Я никогда не работал с разделами SQL Server, но в настоящее время я сталкивался с разработкой базы данных, для которой тома, вероятно, этого требуют. Система для купонов. Купоны будут выдаваться периодически, обычно каждые шесть недель, хотя будет также специальная выдача - например, для специального мероприятия. Количество клиентов составляет 15 миллионов, и для каждого события выдачи каждый клиент получит 6 различных типов купонов, что составит 90 миллионов экземпляров купона. Нам необходимо отслеживать данные о погашении экземпляра купона и сохранять их в течение 6 месяцев, хотя обычно купон действителен только в течение шести недель. Любой запрос на погашение недействительного купона не попадет в базу данных, поскольку он будет проверен POS до.
За шестимесячный период нам потребуется сохранить до 360 миллионов строк в таблице экземпляров купонов и до 72 миллионов (при условии максимальной ставки погашения 20%) в таблице погашений. У меня такое ощущение, что эти цифры слишком велики для одного раздела?
У меня вопрос - что использовать в качестве ключа раздела? Одним из очевидных кандидатов будет событие выдачи, дающее приблизительно 6 разделов. Но тогда я думаю, что, может быть, даже это даст слишком большой размер раздела, чтобы обеспечить оптимальную производительность? Можно ли разделить по двум ключам, например, по событию выдачи + последняя цифра идентификатора клиента? Таким образом, логика будет:
If issuance event = 1 and last digit of customer id < 5 then
Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
Store in partition 4
Etc...Кроме того, я не уверен в спецификации сервера базы данных, который нам понадобится. Хватит ли 16 ГБ и 8CPU? БД должна иметь возможность возвращать результат из таблицы экземпляров купона, введя числовое значение штрих-кода менее чем за полсекунды. Ожидаемый запрос транзакции для проверки (выбора) и выкупа (вставки), как ожидается, достигнет пика примерно 3500 в минуту.
64-битный сервер db SQL Server 2008r2 будет настроен как виртуальная машина с очень мощного хоста с доступом к высокопроизводительной и большой емкости SAN.
Я был бы очень благодарен за любые советы от тех, кто развернул решение SQL Server для управления подобными томами.
С уважением
Роб.
источник
Ответы:
Вопросы по спецификации сервера должны быть направлены либо на Serverfault, либо на DBA.SE.
Что касается вопроса о разделении, я не думаю, что вам обязательно нужно разделить для этого.
360 м рядов это много, но это не слишком громоздко.
Ни при каких обстоятельствах НЕ пытайтесь разделить на основе последней цифры поля. Я не уверен, что это даже сработает, но это не SARGable, который не будет надежным.
Если вам нужно только выполнить поиск по одной строке на основе числового ключа, разделение, вероятно, не поможет.
Если вы решите следовать маршруту раздела, имейте в виду, что для обеспечения эффективности все ваши запросы должны включать ваши ключи раздела, чтобы движок знал, какой раздел проверить. В противном случае он проверит их все, и вы фактически повредите производительности.
источник
Вы МОЖЕТЕ разбить на несколько ключей, если используете постоянный вычисляемый столбец; однако, как говорили другие, разбиение не работает для каждой ситуации. Я не уверен, что понимаю ваш сценарий достаточно, чтобы дать вам конкретный совет, но вот несколько общих рекомендаций:
Разделение полезно при чтении данных, когда ключ разделения является частью оператора SQL, что позволяет оптимизатору вызывать исключение разделов. Вы должны быть уверены, что выбранный вами ключ полезен для большинства запросов.
Одним из преимуществ хорошей стратегии разделения является устаревание данных; например, если ключ вашего раздела основан на дате (т. е. на дне года), и вы хотите удалить все данные, которые старше определенной даты, очень легко переключить эти разделы в пустую таблицу и усечь.
источник
Вы действительно должны определить свои требования немного более четко. Вы упомянули, что через 6 месяцев у вас будет около 360 миллионов строк. Как насчет 2 лет? Будете ли вы продолжать расти только с той скоростью, с которой вы в настоящее время растете? Или есть шанс, что вы будете испытывать экспоненциальный рост. Вы хотите сохранить данные в этой таблице навсегда; или вы хотите архивировать данные на регулярной основе.
Разделение может быть использовано для архивирования данных. Смотрите сценарий скользящего окна. Смотрите этот технический документ и этот .
Разделение также можно использовать для управления фрагментацией индекса. Вы можете перестроить / реорганизовать отдельные разделы.
Вы должны также рассмотреть разделенные представления в противоположность разделенным таблицам. Секционированные представления не требуют лицензии SQL Server Enterprise. Секционированные представления также позволяют выполнять перестроения индексов в режиме онлайн для определенного «раздела».
Разделение также может учитываться при планировании аварийного восстановления. Может использоваться для частичного восстановления базы данных. Например: ваши старые разделы могут быть в другой файловой группе, чем основной / текущий разделы. И затем, когда вы восстанавливаете, вы восстанавливаете основную файловую группу, затем файловую группу, в которой находятся ваши текущие разделы, и, наконец, вы можете восстановить файловые группы, в которых находятся старые разделы. Это может сократить время, в течение которого ваше приложение должно быть закрыто.
Посмотрите это отличное видео от Кимберли Триппа о разделах .
источник
Если вы не делаете разбиение из-за архивирования старых данных, вы делаете это по неправильной причине и не должны этого делать.
источник