Раздел или Индекс большой таблицы в SQL Server - PullRequest
Новая
       19

Раздел или Индекс большой таблицы в SQL Server

5 голосов
/ 09 мая 2019

У меня есть большая таблица, состоящая из 4 миллиардов + строк и 50 столбцов, большинство из которых datetime или numeric, за исключением нескольких varchar.

Данные будут вставляться в таблицу еженедельно (около 20 миллионов строк).

Я ожидаю запросов с предложениями where для некоторых столбцов datetime и пары столбцов varchar. В таблице нет первичного ключа.

Нет индексов и таблица не разбита на разделы. Я использую SQL Server 2016.

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

Поскольку таблица большая, я должен сначала создать индексы или сначала создать разделы? Если я создаю индексы, а затем создаю разделы, что мне следует делать, чтобы поддерживать их новыми еженедельными данными.

РЕДАКТИРОВАТЬ : Кроме того, минимальные обновления и удаления ожидаются в таблице

1 Ответ

3 голосов
/ 09 мая 2019

Я понимаю, что мне нужно разделить или проиндексировать таблицу

Вам нужно понять, что вы получаете от разбиения. Это совсем не тот случай, когда SQL Server требует правильного разделения на большие таблицы. SQL Server масштабируется до произвольных размеров таблиц без каких-либо внутренних проблем.

Общие преимущества разделения:

  1. Массовое удаление в постоянное время
  2. Другое хранилище для старых разделов
  3. Не резервировать старые разделы

Иногда в особых ситуациях (например, columnstore) разбиение может помочь в качестве стратегии для ускорения запросов. Обычно для этого лучше индексировать.

По сути, разбиение разбивает таблицу физически на несколько вложенных таблиц. Чаще всего это оказывает отрицательное влияние на планы запросов. Индексы вполне способны ограничить набор данных, к которым нужно прикоснуться. Перегородки хуже для этого.

Большинство запросов будут фильтроваться по столбцам datetime и по некоторым столбцам varchar. Мол, получить данные для определенного диапазона дат для определенного объекта. С индексами он будет сильно фрагментирован из-за новых вставок, а перестройка / реорганизация индексов также потребует много времени. Я могу сделать это, но опять же не уверен, какой подход.

Кажется, вы можете лучше всего решить эту проблему с помощью индексации:

  1. Индекс в соответствии с ожидаемыми запросами.
  2. Поддерживать индексы должным образом. Это не так уж сложно. Например, восстановите их после еженедельной загрузки.

Поскольку таблица большая, я должен сначала создать индексы или сначала создать разделы?

Сначала настройте разделение объектов. Затем создайте или перестройте кластеризованный индекс на новой схеме секционирования. Если возможно, сначала удалите другие индексы, а затем создайте их заново (может не работать из-за ограничений доступности).

что мне делать, чтобы получать новые данные, поступающие еженедельно.

Какие у вас проблемы? Новые данные будут сохранены в соответствующих разделах автоматически. Обязательно создайте новые разделы перед загрузкой данных. Держите перегородки готовыми за 2 недели. Последние разделы всегда должны быть пустыми, чтобы избежать дорогостоящих разбиений.

В таблице нет первичного ключа.

Чаще всего это не очень хороший дизайн. Большинство таблиц должны иметь первичный ключ и кластерный индекс. Если нет естественного ключа, используйте искусственный ключ, такой как bigint identity.

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

...