Нужны подходы к разделению базы данных SQL Server для архивации и отчетности.

Мне не помешала бы помощь. У меня есть производственная база данных на 750 ГБ. (Да, да, этот вопрос можно было бы решить раньше, но он выше моей зарплаты) База данных содержит данные за несколько лет.

Текущее требование состоит в том, чтобы

  1. ПЕРЕМЕЩАЙТЕ (а не просто копируйте) старые данные в отдельную архивную базу данных, чтобы повысить производительность в производственной среде. т.е. строки будут удалены из производства навсегда. Это будет делаться периодически - я предлагаю раз в месяц, на непрерывной основе. Я не знаю сразу, будет ли архивная БД на другом сервере - может быть, а может и нет.
  2. Создайте среду отчетности таким образом, чтобы она содержала объединение архивной и производственной баз данных. Загвоздка в том, что часть, состоящая из производственных данных, должна обновляться не реже одного раза в день. Этой среды, вероятно, не будет на рабочем сервере (но я могу ошибаться!)

Для целей этого вопроса предположим, что схемы везде одинаковы :) Все таблицы имеют один первичный ключ - INT NOT NULL IDENTITY (1,1). У нас есть возможность делать снэпшоты продукции через SAN. Первичные ключи должны быть сохранены.

Что было рассмотрено до сих пор

  • Мы рассмотрели репликацию и доставку журналов, но этого недостаточно, чтобы сделать базу данных отчетов объединением рабочей и архивной баз данных.
  • Мы рассмотрели секционированные представления, но первичный ключ — это IDENTITY и соответственно не будет работать :(
  • Мы рассматривали возможность разделения, но я не сторонник ежедневного ETL, для которого потребуются сотни гигабайт операций ввода-вывода (при таком подходе мы не можем использовать моментальный снимок SAN).
  • Наконец, я рассматриваю индивидуальный подход к приложению, который будет эмулировать некоторые функции репликации SQL Server, но с более специфическими функциями, чем стандартные. Я действительно не хочу делать что-то очень нестандартное.

Что мне здесь не хватает? Это не может быть уникальной потребностью.


person Xavier J    schedule 20.05.2014    source источник
comment
Какую проблему ты пытаешься решить? то есть, почему база данных 750 ГБ является проблемой?   -  person adrianm    schedule 21.05.2014
comment
Производительность начинает ухудшаться, например. Клиентское приложение вставляет миллионы строк в неделю. Так уже несколько лет ходит. Мы не можем ограничить количество вставляемых строк — такова природа бизнеса.   -  person Xavier J    schedule 21.05.2014
comment
@codenoire У меня есть несколько идей на этот счет, но они связаны с нашей коммерческой технологией, поэтому не подходят для ответа на stackoverflow. Вы можете написать мне, если хотите узнать больше об этом, мой адрес электронной почты находится в моем профиле.   -  person dbschwartz    schedule 22.05.2014
comment
Думаю, вы уже придумали какое-то решение. Было бы здорово, если бы вы добавили сюда ответ, описывающий, что вы наконец сделали и насколько хорошо это вам помогло.   -  person Ankur-m    schedule 19.09.2014


Ответы (1)


Как спрашивает @adriamn, у меня тот же вопрос.

У вас есть одна большая таблица с множеством строк, которая не масштабируется для ваших целей, например. из-за блокировки, индексов и т.д.?

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

Важно то, что вы делите данные во время выполнения на разные таблицы, и нет единой точки отказа (или конфликта) с точки зрения схемы базы данных.

person Martin Podval    schedule 21.05.2014
comment
Это подход. Но проблема в том, что в настраиваемой среде отчетов у нас есть несколько готовых отчетов, а также некоторые функции для специальных отчетов. Это усугубит уже существующие проблемы для пользовательской базы, если мы начнем дробить таблицы по диапазонам дат. - person Xavier J; 21.05.2014