Предложение по проектированию больших баз данных SQL Server

Мы создаем базу данных в MSSQL 2008 R2 Standard, где мы будем хранить большое количество записей. Мы оцениваем более 200 миллионов записей в одну таблицу в год, и мы в основном ВСТАВЛЯЕМ с очень малым количеством ОБНОВЛЕНИЙ или УДАЛЕНИЙ в данных. Это система архивации данных, в которую мы ежедневно вставляем исторические записи. Мы будем генерировать различные виды отчетов по этой исторической записи по запросу пользователя, поэтому у нас есть некоторые опасения и мы нуждаемся в технической информации и рекомендациях.

• Как лучше всего управлять такими архивными таблицами и базами данных?

Вот мое мнение:

1. Если у вас очень мало обновлений / удалений, вы можете увеличить коэффициент заполнения страницы до 95%. Это сэкономит на пространстве и читает. Сделайте некоторое тестирование все же.
2. Разделите таблицу на основе широкой категории, например, год.
3. Разместите эти разделы в разных файловых группах.

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

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

• Убедитесь, что ваш дизайн позволяет вашим вставкам всегда находиться в конце стола. Подсказка кластерного индекса.

• Лишь очень немногие некластеризованные индексы поддерживают отчеты, которые вам нужно сделать, чтобы поддерживать их минимальные. Эти отчеты предварительно созданы? если да, то подумайте над этим вопросом: нормально ли, если создание отчета занимает 2 часа? (без индекса) или 1 мин (с индексом). Может быть, нормально, чтобы отчет занимал 2 часа, чтобы индекс был меньше? а может и нет? Если отчет не составлен заранее, это другой вопрос, так как пользователи не любят ждать, и вам, возможно, потребуется внедрить больше индексов для поддержки ваших отчетов.

• Исходя из того, как вы описываете эту базу данных, звучит так, как будто вы ожидаете много строк, и данные будут значительно увеличиваться и увеличиваться. Рассматривали ли вы, как создать резервную копию этой системы? Я имею в виду, что большинство данных будут одинаковыми и просто добавляются новые? Я не знаю бизнес-требований этой системы, но мне кажется, что через год или два это может быть база данных значительного размера, и у вас могут возникнуть проблемы с созданием большого количества полных резервных копий. Подумайте о создании одного полного резервного копирования с периодическими (еженедельными?) И дифференциальными (ежедневными?) И журналами транзакций (ежечасно?). Конечно, как я уже сказал, я не знаю бизнес-требований, может быть, вам не нужны все резервные копии все время? Размер может быть проблемой в архивных системах.