Какой лучший способ управления большим количеством таблиц в MS SQL Server?

Question

Этот вопрос связан с другим:
Поможет ли несколько файловых групп ускорить мою базу данных?

Программное обеспечение, которое мы разрабатываем, является аналитическим инструментом, использующим MS SQL Server 2005 для хранения реляционных данных. Первоначальный анализ может быть медленным (поскольку мы обрабатываем миллионы или миллиарды строк данных), но существуют требования к производительности для быстрого вызова предыдущих анализов, поэтому мы «сохраняем» результаты каждого анализа.

Наш нынешний подход заключается в сохранении результатов анализа в виде серии «специфичных для прогона» таблиц, и анализ достаточно сложен, чтобы в результате мы могли получить до 100 таблиц на анализ. Обычно эти таблицы занимают пару сотен МБ на анализ (что мало по сравнению с нашими сотнями ГБ, а иногда и несколькими ТБ исходных данных). Но в целом, дисковое пространство не является проблемой для нас. Каждый набор таблиц специфичен для одного анализа, и во многих случаях это дает нам огромное улучшение производительности по сравнению со ссылкой на исходные данные.

Подход начинает разрушаться, когда мы накапливаем достаточно сохраненных результатов анализа - прежде чем мы добавили более надежные возможности архивирования / очистки, наша тестовая база данных поднялась до нескольких миллионов таблиц. Но для нас не составит большого труда иметь более 100 000 столов, даже в производстве. Microsoft накладывает довольно огромный теоретический предел на размер системных объектов (~ 2 миллиарда), но как только наша база данных вырастет за пределы 100 000 или около того, простые запросы, такие как CREATE TABLE и DROP TABLE, могут значительно замедлиться.

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

Еще одно замечание: я не в восторге от идеи «просто бросить аппаратное обеспечение при проблеме» (т. Е. Добавить ОЗУ, мощность процессора, скорость диска). Но мы также не исключаем этого, особенно если (например) кто-то может точно сказать нам, какой эффект будет иметь добавление ОЗУ или использование нескольких файловых групп при управлении большим системным каталогом.

Answer 1

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

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

CREATE TABLE и DROP TABLE, вероятно, работают плохо, потому что базы данных master или model не оптимизированы для такого рода поведения.

Я также рекомендую поговорить с Microsoft о вашем выборе дизайна базы данных.

Answer 2

Все ли таблицы имеют разные структуры? Если они имеют одинаковую структуру, то вам может не хватить одной многораздельной таблицы.

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

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

Answer 3

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

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

Мы также заметили, что SQL 2008, как правило, обрабатывает большие системные каталоги лучше, чем SQL 2000 и SQL 2005. (Мы не обновились до 2008 года, когда я разместил этот вопрос.)

Answer 4

Это очень интересная проблема / приложение, с которым вы работаете. Я хотел бы поработать над чем-то вроде этого. :)

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

Вам понадобится сочетание серьезных хранилищ данных и разбиения данных / таблиц. В зависимости от того, какой объем данных вы хотите сохранить и заархивировать, вам может потребоваться начать нормализацию и выравнивание таблиц.

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