Xeraph@NCHOVY

내가 메일 쓰고 나서 팀장님께서 주신 링크(Bulk Insert 옵션에 따른 성능 비교)도 참조할만하다. 정리를 잘 해놨다.

그 외에 아래 사항도 알아두면 좋다.

1. Visio에서 SQL Server로 포워드 엔지니어링하면 자동으로 클러스터드 인덱스 잡힘
2. SQL Server 2005의 SSIS에서 FastParse=on으로 설정하고 패키지 실행하면 ROWLOCK 기반의 Bulk Insert 보다 더 빠르다고 함. (SQL Server 2005의 Bulk Insert 성능 비교)
3. Bulk Insert 할 때 Table Lock 걸면 Uncommitted Read 해도 조회 불가
4. Bulk Insert 할 때 ORDER 옵션으로 힌트 줄 수 있음
5. SQL 서버에서는 pintable로 메모리 DB 사용 가능

이제 실제 내용으로 들어가보자.

GUID를 식별자로 쓰면 순서가 없기 때문에 랜덤하게 끼워넣어야 한다. 이 경우 빈번한 페이지 복사 작업이 발생하게 될 것이고, 데이터셋이 커질수록 성능이 저하될 수 밖에 없다. 혹 실수로 Clustered Index까지 지정하는 경우 성능이 극심하게 떨어진다. 아래 테이블들은 GUID를 Clustered Index로 잡거나 Non-Clustered Index로 잡은 경우의 성능과, 성능이 아주 잘 나올 것으로 예상되는 AutoID와, 순서를 맞춰서 TimeID 문자열을 만드는 경우 각각 어느 정도의 성능 편차를 보이는지 실험한 것이다.

CREATE TABLE GuidLogs (
LogUUID CHAR(36) NOT NULL PRIMARY KEY,
Message Varchar(200) NOT NULL)

CREATE TABLE AutoIdLogs (
AutoID INT IDENTITY(1, 1) PRIMARY KEY,
Message Varchar(232) NOT NULL)

CREATE TABLE NonClusteredGuidLogs (
LogUUID CHAR(36) NOT NULL PRIMARY KEY NONCLUSTERED,
Message Varchar(200) NOT NULL)

CREATE TABLE TimeStringIdLogs (
TimeID CHAR(21) NOT NULL PRIMARY KEY,
Message Varchar(200) NOT NULL)

.NET에서 SqlBulkCopy를 이용하여 100만건을 Bulk Insert 했을 때, 수치는 아래와 같았다.

1. AutoID 경과 시간 : 17.8746568초
2. TimeID 경과 시간 : 34.9216259초
3. Non-Clustered GUID 경과 시간 : 70.8910787초
4. Clustered GUID 경과 시간 : 124.88924초

순서만 잘 잡아서 넣어도 Non-Clustered에 비해 2배, AutoID는 4배까지 성능이 차이난다. Clustered 잡힌 경우는 거의 재앙이라고 봐야 될 정도로, 7배 정도의 차이가 발생한다. 이 차이는 데이터셋이 클수록 더 심해질 것이다.

이렇게 귀찮다는 이유로 GUID를 식별자로 쓰면 성능으로 심각한 손해를 볼 수 있다. 유일성을 필요로 하는 경우 다른 키를 조합하는 등 꼼수를 잘 부려서 해결해야 한다.