Некоторые (надеюсь) основные вопросы об управлении большими таблицами (> 10 миллиардов строк) в SQL Server - PullRequest
0 голосов
/ 09 декабря 2011

Я провожу некоторые эксперименты с дизайном таблицы для таблицы, которая, как ожидается, будет иметь LOTS строк (свыше 10 миллиардов). Несколько вещей, которые сразу приходят на ум:

  • В том, что я называю табличным подходом «Tall», каждая строка будет иметь один из около 25 «типов» вместе со значением, соответствующим этому типу. Должен ли я превратить это в «широкий подход» с одной строкой, содержащей столбец NULLable для значения для каждого типа? Это не очень хороший подход с точки зрения удобства сопровождения (что, если мне нужно добавить больше «типов»), но меня больше беспокоит производительность, причем размер является второстепенным фактором.
  • Ряды будут иметь метку даты и времени (вероятно, маленькое время, так как мне нужна только минута). Я слышал, что мне может быть лучше использовать целочисленное представление для даты и времени, а не для самого времени в таблице. Я ожидаю, что эта дата и время будут активно использоваться в запросах (возможно, даже в той степени, в которой они являются частью кластерного индекса).

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

1 Ответ

1 голос
/ 09 декабря 2011

Вы можете извлечь выгоду из разбиения таблицы.И SQL Server, и Oracle хорошо поддерживают эту функцию.Разделение таблиц позволяет вам сохранить одну логическую таблицу, к которой вы будете продолжать запрашивать, но СУБД фактически разбивается на несколько физических файлов, которые она поддерживает с указанными вами правилами.Например, у вас могут быть разделы на основе даты, поэтому строки с CreateDate, которые попадают в 1990, 2000, 2010 или 2020 г., будут размещены в соответствующем разделе.

СУБД также использует разделы для использования параллелизма иможет повысить производительность при запросах, охватывающих несколько разделов.

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

Документация Microsoft по секционированию

Обновление: если вы рассматриваете возможность использования целого числа для вашей даты и времени для повышения производительности, на самом деле было бы, если бы вы поместили свой индекс в целочисленную дату.Причина этого в том, что целые числа легче сортировать, поэтому создание индекса B-Tree улучшит общую скорость этого конкретного индекса.Однако, если вы не собираетесь запрашивать использование этого столбца (в предложении where или group by), не рекомендуется просто добавлять индексы, потому что вы можете это сделать.На самом деле, я не удивлюсь, если ваше хранилище индекса будет больше, чем размер вашей таблицы.

...