유니코드가 저장소 및 성능에 미치는 영향

SQL Server 2005 에서는 UCS-2 인코딩 체계를 사용하여 유니코드 데이터를 저장합니다. 이 인코딩 체계에서는 모든 유니코드 문자가 2바이트를 사용하여 저장됩니다.

문자를 유니코드로 저장하는 것과 비유니코드로 저장하는 것의 차이는 비유니코드 데이터가 더블바이트 문자 집합을 사용하여 저장되는지 여부에 따라 달라집니다. 동아시아 언어 이외의 모든 언어 및 태국어에서는 비유니코드 문자를 싱글바이트로 저장합니다. 따라서 이러한 언어를 유니코드로 저장하면 비유니코드 코드 페이지를 지정할 때 사용되는 것보다 두 배의 공간이 사용됩니다. 반면 다수의 다른 아시아 언어의 비유니코드 코드 페이지에서는 DBCS(더블바이트 문자 집합)로 문자 저장을 지정합니다. 따라서 이러한 언어의 경우 비유니코드로 저장하는 것과 유니코드로 저장하는 것에는 거의 차이가 없습니다.

다음 표에서는 더블바이트 문자 집합으로 문자 데이터 저장을 지정하는 비유니코드 코드 페이지를 보여 줍니다.

유니코드 데이터가 성능에 미치는 영향은 다음과 같은 다양한 요인이 복합되어 나타납니다.

• 유니코드 정렬 규칙 및 비유니코드 정렬 규칙 간의 차이
• 더블바이트 문자 정렬 및 싱글바이트 문자 정렬 간의 차이
• 클라이언트 및 서버 간의 코드 페이지 변환

SQL Server에서는 Windows 데이터 정렬로 정의된 비유니코드 데이터에 대해 유니코드 정렬 규칙을 사용하여 문자열 비교를 수행합니다. 이러한 정렬 규칙은 비유니코드 정렬 규칙보다 훨씬 복잡하므로 더 많은 리소스가 필요합니다. 흔히 유니코드 정렬 규칙을 적용하는 데 비용이 더 많이 들지만 일반적으로 유니코드 데이터와 Windows 데이터 정렬로 정의된 비유니코드 데이터 간에 성능 차이는 거의 없습니다.

단, 이것은 SQL 데이터 정렬을 사용하여 정의된 비유니코드 데이터에 대해 SQL Server에서 비유니코드 정렬 규칙을 사용하는 경우에만 해당합니다. 이 경우 유니코드 정렬 규칙을 적용할 때보다 정렬 및 검색 속도가 일반적으로 더 빠릅니다. 유니코드 정렬 규칙은 Windows 데이터 정렬 또는 SQL 데이터 정렬을 사용하여 정의된 모든 유니코드 데이터에 적용됩니다.

또 한 가지 중요한 점은 대량의 유니코드 데이터를 정렬할 경우 동일한 양의 비유니코드 데이터를 정렬할 때보다 속도가 느려질 수 있다는 것입니다. 그 이유는 데이터가 더블바이트로 저장되기 때문입니다. 반면 아시아 언어 문자를 유니코드로 정렬하면 아시아 언어 DBCS 데이터를 특정 코드 페이지로 정렬하는 것보다 속도가 빨라집니다. DBCS 데이터는 싱글바이트와 더블바이트 폭이 혼합되어 있는 반면 유니코드 문자는 고정 폭이기 때문입니다.

다른 성능 문제는 주로 SQL Server 인스턴스와 클라이언트 간의 인코딩 메커니즘 변환 문제에 따라 나타납니다. 일반적으로 클라이언트와 서버 간 코드 페이지 변환이 성능에 미치는 영향은 사소합니다. 그렇지만 여기에서 어떤 성능 문제가 발생하는지 이해하는 것이 중요합니다.

ODBC API 버전 3.6 또는 이전 버전과 DB-Library API에서는 유니코드가 인식되지 않습니다. 이러한 API로 정의된 데이터 액세스 방법을 사용하는 클라이언트에서는 유니코드 데이터를 암시적으로 클라이언트 코드 페이지로 변환하기 위해 리소스가 사용됩니다. 또한 클라이언트 코드 페이지가 특정 유니코드 문자를 인식하지 못하는 경우 클라이언트측에서 데이터가 손상될 위험이 있습니다.

SQL Server 버전 7.0에 포함된 Microsoft Data Access Components 버전 2.7을 시작으로 이후 버전의 ODBC와 OLE DB 및 ADO는 유니코드를 인식하며 UCS-2 인코딩 메커니즘을 사용합니다. 따라서 유니코드를 사용할 수 있는 응용 프로그램의 경우 SQL Server 인스턴스의 유니코드 데이터로만 작업한다면 변환 문제는 발생하지 않습니다. 클라이언트가 유니코드 사용 가능 API를 사용하지만 SQL Server 인스턴스의 데이터 저장 메커니즘이 유니코드가 아닌 경우에는 변환 문제가 발생하지 않습니다. 그러나 문자에 대한 코드 포인트를 SQL Server 코드 페이지에 매핑할 수 없는 경우에는 데이터 삽입 또는 업데이트 작업 중 데이터가 손상될 수 있습니다.

최상의 유니코드 사용 방법

일반적으로 DBCS가 아닌 데이터를 유니코드로 저장할지 여부는 이 작업이 저장소에 미치는 영향, 클라이언트가 데이터로 작업하는 동안 발생하게 될 정렬 및 변환 작업의 양과 데이터 손상이 어느 정도나 될지를 제대로 인식하고 결정해야 합니다. 정렬 및 변환은 해당 작업이 수행되는 위치에 따라 성능에 영향을 줄 수 있습니다. 그러나 이것은 대부분의 응용 프로그램에서는 무시해도 될 만한 수준입니다. 특히 인덱스가 올바르게 디자인된 데이터베이스는 거의 영향을 받지 않습니다. 그러나 데이터가 손상될 경우에는 응용 프로그램과 데이터베이스의 무결성뿐만 아니라 전반적인 업무에 영향을 받게 됩니다. 이러한 장단점을 고려하여 다음 두 조건 모두에 해당할 경우에는 문자 데이터를 특정 코드 페이지로 저장하는 것이 좋습니다.

• 하드웨어 제한으로 인해 저장소 공간을 절약해야 합니다. 또는 대량의 데이터를 자주 정렬하고 있으며 테스트에 따르면 유니코드 저장 메커니즘이 성능에 심각한 영향을 주는 것으로 나타납니다.
• 데이터에 액세스하는 모든 클라이언트의 코드 페이지가 서버의 코드 페이지와 일치하며 이러한 상황이 예기치 않게 변경될 가능성은 없습니다.

대부분의 경우 DBCS가 아닌 데이터를 비롯하여 문자 데이터를 유니코드로 저장할지 여부는 단순히 성능보다는 전반적인 업무 요구 사항을 토대로 결정해야 합니다. 인터넷 트래픽이 급격하게 증가된 글로벌 경제에서 다양한 로켈을 실행하는 클라이언트 컴퓨터를 지원하는 것이 더욱 중요해지고 있습니다. 뿐만 아니라 전세계 사용자가 요구하는 모든 문자를 지원하는 단일 코드 페이지를 선택하는 것이 점점 어려워지고 있습니다.

참고 항목

개념

데이터 정렬 및 코드 페이지 아키텍처
데이터 정렬 유형

도움말 및 정보

SQL Server 2005 지원 받기