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

Question

В недавнем проекте «ведущий» разработчик разработал схему базы данных, в которой «большие» таблицы будут разделены на две отдельные базы данных с видом на основную базу данных, которая объединит две отдельные базы данных. Основная база данных - это то, из чего было удалено приложение, поэтому эти таблицы выглядели и ощущались как обычные таблицы (за исключением некоторых странных вещей, связанных с обновлением). Это казалось огромной проблемой производительности. Мы видим проблемы с производительностью за этими столами, но ничто не заставляет его передумать о своем дизайне. Просто интересно, как лучше это сделать, или даже стоит ли это делать?

Answer 1

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

Какой у вас размер набора данных? У меня есть клиент с таблицей строк в 6 миллионов в SQL Server, который содержит данные о продажах за 2 года. Они используют его для транзакций и для отчетности без каких-либо заметных проблем со скоростью.

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

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

Answer 2

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

Мой первый вопрос: вы просто имеете в виду размещение больших табличных объектов в отдельных файловых группах (на отдельных шпинделях) или вы имеете в виду разбиение данных внутри табличного объекта?

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

Я бы предложил вместо использования дополнительных баз данных для хранения больших таблиц заглянуть в тему «Файловая группа» в электронной документации по SQL Server или для быстрого просмотра см. Статью :

Если вы заинтересованы в разбиении данных (включая разбиение на несколько файловых групп), то я рекомендую прочитать статьи Кимберли Триппа, который выступил с отличной презентацией во время выхода SQL Server 2005 об имеющихся там улучшениях. Хорошее место для начала - это официальный документ

Answer 3

Какую версию SQL Server вы используете? SQL Server 2005 имеет многораздельные таблицы, но в 2000 (или 7.0) вам необходимо было использовать представления разделов.

Кроме того, что послужило причиной помещения разделов таблицы в отдельную базу данных?

Когда мне приходилось разбивать таблицы в прошлом (до 2005 года), обычно это столбец даты или что-то подобное, с видом на различные разделы. В Books Online есть раздел, в котором рассказывается о том, как это сделать, и все правила вокруг него. Вы должны следовать правилам, чтобы заставить его работать так, как он должен работать.

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

Найдите "многораздельную таблицу" в MSDN, и вы сможете найти более полное руководство для многораздельных таблиц SQL Server 2005, а также советы о том, как настроить их для максимальной производительности.

Answer 4

Существует определенное преимущество для разделения таблиц (независимо от того, находятся ли они в одной или разных файловых группах / дисках). Если столбец раздела выбран правильно, вы поймете, что ваши запросы будут попадать только в нужный раздел. Так что представьте, если у вас есть 100 миллионов записей (я разделил таблицы намного больше, чем это - около 20+ миллиардов строк), и если по большей части, более 70% вашего доступа к данным является только определенной категорией, временной шкалой или типом данные, то это помогает хранить наиболее доступные данные в отдельном разделе. Кроме того, вы можете выровнять раздел по отдельным группам файлов с различными типами дисков (SATA, Fibre Channel, SSD), чтобы наиболее часто используемые / занятые данные находились в самом быстром хранилище, а наименее / редко используемые - практически на медленных дисках.

Хотя, в отличие от Oracle, в SQL Server возможности разбиения ограничены. Вы можете выбрать только один столбец для разделения (даже в SQL 2008). Таким образом, вы должны правильно выбрать столбец, где этот столбец также является частью большинства ваших частых запросов. По большей части люди легко выбирают разделение по столбцу даты. Однако, хотя логично разделить таким образом, если ваши запросы не содержат этот столбец как часть условия, вы не получите достаточных преимуществ от разбиения (другими словами, ваш запрос затронет все разделы независимо от того).

Разделение для хранилищ данных / баз данных типа интеллектуального анализа данных намного проще, чем для OLTP, так как большинство запросов к базе данных DW ограничены периодом времени.

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

Answer 5

Вы спрашиваете о передовых практиках с точки зрения дизайна базы данных или убеждаетесь, что вы изменили свое мнение? :)

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

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

Создайте новую физическую таблицу где-нибудь с помощью 'create table t1 as select * from view1', а затем запустите некоторый длинный пакет с вертикально разделенной таблицей и вашей новой таблицей. Если все так плохо, как вы говорите, разница должна быть очевидной.

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

Answer 6

Я бы не согласился с предположением, что путем разбиения ничего нельзя получить.

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

Например, у нас есть таблица, в которой поле пакета в виде INT представляет INT.

Если мы разделим данные по этому полю, а затем повторно запустим запрос для определенного пакета, мы сможем запустить заданную статистику io ON до и после разделения и увидеть сокращение ввода-вывода,

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

Я не делал много разделов на SQL Server, но у меня есть опыт разделения на Sybase ASE, и это известно как удаление разделов. Когда у меня будет время, я собираюсь протестировать сценарий на компьютере с SQL Server 2005.