#sql-server
#sql-server
Вопрос:
Мой босс хочет, чтобы я настроил механизм архивирования таким образом, чтобы таблица не становилась слишком большой и не страдала от проблем с производительностью. Мы увидели, что таблица выросла до 11 миллионов строк и размером около 1 гигабайта, что, по-видимому, не так важно для SQL Server. Он имеет кластеризованный индекс в столбце DateTime, который, я думаю, не сильно повлияет на производительность, поскольку строки обычно будут вставляться в хронологическом порядке. порядок.
Каков наилучший способ архивирования (перемещения и хранения в другом месте) этих данных? Если бы я должен был переместить данные в отдельную таблицу в базе данных, это все равно замедлило бы работу базы данных? Было бы лучше с точки зрения производительности, если бы я заархивировал данные в отдельную базу данных на том же сервере SQL? Или есть другой вариант, который превосходит два, которые я рассматриваю.
Заранее спасибо.
Ответ №1:
Найдите другого босса. 11 миллионов — это МАЛО. Как МАЛЕНЬКИЙ. Вернитесь, когда в базе данных будет 10 миллиардов строк. Посмотрите на разделение, если нужно.
Тем не менее, это во многом зависит от того, что вы хотите, и являются ли данные невидимыми для запросов или нет. В любом случае, разделяемые данные, которые не запрашиваются, не будут облагаться налогом на сервер — если они запрашиваются, то не имеет значения, является ли это отдельной таблицей или базой данных. Перемещение данных лучше всего выполнять — в нерабочее время (ночные выходные) с помощью запланированного задания.
Комментарии:
1. Я думаю то же самое. Я думаю, что проблема с производительностью была результатом чего-то другого, а не роста таблицы; однако у меня нет средств доказать это, поэтому мне остается реализовать механизм архивирования. Итак, с точки зрения производительности не имеет значения, были ли данные перемещены в таблицу или базу данных? Тогда я мог бы выбрать опцию таблицы.
2. Нет, пробел есть пробел — пока нет скрытых других точек, таблица или база данных не имеют значения. Однако я бы начал анализировать запросы к 11 миллионам строк таблицы с помощью profler и посмотрел, отсутствует ли какой-то глупый индекс или какой-то глупый SQL.