Огромный стол с одним столбцом (2,5 B строк). Кластерный индекс против кластерного индекса Columnstore

Question

У нас огромная таблица Table1(2,5 миллиарда строк) с одним столбцом A(тип данных NVARCHAR(255)). Каков правильный подход для операций поиска по этой таблице. Кластерный индекс на A Vs Кластерный индекс хранилища столбцов на A.

Мы уже храним эту таблицу в отдельной файловой группе от другой таблицы Table2, к которой она будет присоединена.

Вы предлагаете разделить эту таблицу для лучшей производительности? Этот столбец также будет содержать данные Unicode. Итак, какой подход разделения подходит для типа данных Unicode?

ОБНОВЛЕНИЕ: Чтобы уточнить далее, сценарий использования для таблицы SEEK. В таблице хранятся идентификаторы для физических лиц. Основными проблемами здесь являются производительность SEEK в случае огромного стола. Эта таблица будет указана внутри транзакции. Мы хотим, чтобы транзакция была короткой.

Answer 1

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

Учитывая, что это поиск определенных строк, а не агрегация столбца, я бы рекомендовал кластерный индекс вместо индекса хранилища столбцов.