Должен ли я создать кластерный индекс для таблицы фактов? никогда? всегда?

Question

Есть ли недостатки в хранилище данных для создания кластеризованных индексов на таблицах фактов? (большую часть времени это будет в столбце datetime)

Вы бы ответили да или нет "по умолчанию ..."?

Если я не должен создавать кластерные индексы по умолчанию, то почему? (Я знаю плюсы кластерных индексов, но каковы некоторые минусы?)

Ссылки

http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/11/365.aspx

Answer 1

Я не хочу говорить всегда и никогда , но я думаю, что в большинстве случаев использование кластерных индексов на ваших таблицах фактов будет для вас хорошей вещью. Не рекомендуется создавать кластеризованный индекс для типа столбца, который вставляется со значениями, которые могут быть случайными. Например, вы не хотели бы кластеризованный индекс на что-то вроде GUID. Даты и последовательные идентификаторы отлично подходят для кластерных индексов, особенно для запросов диапазона.

Вы заявили, что знаете плюсы кластеризованных индексов, но с точки зрения минусов все будет зависеть от того, как вы их используете, чтобы определить, являются ли они минусами для вас.

1.) В каждой таблице может быть только один кластеризованный индекс, поскольку он изменяет расположение блоков данных в соответствии с порядком индекса. Вот почему кластерные индексы отлично подходят для запросов диапазона

2.) Поскольку блоки данных расположены в порядке индекса, вставки и обновления, которые изменяют порядок ключа, могут вызвать физические изменения в блоках данных, чтобы сохранить их в порядке с индексом. Вставка значения ключа в последовательном порядке может облегчить эту проблему.

Answer 2

Я бы всегда предлагал кластеризованный индекс для таблицы (транзакции или хранилища), в которой часто выполняется поиск по заданному значению. Недостатком кластерного индекса (или любого индекса) является то, что вы создаете дополнительное хранилище данных, которое занимает место. Если индексируемая таблица огромна ... индекс тоже будет! Чем больше у вас индексов, тем больше данных вы храните в дополнение к базе данных. Однако, если вам нужна скорость для поиска, вам может понадобиться индекс, который поможет увеличить скорость.

Однако вы можете также создать кластеризованный индекс для идентификатора вашей таблицы. А затем создайте индексы вне базы данных в таком продукте, как Lucene (или Lucene.NET). Затем вы можете выполнить поиск в вашем индексе Lucene (который обладает гораздо большей гибкостью и возможностями, когда дело доходит до поиска), который будет возвращать идентификатор определенной записи (или записей), который вы затем сможете использовать для идентификации данных, которые вам нужны в вашей базе данных. Это маршрут, который мы довольно часто использовали в моем текущем проекте, и я должен признать, что он работает довольно гладко! Создание индексов значительно быстрее (особенно по сравнению с использованием опций FullText в SQL Server). Просто кое-что рассмотреть.

Answer 3

Наличие кластерного индекса PK с автоинкрементом int (bigint) значительно упрощает разбиение; и рано или поздно таблица фактов доходит до этой точки. Так что, даже если вы думаете, что вам это может не понадобиться, создайте его.