Юникод и производительность

Question

Я нахожусь в процессе миграции крупномасштабного веб-сервиса для совместимости с международными символами.Это стек Tomcat / Spring MVC / SQL Server.Сам переход был относительно простым, мы внесли несколько изменений настроек в Tomcat, чтобы принудительно использовать в ответ UTF-8 по умолчанию, изменили некоторый код Java для использования кодировки и перенесли несколько столбцов VARCHAR в NVARCHAR, после чего последовала здоровая дозамодульные / функциональные тесты.

Другой человек в моей команде хочет провести нагрузочный тест, чтобы убедиться, что ни одно из изменений не повлияет на производительность системы.Отдельные компоненты этого перехода, описанные выше, на самом деле не намекают на какие-либо изменения производительности, и, честно говоря, я не думаю, что это абсолютно необходимо, основываясь на моих ограниченных знаниях.В любом случае я планирую это сделать, но мой вопрос в следующем: есть ли какие-либо проблемы с производительностью, которые можно увидеть при такой миграции?Есть ли что-то специфическое для другой кодировки символов, которое может изменить производительность системы?

Единственное, о чем я мог подумать, это сравнение и сортировка тяжелых строк и т. Д. Есть идеи?

Answer 1

Вам следует рассмотреть возможность обновления до SQL Server 2008 R2, поскольку он предлагает Сжатие Unicode :

Сжатие Unicode в SQL Server 2008 R2 использует реализацию Стандартная схема сжатия для Unicode (SCSU) алгоритм для сжатия Значения Unicode, которые хранятся в строке или страницы сжатые объекты. Для этих сжатые объекты, Unicode сжатие автоматическое для nchar (n) и nvarchar (n) столбцы. SQL Сервер базы данных Engine хранит Unicode данные в виде 2 байтов, независимо от локали. Это известно как кодирование UCS-2. За в некоторых регионах реализация Сжатие SCSU в SQL Server 2008 R2 может сэкономить до 50 процентов в хранилище пространство.

Самая большая проблема, с которой вы столкнетесь, - это правила приоритета типов данных Поскольку NVARCHAR имеет более высокий приоритет, чем VARCHAR, любое выражение, которое смешивает два, будет приведено к NVARCHAR. С практической точки зрения это означает, что условие соединения между столбцом A и столбцом B, которое раньше было между двумя столбцами VARCHAR и привело к поиску по индексу, теперь будет между CAST(A as NVARCHAR) и B (учтите, что мы изменили только B на NVARCHAR), и это больше не SARGable (вызовет сканирование таблицы). Эта проблема может появляться в объединениях, в предложениях WHERE, в типах параметров и во многих других местах. Это должно быть тщательно продумано, ухудшение производительности, которое приводит к огромным (полное сканирование против поиска).

Answer 2

У меня есть только этот анекдот:

В моей бывшей компании мы столкнулись с проблемой сопоставления текстового поля в базе данных (ASCII) со строкой Unicode в запросе.Это привело к тому, что сервер sql переключился на сканирование таблиц, а не на обычный индекс, поскольку он не мог доказать, что строка всегда будет переводимой в ascii.Это было значительным ударом по производительности для нас.

Answer 3

Кодировка символов, если она сделана правильно, не должна быть проблемой.Unicode намного сложнее, но вы не думаете об этом.Кто-то уже сделал.Все, о чем вам нужно подумать, это то, что вы не конвертируете произвольные строки бессмысленным образом.

Однако вы увидите, что все ваши строковые данные будут занимать вдвое больше места.Это влияет на эвристику, которую использует SQL Server для создания планов выполнения, и существуют тонкие проблемы с индексами, которые могут измениться, но я не стал бы беспокоиться об этом, если у вас нет действительно больших наборов данных.