Нужен совет: архитектура БД SQL Server для большой базы данных

Question

Привет всем!

Мой клиент в настоящее время имеет базу данных SQL Server, которая выполняет 3-4 миллиона вставок, примерно столько же обновлений и даже больше операций чтения в день, каждый день.Текущая БД выглядит странно ИМХО: входящие данные попадают в таблицу «Текущий», затем ночные записи перемещаются в соответствующие месячные таблицы (например, MarchData, AprilData, MayData и т. Д.), Которые являются точными копиями текущей таблицы (схемаимею в виду).Считывания выполняются с точки зрения того, что UNION все месячные таблицы и текущая таблица, вставки и обновления выполняются только для текущей таблицы.Мне объяснили, что разделение данных на 13 таблиц было вызвано тем фактом, что все эти таблицы используют отдельные файлы данных, и эти файлы данных записываются на 13 физических жестких дисках.Таким образом, каждая таблица получает свой собственный жесткий диск, предположительно увеличивающий производительность просмотра.Что я замечаю, так это то, что ночной перенос записей в ежемесячные таблицы (который выполняется каждые 2 минуты в течение ночи, 8 часов) совпадает с полным резервным копированием, и БД начинает сканировать, время ожидания веб-сайта и т. Д.

Мне было интересно, действительно ли этот подход лучший?Или мы можем рассмотреть другой подход?Обратите внимание, что база данных составляет около 300-400 ГБ и растет на 1,5-2 ГБ в день.Время от времени мы переносим записи старше 12 месяцев в отдельную базу данных (архив).

Любое понимание высоко ценится.

Answer 1

Если вы используете MS SQL Server, рассмотрите Секционированные таблицы и индексы .

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

Это решение, созданное MS, похоже, очень похоже на ваше, за исключением одной важной вещи: оно не перемещает записи за ночь.

Answer 2

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

Для этого есть одно утверждение: ИДИОТЫ НА РАБОТЕ.

• Таблицы хранятся не на дисках, а в файловых пространствах, которые могут занимать несколько файлов данных. Обратите внимание на это ... так что вы можете иметь одно файловое пространство с 12 файлами данных на 13 дисках, и таблица будет распределена по ВСЕМ 13 ТАБЛИЦАМ. Не нужно играть в глупые глупые игры, чтобы распределить нагрузку, это уже возможно, просто прочитав документацию.

• Даже тогда я серьезно сомневаюсь, что 13 дисков быстрые. В самом деле. Я использую частную базу данных меньшего размера (всего 800 ГБ), которая содержит 6 дисков только для данных, и мое текущее рабочее задание состоит из трех цифр дисков (то есть более 100). Пожалуйста, не называйте 13 дисков большой базой данных.

• Во всяком случае, ДОЛЖНА быть необходимость распространять данные, а не UNION, а многораздельные таблицы (для стандартного сервера sql, хотя и для корпоративной версии) - это путь.

Обратите внимание, что объем базы данных составляет около 300-400 ГБ и увеличивается на 1,5-2 ГБ в день.

Получите приличный сервер.

Мне было интересно, действительно ли этот подход лучший?

• О, железо. Получите один из ящиков SuperMicro для баз данных высотой от 2 до 4 стоек, объединительную плату SAS, от 24 до 72 слотов для дисков. Да, один компьютер.

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

• ... вы действительно понимаете, что такие диски - это грубое пренебрежение. RAID 5 или RAID 6 или RAID 10 в порядке, в противном случае ваш сервер может быть недоступен, когда произойдет сбой диска, и перезагрузка базы данных объемом 600 ГБ займет время. Я запускаю RAID 10 для своих дисков с данными, но затем в частном порядке есть таблицы с примерно миллиардом строк (и в работе мы добавляем об этом один день). Учитывая МАЛЕНЬКИЙ размер базы данных, пара SSD также помогла бы ... их бюджет IOPS мог бы означать, что вы могли бы пойти на 2-3 диска и получить намного большую скорость. Если это невозможно, могу поспорить, что эти диски - это медленные 3,5-дюймовые диски со скоростью 7200 оборотов в минуту ... Может помочь переход на диски корпоративного уровня. Лично я использую 300-гигабайтные велоцирапторы для баз данных, но нужно взять диски SAS 15 КБ; )

В любом случае, это звучит очень плохо. Так плохо, что я был бы рад, если бы мой ученик придумал что-то такое умное (как это определенно будет над головой стажера), или мой разработчик перестал бы работать на меня, как только я это выясню (на основании грубой некомпетентности, чувствую свободно оспаривать в суде)

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