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

Question

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

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

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

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

Answer 1

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

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

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

[EDIT] SQL Server 2005 и более поздних версий (Enterprise Edition) поддерживает разделы. Благодаря Mitch Wheat

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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