По-перше, зауважте, що 1 мільярд рядків можна ефективно обробляти за допомогою розділеної архітектури на звичайному апаратному забезпеченні сервера. Екзотичні архітектури для спільного використання нічого не знадобляться для цього обсягу даних, однак, ви, мабуть, отримаєте значні переваги від розподілу таблиць.
Шардінг - це щось інше, ніж горизонтальний розподіл, і передбачає архітектуру "нічого спільного", яка не підтримується більшістю версій SQL Server 1
SQL Server може підтримувати горизонтальний розподіл, і спільна архітектура диска буде достатньою для ~ 1 біллонових рядків.
У SQL Server ви створюєте функцію розділу, яка вибирає розділ на основі значень або діапазонів значень у стовпці таблиці, наприклад
create partition function F_AccPrdPart (int)
as range left for values (
180001 -- Dummy value
,199012 ,199112 ,199212 ,199312, 199412 ,199512
,199612 ,199712 ,199812 ,199912 ,200012 ,200112
,200212 ,200312 ,200412 ,200512 ,200612 ,200712
,200812
,200901, 200902, 200903, 200904, 200905, 200906
,200907, 200908, 200909, 200910, 200911, 200912
,201001, 201002, 201003, 201004, 201005, 201006
,201007, 201008, 201009, 201010, 201011, 201012
,201101, 201102, 201103, 201104, 201105, 201106
,201107, 201108, 201109, 201110, 201111, 201112
,202012
,939999 -- Dummy value
)
go
Потім створіть одну або кілька груп файлів, для яких слід розподілити розділи. Для великого набору даних ці групи файлів можуть бути створені на різних фізичних томах. Зауважте, що зберігання прямого приєднання буде набагато швидше, ніж SAN, для цього майже у всіх випадках. У наведеному нижче прикладі ми створили б 6 груп файлів під назвою PartVol1-PartVol6.
Одна або кілька схем розділів можуть бути створені для розподілу табличних розділів для груп файлів на основі значення функції розділу.
create partition S_AccPrdPart as partition F_AccPrdPart
TO ([PRIMARY]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2]
,[PRIMARY]
,[PRIMARY])
go
Ця схема розроблена для розподілу на обліковий період. Для цього також часто використовуються дати, хоча будь-який ключ можна використовувати.
Можна створити таблицю за схемою розділів так, ніби це була група файлів, наприклад
Create table FooTrans (
FooTransID int identity (1,1) not null
,AccPeriod int not null
,[...]
) on S_AccPrdPart (AccPeriod)
go
Зауважте, що таблиця створюється за схемою розділів замість визначеної групи файлів, а пункт визначає стовпець, який повинен використовуватися як ключ розділу. Виходячи з ключа розділу, рядки в таблиці будуть розподілені до однієї з груп файлів у схемі розділів.
Примітка. Основне правило для проектування схеми розділення полягає в тому, що кожен розділ повинен мати кількість рядків у низьких 10-х мільйонах, наприклад, від 10 до 50 мільйонів залежно від ширини рядків. Об'єм диска, на якому сидить розділ, повинен бути досить швидким, щоб здійснити сканування принаймні одного розділу за кілька секунд.
Системи розділення, заточення та загального користування
Здається трохи термінології для того, щоб тут відключити деякі дискусії з цієї теми.
Система "спільного нічого" - це паралельна система, де вузли не мають спільного сховища SAN, але використовують місце зберігання для локального вузла. Класичний приклад цього типу архітектури - Терадата. Системи, що діляться нічим, не мають масштабів для дуже великих наборів даних, оскільки вони не мають центральних вузьких місць. Шкала пропускної здатності вводу / виводу з кількістю вузлів у системі.
Система "спільного диска" - це система, де один або більше серверів баз даних поділяють одну підсистему зберігання диска. База даних може бути одним сервером з локальним сховищем або приєднаним до SAN, або кластером серверів, приєднаним до спільного SAN. Системи цього типу обмежені пропускною здатністю, доступною з підсистеми зберігання даних.
'Sharding' - термін, що використовується для опису поділу бази даних між декількома фізичними серверами в архітектурі загального користування. Різні платформи матимуть більшу або меншу підтримку шаруватих баз даних. У колах Teradata цей термін не використовується, оскільки Teradata представляє клієнтам прозоре єдине системне зображення, навіть якщо фізична архітектура не є загальним типом.
Старіші версії SQL Server мають обмежену підтримку загострення через розподілені перегляди в розділі. Тепер Microsoft створила версію SQL Server 2008 R2, яка підтримує архітектуру спільного використання нічого з єдиним системним зображенням, але ця версія доступна лише для виробників оригіналу та їх можна придбати лише в апаратному комплекті.
За 1 мільярд рядків
Для 1 мільярда рядків (за винятком випадків, коли окремі рядки надзвичайно широкі) загальнодоступна нічліжна або заштрихована архітектура зручно в царинах надмірності. Цей тип томів можна обробляти на одному сервері розумних специфікацій, якщо він має достатньо швидку підсистему диска.
Місцевий диск з прямим приєднанням - це на сьогоднішній день найбільш економічно ефективний з точки зору ціни на продуктивність. Один контролер RAID SAS може приймати кілька масивів, а на сервері може бути встановлено кілька контролерів. Залежно від конфігурації, сучасний масив SAS розміром 24-25 слотів може передавати тисячі IOPS або 1 ГБ + / сек у поточній продуктивності; сервер з декількома шинами PCI-e та декількома контролерами теоретично може обробляти більше.
Тип продуктивності, необхідної для роботи з базою даних на 1 мільярд рядків, можна досягти досить легко і дешево за допомогою апаратного забезпечення товарного сервера та прямого зберігання цього типу. Також може бути використаний SAN, але для отримання еквівалентної продуктивності вам може знадобитися кілька контролерів SAN, і апаратне забезпечення, ймовірно, буде на порядок дорожчим.
Як загальна рекомендація, використовуйте сховище прямого вкладення для додатків із великими вимогами вводу / виводу, якщо вам не потрібен справжній час роботи. Помилки керування конфігурацією та зміною є набагато більшим джерелом позапланового простою, ніж апаратні збої в сучасних центрах обробки даних.
SAN можуть надати вам більш керовану платформу зберігання, якщо у вас є великий асортимент програм, оскільки вони надають вам ряд централізованих засобів управління сховищами. Однак це досягає високої ціни, а отримання високої продуктивності інфраструктури на базі SAN важко і дорого.
1 Microsoft робить паралельну версію SQL Server, але вона доступна лише через OEM-канали в комплекті з обладнанням. Версії, доступні на полиці, не підтримують цю можливість.