Розбиття SQL Server - що використовувати для ключа розділу?

Я ніколи не працював з розбиттям 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...

Крім того, я не впевнений у специфікації сервера баз даних, яка нам знадобиться. Чи вистачить 16gb та 8CPU? ДБ повинен мати можливість повернути результат з таблиці примірника купона, введеного на числове значення штрих-коду менше ніж за півсекунди. Очікуваний запит на транзакцію для підтвердження (вибору) та викупу (вставки) очікується, що він досягне приблизно 3500 за хвилину.

64-бітовий db-сервер SQL Server 2008r2 буде розглядатися як VM від дуже потужного хоста з доступом до високопродуктивної та великої ємності SAN.

Буду дуже вдячний за будь-які поради тих, хто розгорнув рішення SQL Server для управління подібними обсягами.

З повагою

Роб.

Питання щодо специфікацій сервера повинні бути спрямовані або на сервер за замовчуванням, або на DBA.SE.

Що стосується питання про розділення, я не думаю, що вам це потрібно не потрібно.

360м рядків - це багато, але це не надто громіздко.

Ви НЕ ні за яких обставин намагатися перегородці на основі останньої цифри поля. Я не впевнений, що це навіть спрацює, але це не SARGable, що не було б прийнятним.

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

Якщо ви все-таки вирішите продовжувати шлях до розділу, майте на увазі, щоб бути ефективними, усі ваші запити повинні включати ваш ключ (и) розділу, щоб двигун знав, який саме розділ потрібно перевірити. Інакше він перевірить їх усіх, і ви насправді зашкодите роботі.

МОЖЕТЕ розділити на декілька клавіш, якщо ви використовуєте збережений обчислюваний стовпчик; як казали інші, однак розділення не працює для кожної ситуації. Я не впевнений, що я досить добре розумію ваш сценарій, щоб дати конкретні поради, але ось кілька загальних рекомендацій:

• Розділення корисно при читанні даних, коли ключ розділення є частиною оператора SQL, що дозволяє оптимізатору викликати виключення розділів. Ви повинні бути впевнені, що обраний вами ключ корисний для більшості запитів.

• Однією з переваг хорошої стратегії розподілу є старіння даних; наприклад, якщо ваш ключ розділу на основі дат (тобто день року), і ви хочете видалити всі дані, які є старшими за певну дату, дуже просто ПЕРЕМЕГИТИ ці розділи в порожню таблицю і усікати.

Вам дійсно потрібно визначити свої вимоги трохи чіткіше. Ви згадуєте, що у вас буде близько 360 мільйонів рядків за 6 місяців. Як за 2 роки? Ви все ще будете рости лише тим темпом, який ви росте в даний час. Або є шанс, що ви відчуєте експоненціальне зростання. Чи хочете зберегти дані в цій таблиці назавжди; або ви хочете регулярно архівувати дані.

Розділення може використовуватися для архівації даних. Див. Сценарій розсувного вікна. Дивіться цю газету та цю .

Розділення може також використовуватися для управління фрагментацією індексу. Ви можете перебудувати / реорганізувати окремі розділи.

Ви також повинні розглядати розділені представлення на відміну від розділених таблиць. Розділені представлення не потребують ліцензії на SQL Server Enterprise. Перегляди з розділеними можливостями також дозволяють виконувати перебудову індексу в Інтернеті на певному "розділі".

Розділення може також враховуватися під час планування відновлення після аварій. Його можна використовувати для часткового відновлення бази даних. Наприклад: ви можете мати свої старі розділи в іншій групі файлів, ніж основна / поточна. І тоді, коли ви відновляєтесь, ви відновите первинну групу файлів, потім групу файлів, на якій розміщені ваші поточні розділи, а потім нарешті ви можете відновити групи файлів, на яких розташовані старі розділи. Це може скоротити кількість часу, коли ваша заявка повинна бути знищена.

Перегляньте це чудове відео з Кімберлі Трипп про перегородки .

Якщо ви не зробите розділення через архівування старих даних, ви робите це з неправильної причини і не повинні цього робити.