Стратегия роста данных - PullRequest
0 голосов
/ 09 марта 2011

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

Теперь не все данные должны быть доступны в любое время, хотя мы должны сделать это.Другими словами, мы можем «заархивировать» некоторые старые данные.Наша текущая стратегия заключается в простом перемещении «архивных» данных в другую таблицу, чтобы запросы «изо дня в день» выполнялись быстро, и мы можем получить доступ к «архивированным» данным, когда нам это необходимо, путем объединения двух таблиц.

Ответы [ 4 ]

1 голос
/ 09 марта 2011

Использовать разбиение таблицы.

Прочитайте эти ссылки, автор подробно с примером. http://blog.sqlauthority.com/2008/01/24/sql-server-2005-introduction-to-partitioning/

http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitioning-tutorial-how-to-horizontal-partition-database-table/

0 голосов
/ 09 марта 2011

Как пояснение к другим ответам, обе стратегии работают хорошо в зависимости от того, какую версию Sql Server вы используете.Если у вас корпоративная редакция, то я бы пошел путем разбиения таблиц, так как он требует меньше работы на стороне разработки.К сожалению, Microsoft ограничил разделение таблиц только корпоративной версией, хотя это функция практически во всех других базах данных, включая бесплатные альтернативы с открытым исходным кодом.Если вы застряли без корпоративной версии (многие считают, что это цена> $ 20 тыс. / Процессор), то хорошая альтернатива - перейти к подходу ручного разбиения, как вы сначала предложили.Другой альтернативой, которая не требует корпоративной версии, является использование покрывающих индексов.Хороший способ сделать это - использовать представление и создать материализованный индекс для представления, это в основном создание копии только тех данных, которые вам нужны на диске, без лишних затрат на перемещение данных вокруг себя.Допустим, вы создали представление с предложением where для включения только сегодняшних данных, а затем создали материализованный индекс для представления, фактически будет индекс, содержащий все данные за сегодня на диске, и возврат будет таким же быстрым, как если бы вывручную разделил данные.К сожалению, есть много ограничений в сложности представления, для которого вы можете создать индекс, но оно того стоит, когда оно работает, оно работает хорошо.

0 голосов
/ 09 марта 2011

Для SQL Server 2005+ взгляните на разбиение таблицы .

0 голосов
/ 09 марта 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...