Проектирование схемы базы данных - Советы по улучшению возможности архивирования?

Question

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

• Однако эти записи журнала будут использоваться системой во время выполнения для принятия решений, поэтому доступ к ним должен быть относительно быстрым.
• У них также есть проблема в том, что их будет много (по моим оценкам, добавлено 12,5 миллионов в месяц).
• Мне нужно не более последних 30-45 дней для обработки решения.
• Мне нужно хранить их все гораздо дольше 45 дней для поддержки и решения юридических вопросов, вероятно, по крайней мере, 2 года.
• Дизайн таблицы довольно прост, все простые типы (без больших двоичных объектов или чего-либо еще), где это возможно, будут использовать database engine для ввода данных по умолчанию, не более одного внешнего ключа.
• Если это имеет какое-либо значение, базой данных будет Microsoft SQL Server 2005.

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

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

Answer 1

Некоторые базы данных предлагают "разделы" (например, Oracle).Раздел подобен представлению, которое собирает несколько таблиц с идентичным определением в одну.Вы можете определить критерии, по которым новые данные сортируются в разные таблицы (например, месяц или неделя года % 6).

С точки зрения пользователя, это всего лишь одна таблица.Из базы данных PoV это несколько независимых таблиц, поэтому вы можете эффективно запускать для них полные табличные команды (такие как truncate, drop, delete from table (без условия), load / dump и т.д.).

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

[РЕДАКТИРОВАТЬ] SQL server 2005 и более поздних версий (Enterprise Edition) поддерживает разделы.Благодаря Митч Уит

Answer 2

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

Я согласен с использованием триггеров для заполнения таблицы 'CurrentMonthAudit', в конце месяца вы можете переименовать эту таблицу в MonthAuditYYYYMM .Тогда переместить старые таблицы с вашего основного сервера с помощью ETL будет легко, и каждая из ваших таблиц будет управляемой.Поверьте мне, это намного лучше, чем пытаться управлять одной таблицей примерно с 250 миллионами строк.

Answer 3

Ваше первое правильное решение - сделать все как можно проще.

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

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

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

(Кстати, большие таблицы не замедляются быстро, если они хорошо спроектированы - они замедляются медленно.)

Answer 4

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

Базы данных не всегда являются лучшим вариантом, особенно для файлов журналов :)