Секціонованими таблиці та індекси SQL Server 2005

Для чого потрібно секціонування?

Перш, ніж говорити про те, як здійснювати секціонування і використовувати його можливості, спочатку потрібно зрозуміти, наскільки воно необхідне, що таке секціонування і кому варто його використовувати? Коли Ви створюєте таблиці, Ви проектуєте їх таким чином, щоб зберігати інформацію про сутності, наприклад, про покупців або продажах. Кожна таблиця повинна мати атрибути, які описують тільки цю сутність, і, наприклад, для всіх покупців і продажів історично склалося так, що всі Ваші покупці і всі Ваші продажу створюються у відповідних таблицях.
У той час як наявність однієї єдиної таблиці для кожної суті є найбільш простим підходом для проектування і розуміння, це може бути не кращим рішенням з точки зору продуктивності, масштабованості і керованості, особливо в тих випадках, коли таблиці стають досить великими. Секціонування може забезпечити переваги як для великих таблиць (і / або їх індексів), так і для таблиць, які мають змінюються моделі доступу. Більш того, секціонування великих таблиць підвищує їх масштабованість та керованість, а також спрощує використання таблиць при додаванні або видаленні значних фрагментів (або діапазонів) даних.


Так що ж являє собою велика таблиця? VLDB (Very Large Database) прийнято називати бази даних, сукупний розмір яких вимірюється сотнями гігабайт, або навіть терабайтами; однак цей термін ніяк не визначає індивідуальні розміри таблиць. Велика таблиця – це така таблиця, показники продуктивності або тимчасові витрати на обслуговування якої виходять за допустимі рамки. Крім того, таблицю можна вважати великою, якщо дії, вироблені одним користувачем, роблять значний вплив на іншого користувача, або якщо операції обслуговування бази даних впливають на можливості інших користувачів. Це призводить до обмеження доступності бази даних. Адже навіть при тому, що сервер продовжує залишатися доступним, як можна вважати Вашу базу даних доступною, коли робочі характеристики таблиці продажів значно погіршилися, або таблиця зовсім недоступна протягом всього періоду поточного обслуговування бази даних по 2 години на день, на тиждень, або нехай навіть на місяць? У деяких випадках регулярний простий все ж припустимо, але частіше за все простою можна уникнути або мінімізувати за рахунок поліпшення проектування.


Таблицю, модель доступу до якої змінюється, можна також вважати великою, коли підмножини (або діапазони) рядків цієї таблиці мають різні моделі використання. І хоча моделі використання не обов'язково повинні змінюватися (і це зовсім не є вимогою секціонування), коли моделі використання все ж змінюються, тоді можуть бути отримані додаткові переваги від секціонування. З точки зору продажів, дані поточного місяця зазвичай використовуються для читання / запису (read-write), в той час як дані попередніх місяців (і часто більша частина таблиці) – тільки для читання (read-only). Якщо у великих таблицях використання даних змінюється, або накладні витрати на обслуговування величезні, то це може обмежити здатність таблиці відповідати на різні запити користувачів, у свою чергу, обмежуючи і доступність і масштабованість. Крім того, особливо коли великі масиви даних використовуються по-різному, операції обслуговування можуть відмовитися від планового обслуговування статичних даних. Обслуговування даних, які в цьому зовсім не потребують – занадто дороге задоволення. Зайві витрати можуть позначитися на продуктивності, блокування, резервному копіюванні (дисковому просторі, часі і експлуатаційних характеристиках), а так само негативно впливати на загальну масштабованість сервера.
Крім того, в багатопроцесорних системах поділ великих таблиць призведе до поліпшення продуктивності за рахунок паралелізму. Великомасштабні операції над надзвичайно великими наборами даних (в мільйони рядків) можуть отримати вигоду з паралельної обробки незалежних підмножин даних. В якості простого прикладу поліпшення продуктивності при використанні секціонування може виступати агрегування (Угруповання) у попередніх версіях сервера. Наприклад, замість того, щоб групувати дані в одній великій таблиці, SQL Server може групувати їх у кількох секціях незалежно один від одного, і потім об'єднати агрегати. У SQL Server 2005, об'єднання можуть отримувати дані безпосередньо з секцій; SQL Server 2000, що підтримує паралельні об'єднання наборів даних, все ж таки повинен був створювати ці набори даних на льоту. У SQL Server 2005, зв'язані таблиці (наприклад, Order і OrderDetails), які розділені по одному і тому ж ключу секціонування та однієї і тієї ж функції секціонування, називаються вирівняними. Якщо оптимізатор SQL Server 2005 виявляє, що об'єднуються дві секціонованими і вирівняні таблиці, він може віддати перевагу об'єднати спочатку дані, які містяться в одних і тих же секціях, а потім об'єднати результати. Це дозволяє SQL Server 2005 більш ефективно використовувати багатопроцесорні системи.


Отже, чим же може допомогти секціонування? Там, де таблиці та індекси стають занадто великими, секціонування може допомогти, розщеплюючи великі масиви даних на менші, більш керовані "шматки" (тобто секції). Тип секціонування, описаного в цій статті, називають горизонтальним секціонуванням. При горизонтальному секціонування великі "шматки" рядків зберігаються у кількох окремих секціях. Архітектура секціонованими даних вибирається, настроюється і управляється згідно з вашими потребами. Секціонування в SQL Server 2005 дозволяє вам розділяти ваші таблиці, засновані на індивідуальних моделях використання даних, задаючи обмежені діапазони. І нарешті, SQL Server 2005 надає велике число настройок (опцій) для управління секціонованими таблицями та індексами, додаючи додаткові функції, спроектовані спеціально для нової концепції.


Не дивлячись на те, що секціонованими таблиці та індекси завжди були невід'ємною частиною великих баз даних, покликаної покращувати їх продуктивність і керованість, в Microsoft SQL Server 2005 з'явилися нові можливості, що спрощують процес розробки таких рішень. Даний доповідь присвячена еволюції секціонування таблиць в SQL Server: від ручного секціонування даних шляхом попереднього створення таблиць в якості підготовчого кроку (в SQL Server 7.0 і SQL Server 2000) до процедур реального секціонування таблиць. У SQL Server 2005 нові табличні функції секціонування значно спрощують розробку і адміністрування секціонованими таблиць, в місці з тим ще більше збільшуючи їх продуктивність.

Основне завдання статті – скласти для Вас уявлення про секціонування в SQL Server 2005, про те навіщо, де і як застосовувати його з більшою користю для Ваших надвеликих баз даних (VLDB – Very Large Database). Але незважаючи на те, що секціонування в SQL Server 2005 націлене насамперед на роботу з VLDB, слід пам'ятати, що не всі бази даних великі з самого початку. SQL Server 2005 забезпечує гнучкість і продуктивність, значно спрощуючи створення і обслуговування секціонованими таблиць. Прочитайте цю статтю, щоб отримати докладну інформацію про те, чому Вам варто знати про секціонованими таблицях, що вони можуть Вам запропонувати, і, нарешті, як розробляти, реалізовувати та обслуговувати секціонованими таблиці.


Історія секціонування


Концепція секціонування для SQL Server не нова. По суті, секціонування в різних формах було присутнє в кожному релізі. Однак, без функцій, які допомагають у створенні і підтримці вашої схеми секціонування, секціонування було незручним. А, як правило, якщо інструмент незручний в роботі, то й переваги від технології зменшуються. Тим не менш, з-за істотного виграшу в продуктивності, притаманного секционированию, з SQL Server 7.0 почалося його удосконалення, від секціонованими уявлень, підтримували деякі форми секціонування, до найбільш удосконалених секціонованими таблиць в SQL Server 2005.


Ручне секціонування об'єктів у версіях, що передували SQL Server 7.0


У SQL Server 6.5 і більш ранніх версіях, секціонування повинне було бути частиною вашого проекту, а заодно й побудоване у у всі ваші інструкції доступу до даних і запити. Шляхом створення декількох таблиць, і потім управління доступом до необхідних таблиць через збережені процедури, подання або клієнтські програми, ви могли часто поліпшити продуктивність деяких операцій, але за рахунок складності розробки. Кожен користувач і розробник повинні були знати і належним чином посилатися на відповідні таблиці. Кожна секція створювалася і управлялася окремо, а уявлення використовувалися, для спрощення доступу; тим не менш, це рішення давало деякі переваги. Коли для спрощення користувальницького та програмного доступу застосовувалося об'єднане подання (використовує посібник UNION), процесор запитів повинен був отримати доступ до кожної базової таблиці, щоб визначити, чи знаходиться в ній дані, необхідні для результуючої вибірки. Якщо для виконання запиту була необхідна тільки частина тих базових таблиць, то кожен користувач або розробник повинні були розбиратися в моделі даних, щоб посилатися тільки на необхідні таблиці.


Секціонованими подання до SQL Server 7.0


Основні претензії, які пред'являлися до ручного створення секцій у версіях, що передували SQL Server 7.0, стосувалися в першу чергу продуктивності. У той час як уявлення спростили розробку додатків, користувальницький доступ і написання запитів не спростилися. З випуском SQL Server 7.0, подання були об'єднані з обмеженнями цілісності, що дозволило оптимізатору запитів видаляти зайві таблиці з плану виконання запиту (тобто виключати секції) і значно зменшувати вартість плану виконання, коли об'єднане (UNIONed) подання зверталося до кількох таблиць.


На рисунку 1, зображена схема представлення YearlySales (річний товарообіг). Замість того щоб розміщувати всі продажі в одній-єдиній великій таблиці, Ви можете визначити дванадцять окремих таблиць, по одній на кожен місяць (SalesJanuary2003, SalesFebruary2003, і т.д.).



Малюнок 1: секціонованими подання до SQL Server 7.0/2000

Користувачі, які будуть звертатися до подання YearlySales з наступним нижче запитом, адресуватимуться ТІЛЬКИ до таблиці SalesJanuary2003.






SELECT ys.* 
FROM dbo.YearlySales
AS ys
WHERE ys.SalesDate = “20030113”
 

Поки обмеження цілісності є "довірчими" ("trusted"), і запити до уявлень використовують інструкцію WHERE для обмеження результатів вибірок, грунтуючись на ключі секціонування (стовпці, за яким визначено обмеження цілісності), до тих пір SQL Server буде звертатися тільки до необхідних базовим таблиць. "Довірче" обмеження цілісності – це обмеження цілісності, для якого SQL Server в змозі гарантувати, що всі його дані дотримуються властивостей, заданих обмеженням цілісності. За замовчуванням, обмеження цілісності створюється з опцією WITH CHECK. Цей параметр викликає блокування схеми таблиці для того, щоб дані могли бути звірені з обмеженням цілісності. Обмеження цілісності буде додано, як тільки верифікація перевірить достовірність існуючих даних, але якщо раптом блокування схеми буде видалена, наступні оператори INSERT, UPDATE і DELETE повинні будуть самостійно дотримуватись обмежень цілісності. Завдяки "довірчим" обмеженням цілісності, розробники можуть значно спростити створення уявлень, оскільки їм вже не потрібно безпосередньо звертатися до цікавлять їх таблиць. Завдяки "довірчим" обмеженнями цілісності SQL Server покращує продуктивність запитів, виключаючи непотрібні таблиці з плану виконання.


Примітка: обмеження цілісності може стати "не довіряє" ("untrusted") з кількох причин, наприклад, якщо при виконанні оператора bulk-insert не заданий аргумент CHECK_CONSTRAINTS. Як тільки обмеження цілісності стане "не довіряє", процесор запитів повернеться до сканування всіх базових таблиць, оскільки немає ніякого способу підтвердити, що запитувані дані дійсно розташовані в шуканої таблиці.


Секціонованими подання в SQL Server 2000


Не дивлячись на те, що SQL Server 7.0 значно спростив розробку і поліпшив продуктивність операторів SELECT, оператори модифікації даних не зазнали ніяких змін; оператори INSERT, UPDATE і DELETE підтримувалися тільки для базових таблиць, і не підтримувалися для вистав, які об'єднували набори даних (за допомогою оператора UNION). SQL Server 2000 дозволив операторам модифікації даних також отримувати вигоду з можливостей секціонованими уявлень, дозволяючи через уявлення модифіковані відповідні базові таблиці. І хоча існують додаткові обмеження на створення ключа секціонування, тим не менш, основний принцип полягає в тому, що не тільки оператори SELECT, але й оператори модифікації даних будуть направлятися безпосередньо відповідним базовим таблиць. За більш повною інформацією про обмеження, налаштуванню, конфігурації та деяких прийомах секціонування в SQL Server 2000 ви можете звернутися до статті: http://msdn.microsoft.com/library/techart/PartitionsInDW.htm


Секціонованими таблиці в SQL Server 2005


У той час як удосконалення SQL Server 7.0 і SQL Server 2000 значно поліпшили продуктивність секціонованими уявлень, вони не спрощували їх адміністрування, розробки або розгортання. Усі таблиці, на основі яких будувалося секціонованими уявлення, створювалися і керувалися окремо. Розробка додатків ставала простіше за рахунок того, що розробнику вже не доводилося звертатися безпосередньо до базових таблиць, проте адміністрування було утруднено, оскільки доводилося управляти кожною окремою таблицею, що входить до складу секціонованими уявлення, і його обмеженнями цілісності. Через складності управління, розділення таблиць часто використовувалося тільки тоді, коли дані потрібно було "заархівувати" або завантажити. Операції додавання / видалення з доступної тільки на читання таблиці (read-only) були занадто дорогими – вони займали час, місце в журналі транзакцій, і часто створювали блокування.
Крім того, оскільки попередні стратегії секціонування вимагали, щоб розробник створював індивідуальні таблиці та індекси і потім об'єднував їх шляхом подання, оптимізатору запитів було потрібно перевірити достовірність та визначити плани виконання для кожної секції (оскільки індекси могли змінитися). Тому час оптимізації запиту в SQL Server 2000 часто лінійно зростає зі збільшенням кількості секцій, що входять до подання, чого не відбувається в SQL Server 2005, де кожна секція за визначенням має одні й ті ж індекси.


Приміром, розберемо випадок, коли поточний місяць OLTP-даних (Online Transaction Processing), повинен бути переміщений в кінці місяця в OLAP-таблицю. Сама остання таблиця (призначена для запитів read-only) – Це одиночна таблиця з одним кластерним і двома некластерного індексами; масове завантаження (bulk load) 1GB даних (у вже проіндексовану і діючу таблицю) створює блокування з поточними користувачами крім того, що таблиця і / чи індекси стають фрагментованим і / або блокованими. Крім того, процес завантаження займе суттєвий час, оскільки таблиця й індекси повинні обслуговуватися в міру надходження кожного рядка. Є способи, що дозволяють прискорити bulk load, однак, вони можуть безпосередньо торкнутися всіх інших користувачів, таким чином, приносячи в жертву можливість паралельної роботи ради швидкості виконання. Якщо б ці дані додавалися до недавно створеної (порожню) таблицю, то спочатку могла б відбутися завантаження даних (у т.ч. паралельна завантаження), а потім побудова індексів (Можливо, також паралельне). Часто ви змогли б досягати 10-ти кратного (або ще більшого) переваги від використання даного підходу. Фактично, завантажуючи в неіндексовані таблицю (heap – купу), Ви можете скористатися перевагою багатопроцесорної системи, завантажуючи паралельно численні файли даних або численні "фрагменти" одного і того ж файлу (задані початковими і кінцевими рядками).


У будь-якому з випусків SQL Server секціонування дозволяє Вам управляти таблицями на більш високому рівні, не зобов'язуючи Вас зберігати всі дані в одному місці – з сильно фрагментованими індексами та відсутністю реального управління будь-яким аспектом поведінки на більш високому рівні. Функціональна стратегія секціонування могла бути досягнута в попередніх випусках, шляхом динамічного створення та видалення таблиць і модифікування UNION-уявлень. Проте в SQL Server 2005 рішення більш витончено: Ви можете просто "включити" ("switch in") нещодавно-наповнену секцію (і), як додаткову секцію до існуючій схемі секціонування, або "вимкнути" ("switch out") будь-яку стару секцію (и). Процес "включення / вимикання" секцій займає незначний час, і може бути навіть прискорений за рахунок застосування паралельної завантаження даних (bulk loading) і паралельного створення індексів. Що ще більш важливо, секція управляється з-за меж таблиці, таким чином, під час додавання нової секції на діючу таблицю не виявляється ніякого впливу. У результаті, додавання секції відбувається за лічені секунди.


Ще краще йдуть справи у разі, якщо дані необхідно видалити. Якщо база даних потребує тільки в "sliding window" ("ковзне вікно") наборі даних, то, коли нові дані будуть готові до переселення (Наприклад, в поточний місяць), тоді найбільш старі дані (наприклад, дані того ж місяця за попередній рік) зможуть бути видалені. У цьому випадку, Ви, ймовірно, досягнете поліпшення продуктивності від використання секціонування на кілька порядків. Оскільки це може здатися неправдоподібним, давайте розглянемо наявні тут відмінності.


Коли всі дані знаходиться в одній єдиній таблиці, видалення 1GB даних (найстаріших даних) вимагає порядкової маніпуляції даними та пов'язаними з ними індексами. Процес видалення даних приводить до істотної log-активності і не дозволяє обмежували журнал транзакцій до кінця видалення (пам'ятаєте, що видалення – це окрема auto-commit транзакція; тим не менш, Ви можете керувати розміром транзакції, виконуючи множинне видалення в одній транзакції там, де тільки можливо), а також потребує [потенційно дуже] більший журнал транзакцій. Щоб видалити таке ж кількість даних, видаляючи певну секцію з секціонованими таблиці, все, що треба зробити – це "вимкнути" секцію (що є операцією над метаданими), і потім видалити або усікти автономну таблицю.


А крім того, чи знаєте Ви, що використання файлових груп (filegroups) спільно з секціями є ідеальним механізмом секціонування? Файлові групи дозволяють Вам розміщувати окремі таблиці на різних фізичних дисках. Якщо окрема таблиця розташовується в декількох файлах, завдяки використанню filegroups, то тоді фактичне розташування даних передбачити неможливо. У системах, які не допускають паралельної обробки даних, SQL Server, завдяки застосуванню файлових груп, покращує продуктивність за рахунок використання всіх дисків більш рівномірно і тому конкретне розміщення даних у них не є настільки принциповим.


На Малюнку 2 представлена файлова група, що складається з трьох файлів. У ній розташовуються дві таблиці: Orders і OrderDetails. Коли дані таблиць розміщують у файловій групі, SQL Server пропорційно заповнює файли файлової групи, захоплюючи в них необхідне дисковий простір для своїх об'єктів екстент (шматками по 64 Kb, що дорівнює 8 сторінок даних по 8 Kb). У момент створення таблиць Orders і OrderDetails файлова група буде порожня. Коли приходить новий замовлення, в таблиці Orders створюється відповідний запис, і по одному запису в таблиці OrderDetails для кожного замовленого товару. SQL Server виділяє один екстент для таблиці Orders в File1, і потім ще один екстент для таблиці OrderDetails в File2. По всій імовірності, таблиця OrderDetails буде рости швидше, ніж таблиця Orders, і тому наступні кілька екстент будуть виділені для неї: наступний екстент для таблиці OrderDetails буде розташовуватися у файлі File3. На наведеному нижче малюнку продемонстровано розміщення екстент даних таблиць Orders і OrderDetails у файловій групі.



Малюнок 2. Пропорційне заповнення файлів


SQL Server і далі продовжить балансувати (врівноважувати) розміщення всіх об'єктів у межах цієї файлової групи. Поряд з тим, що SQL Server отримує вигоду від використання більшої кількості дисків для даної операції, це не так оптимально з точки зору управління або перспективи обслуговування (зайві незручності), або для ситуації, коли моделі використання досить передбачувані (і відособлені).


У SQL Server 2005 секціонованими таблиця може бути спроектована (використовуючи "функції" і "схеми") таким чином, щоб рядки, що мають однаковий ключ секціонування, розміщувалися б в строго вказаному місці. Функція секціонування визначає межі секцій і те, в яку секцію повинно бути занесено перше значення. У разі LEFT-функції, перше значення буде верхньою межею в першій секції. У разі RIGHT-функції, перше значення буде нижньою межею у другій секції. Ми ще розглянемо докладно особливості функцій секціонування далі в цій статті. Як тільки функція визначена, може бути створена схема секціонування для того, щоб визначити фізичне розташування секцій в базі даних. Якщо кілька таблиць використовують одну й ту ж функцію (але не обов'язково одну і ту ж схему), рядки, які мають один і той же ключ секціонування, будуть розташовуватися на диску разом. Цей принцип називається вирівнюванням. Вирівнюючи рядка декількох таблиць по ключу секціонування, SQL Server може (якщо оптимізатор запитів віддасть перевагу) працювати тільки з необхідними групами даних (у кожній з таблиць). Для того щоб вирівнятися, дві секціонованими таблиці або два індекси повинні мати деякий відповідність між їх відповідними секціями. Вони повинні використовувати "еквівалентні" функції секціонування й бути пов'язані по стовпцях секціонування. Дві функції секціонування можуть використовуватися для вирівнювання даних, якщо:



Увага! Навіть якщо дві функції секціонування розраховані на вирівнювання даних, ваші таблиці можуть залишитися не вирівняними з-за не вирівняних індексів, якщо вони не секціонованими за тими ж стовпцях, що і таблиці.


Локалізація (Collocation) – більш сувора форма вирівнювання, коли два вирівняних об'єкта об'єднані з предикатом equi-об'єднання (inner), де equi-об'єднання проводиться за стовпцем секціонування. Це стає важливим у контексті запиту, вкладені запити або іншої подібної конструкції, де можуть зустрітися предикати equi-об'єднання. Локалізація ефективна, оскільки запити, які об'єднують таблиці по стовпцях секціонування, виконуються тоді значно швидше. Візьмемо, наприклад, таблиці Orders і OrderDetails, описані вище. Замість того щоб заповнювати файли пропорційно, Ви можете створити схему секціонування, яка рознесе БД за трьома файловим групам. Ви визначаєте таблиці Orders і OrderDetails таким чином, щоб вони використовували одну і ту ж схему. Пов'язані дані (по ключу секціонування) будуть поміщені в один і той ж файлу, таким чином, ізолюючи необхідні для об'єднання дані. Коли пов'язані рядки з декількох таблиць секціонованими за одним і тим же принципом, SQL Server може об'єднувати секції, не маючи необхідності ритися у всій таблиці або декількох секціях (якщо до таблиць застосовувалися різних функцій секціонування) для зіставлення рядків. У цьому випадку, об'єкти не просто вирівняні, вони, як кажуть, є вирівняним сховищем, оскільки пов'язані дані розташовуються в одних і тих же файлах.


Наступний малюнок демонструє, як два об'єкти можуть використовувати одну і ту ж схему секціонування, коли всі рядки даних з однаковим ключем секціонування опиняться в одній і тій же файлової групі. Коли зв'язані дані вирівняні, SQL Server 2005 може ефективно працювати з великими наборами даних паралельно. Всі дані про продажі за січень (як для Orders, так і для OrderDetails) будуть розташовуватися в першій файлової групі, дані за лютий – у другій файлової групі і т.д.



Малюнок 3. Таблиці вирівняних сховищ


SQL Server підтримує секціонування, засноване на діапазонах. Таблиці, так само як і індекси можуть використовувати одну і ту ж схему для кращого вирівнювання. Гарне проектування здатне значно поліпшити продуктивність системи, але що, якщо використання даних весь час змінюється? Що, якщо буде потрібна додаткова секція? Простота адміністрування при додаванні і видаленні секцій, а також управління секціями ззовні секціонованими таблиці була головною метою при розробці SQL Server 2005.


SQL Server 2005 спростив секціонування для адміністрування, розробки та розгортання, а також для розуміння. Ось деякі з удосконалень в продуктивності і керованості:



Визначення і термінологія


Щоб створювати секції в SQL Server 2005, Вам необхідно познайомитися з декількома новими поняттями, термінами і синтаксисом. У попередніх випусках SQL Server таблиця була завжди фізичним і логічним поняттям, тепер в SQL Server 2005 для секціонованими Таблиць і Індексів у вас є на вибір кілька варіантів того, як і де зберігати таблицю. У SQL Server 2005, таблиці та індекси можуть бути створені з точно таким же синтаксисом, як і в попередніх релізах – як проста таблична структура, поміщена в DEFAULT filegroup або визначену користувачем файлову групу (user-defined filegroup). Крім того, в SQL Server 2005 таблиця і індекси також можуть бути засновані на схемі секціонування. Схема секціонування відобразить об'єкт на одну або можливо кілька файлових груп. Для визначення того, які дані де розміщувати, схема секціонування використовує функцію секціонування. Функція секціонування визначає алгоритм, використовуваний для маршрутизації рядків, а схема пов'язує секції з їх відповідним фізичним місцем розташування (тобто файлової групою). Іншими словами, таблиця, як і раніше є логічним поняттям, але її фізичне розташування на диску може радикально відрізнятися від більш ранніх випусків SQL Server; таблиця може мати схему.


Діапазонні секції


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


Основне застосування діапазонних секцій – архівування даних, підтримка прийняття рішень (коли найчастіше необхідні тільки певні діапазони даних, наприклад, тільки заданий місяць або квартал), і об'єднання OLTP і DSS (Decision Support System – система підтримки прийняття рішень), де використання даних змінюється протягом всього життєвого циклу запису бази даних. Найбільша перевага нової технології (особливо для архівування і обслуговування) полягає в здатності маніпулювати вкрай специфічними діапазонами даних. Діапазонні секції архівують старі дані і завантажують нові надзвичайно швидко. Секції діапазону найкраще підходять для ситуації, коли доступ до даних здійснюється для підтримки прийняття рішень і грунтується на великих діапазонах даних. У цьому випадку Ви дбаєте про те, де конкретно розташовані дані, так щоб звернення велося тільки до відповідних секціях. Коли з'являються нові бізнес – дані, Ви природно захочете додавати їх – легко і швидко.
Створення діапазонних секцій кілька ускладнено, оскільки вам буде потрібно визначити граничні умови для кожної секції. Ще ви повинні будете створити схему, що відображає кожну секцію на файлову (і) групу (и). Тим не менш, вони часто мають сумісний шаблон, так що, будучи якось визначені, вони, ймовірно, будуть легкі в програмній підтримці (див. рис. 4).



Малюнок 4: Діапазон секціонованими таблиця – 12 секцій.


Визначення ключа секціонування


Перший крок у секціонування таблиць та індексів полягає у визначенні "ключа". Ключ секціонування – це стовпець (и) таблиці, який відповідає визначеним критеріям. Функція секціонування визначає тип даних, на якому базується логічне розділення даних. Фізичне розміщення даних визначено схемою секціонування. Іншими словами, схема відображає дані на файлові групи, які в свою чергу відображають дані на конкретні файли. Для цього схема завжди використовує функцію – якщо функція визначає п'ять секції, тоді схема повинна використати п'ять файлових груп. Проте зовсім не обов'язково, щоб всі файлові групи були різними; тим не менш, Ви одержите більший виграш в продуктивності, якщо будете використовувати систему з декількох дисків, переважно багатопроцесорну. При використанні схеми ви визначаєте стовпець, який буде виступати в якості аргументу для функції секціонування.


Дані в діапазонних секціях розділені логічно. Фактично, секції даних в дійсності не можуть бути збалансовані взагалі. Проте використання даних нав'язує діапазонну секцію, оскільки модель використання цієї таблиці визначає спеціальні кордони для аналізу (інакше звані "діапазонами"). Ключ секціонування для діапазонною функції може складатися тільки з одного стовпця, і функція секціонування буде включати всю область даних, навіть якщо ці дані неприпустимі для таблиці. Іншими словами, межі визначені для кожної секції, але перша і остання секції дозволять включати нескінченно малі (перша) і нескінченно великі (остання) значення. Для секцій повинні бути задані обмеження цілісності CHECK для реалізації Ваших бізнес-правил та забезпечення цілісності даних (тобто обмеження області даних кінцевим, а не нескінченним діапазоном). Діапазонні секції ідеальні, коли обслуговування та адміністрування вимагають архівування великих діапазонів даних на регулярній основі, і коли запити звертаються до великих масивів даних – але тільки в межах декількох діапазонів.


Секціонування індексу


Секціонованими можна не тільки дані, але й індекси. Індекси можна секціонованими за допомогою тієї ж функції, що і базову таблицю, або будь-який інший. Однак з точки зору продуктивності найкраще розділяти таблицю і її індекси, використовуючи одну й ту ж функцію. Якщо таблиця і індекси використовують одну й ту ж функцію секціонування, і секціонувального по одних і тих же стовпцях (в тому ж порядку), така таблиця та індекси називаються вирівняними. Якщо індекс створюється за вже секціонованими таблиці, SQL Server автоматично вирівняє новий індекс згідно зі схемою секціонування таблиці, якщо тільки індекс явно не секціонованими по-іншому. Якщо таблиця та її індекси вирівняні, тоді SQL Server може переміщати секції всередині секціонованими таблиць більш ефективно, оскільки всі пов'язані дані та індекси розділені за одним алгоритмом.
Якщо таблиця і індекси визначені не тільки по одній і тій же функції, але і по одній і тій же схемі, тоді вони називаються вирівняним сховищем. Взагалі, якщо таблиці та індекси розташовуються в одному файлі або файлової групі, мультипроцесорні системи можуть отримувати додаткові переваги за рахунок паралельної роботи з секціями. У мультипроцесорних системах у разі вирівняних сховищ SQL Server може змусити кожен процесор працювати з певним файлом або файлової групою, і при цьому бути впевненим, що не буде конфліктів при доступі до даних, оскільки всі необхідні для об'єднання або пошуку по індексу дані будуть локалізовані на одному і тому ж диску. Це дозволяє більшій кількості процесів виконуватися паралельно без переривань.
Для одержання додаткової інформації по темі ви можете звернутися до розділу BOL: Special Guidelines for Partitioned Indexes.


Особливі режими секціонування – Split, Merge і Switch


У SQL Server 2005 для допомоги в управлінні секціонованими таблицями введено кілька нових понять. Оскільки секціонування застосовується до великих таблицями для забезпечення масштабованості і підтримки кращої продуктивності цих таблиць, досить імовірно, що кількість секцій, вибране у момент створення функції секціонування, з часом зміниться. Використовуючи оператор ALTER TABLE з новою опцією "Split" ("розщеплення"), Ви можете додати в таблицю нову секцію. Коли секція "розщеплюється", частина даних може бути перенесена в нову секцію, однак це не найкраще рішення з точки зору продуктивності. Нижче в цій статті буде наведено повний сценарій роботи режиму "split".


Навпаки, якщо необхідно видалити секцію використовуються режими "switch" ("переключення") і "merge" ("злиття"). "Злиття" діапазонних секцій виглядає як вказівка граничної точки, яку необхідно видалити. Якщо робота ведеться тільки з даними певного періоду, які регулярно проводиться архівування бази даних (наприклад, щомісяця), ви могли б архівувати одну секцію даних (самий ранній місяць) після додавання нової секції. Наприклад, Ви могли б побажати мати доступ до даних тільки одного останнього року; тоді в кінці кожного місяця ви б "включали" новий (поточний) місяць, і потім "вимикали" б найраніший місяць, таким чином, проводячи відмінності між read / write OLTP даними поточного місяця і read-only даними попередніх місяців, призначеними для аналізу. Однак, перш ніж Ви об'єднаєте граничну точку Ви повинні вимкнути її (пов'язані з нею) асоційовані дані, інакше злиття може стати дорогою операцією. Існує спеціальна методика, що дозволяє домогтися при цьому найбільшою ефективності. Поняття "switch", "merge" і "split" тільки на перший погляд дещо складними.


У даному сценарії у вас є read-only доступ до таблиці з даними за останній рік. В даний час у цій таблиці містяться дані з вересня 2003 по серпень 2004. Дані за поточний місяць, вересень 2004, знаходиться в іншій базі даних, оптимізованої для продуктивності OLTP (операцій реального часу). У read-only версії таблиці є 13 секції: дванадцять секцій, які містить дані (вересень 2003 – серпня 2004), і одна остання порожня секція (пам'ятаєте, що діапазонні секції включають весь діапазон значень – від нескінченно малого до безмежно великого). Таблиця могла б містити визначення CHECK constraint, для того щоб обмежити OrderDate значеннями з 1 вересня 2003 по 1 вересня 2004; це обмеження дозволить ефективно тримати останню секцію порожній.



Малюнок 5: Межі діапазонних секцій – перед завантаженням даних / архівацією

Коли починається жовтень (в базі даних OLTP), необхідно перемістити дані вересня в секціонованими таблицю, використовувану для аналізу. Включення / вимикання секцій в таблицю – дуже швидкий процес, до того ж, вся підготовча робота може бути виконана з-за меж секціонованими таблиці. Цей сценарій в подробицях описується в навчальному прикладі, який буде розглянуто трохи нижче. Його основна ідея полягає у використанні "каскадних таблиць", які в кінцевому рахунку стануть секціями у секціонованими таблиці ("включення" таблиці, що стає секцією в секціонованими таблиці) або будуть зберігати застарілі дані таблиці ("вимкнення" секції, стає автономною таблицею).


На Малюнку 6 показано "вимкнення" секції, стає окремо не секціонованими таблицею в тій же файлової групі, що й основна таблиця. Оскільки ця "несекціонірованная таблиця" вже існує усередині тієї ж файлової групи (і це є дуже важливим моментом), SQL Server може реалізувати це "переключення" як проста зміна метаданих. Вимкнення секції відбувається за лічені секунди, оскільки SQL Server повинен всього лише змінити метадані, на відміну від видалення, яке могло б зайняти годинник і створити блокування на великих таблицях. Як тільки ця секція "виключена", у вас все ще буде залишатися 13 секцій: перша (найстаріша) секція тепер порожня і остання (найсвіжіша, також порожня) секція повинна бути тепер "розщеплена".



Рисунок 11: Кроки по Створенню секціонованими Таблиці або Індексу


Визначте, ЧИ ПОТРІБНО секціонованими об'єкт


Як вже описано вище – це перший і самий важливий крок. Не кожна таблиця потребує секціонування. Не дивлячись на те, що секціонування прозоро з точки зору програми, воно ускладнює адміністрування та реалізацію ваших об'єктів. У той час як секціонування може запропонувати значні переваги, Ви напевно не станете до нього вдаватися для маленьких таблиць. Так що ж вважати великим, а що маленьким? Ваші вимоги до продуктивності та обслуговування, так само як і поточний стан цих показників – ось фактори, що визначають потребу в секціонування.
Приміром, архівування діапазону даних окремої таблиці продажів займає суттєвий час – хвилини (або більше) при додаванні нових записів (за допомогою INSERT … SELECT) або видалення старих даних (з допомогою DELETE … WHERE). Якщо ці операції створюють зайве навантаження на системні ресурси і продуктивність, тоді вам варто розглянути можливість секціонування, у противному випадку ви можете просто ускладнити адміністрування без істотної вигоди для себе.


Визначте ключ секціонування і кількість секцій


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


За більш докладною інформацією ви можете звернутися до розділу BOL: Designing Partitioned Tables and Indexes.


Визначте, ЧИ ВАРТО використовувати кілька файлових груп


З метою поліпшення продуктивності та спрощення обслуговування слід використовувати файлові групи (filegroups) для розділення даних. Кількість файлових груп частково продиктоване апаратними ресурсами, знаходяться у вашому розпорядженні; напевно вам захочеться мати таку ж кількість файлових груп, що і кількість секцій, і переважно ці файлові групи будуть розташовуватися на різних дисках. Однак, це в першу чергу відноситься до систем, де аналіз має тенденцію бути проведеним по всьому набору даних. Якщо у вашому розпорядженні знаходиться мультипроцесорна система, SQL Server може працювати з кількома секціями паралельно і тому значно скорочувати загальну тривалість обробки великих і складних звітів та аналітичних даних. У цьому випадку, Ви можете отримувати виграш в продуктивності при паралельній обробці даних, а так само при перемиканні секцій у секціонованими таблиці.


Створіть файлові групи


Якщо Ви хочете розмістити секціонованими таблицю в декількох файлах для поліпшення збалансованості підсистеми вводу / виводу, тоді вам слід створити файлову (і) групу (и). Файлові групи можуть складатися з одного або більше файлів, і кожна секція повинна відображатися на файлову групу. Одна файлова група може використовуватися декількома секціями, однак для кращого керування даними, наприклад, для більшої гранулюванні резервного копіювання, ви повинні розробляти ваші секціонованими таблиці продумано, так щоб тільки пов'язані або логічно згруповані дані розміщувалися в одній і тієї ж файлової групі. Використовуючи оператор ALTER DATABASE, Ви додаєте логічне ім'я файлової групи – тієї, до якої будуть додані файли. Щоб створити файлову групу з ім'ям "2003Q3" для навчальної бази даних AdventureWorks використовуйте наступний оператор:






ALTER DATABASE AdventureWorks ADD FILEGROUP [2003Q3]

 

Після того як ви створите файлову групу, використовуйте оператор ALTER DATABASE щоб додати файли у файлову групу.






ALTER DATABASE AdventureWorks
ADD FILE
(NAME = N”2003Q3″,
FILENAME = N”C:AdventureWorks2003Q3.ndf”,
SIZE = 5MB,
MAXSIZE = 100MB,
FILEGROWTH = 5MB)
TO FILEGROUP [2003Q3]

 

Таблиця створюється у файлі (ах), що визначає файлову групу; її місце розташування задається в розділі ON оператора CREATE TABLE. Однак без секціонування таблицю не можна розмістити в декількох файлових групах. Щоб створити таблицю на основі однієї файлової групи, ви використовуєте вираз ON оператора CREATE TABLE. Щоб створити секціонованими таблицю, Ви спочатку повинні визначитися з логікою секціонування. Навіть при тому, що ви можете визначати логічні секції для конкретної окремо взятої таблиці, SQL Server дозволяє Вам повторно використовувати визначення секцій і для інших об'єктів. Щоб відокремити поняття "Секція" від поняття "таблиця" Ви створюєте структуру секцій за допомогою функції секціонування. Тому перший крок у секціонування таблиці полягає у створенні функції секціонування.


CREATE PARTITION FUNCTION для діапазонних секцій


Діапазонні секції повинні бути визначені з граничними умовами. Крім того, всі межі повинні бути включені; функція діапазонною секціонування повинна включати всі значення навіть при тому, що діапазон значень таблиці може бути (і повинна бути) більш обмеженим (за допомогою CHECK constraint). Ніякі значення (з будь-якого кінця діапазону) не повинні бути виключені. Крім того, оскільки дані, імовірно, будуть додаватися і віддалятися з секції, вам буде потрібно остання порожня секція, яку ви зможете постійно "розщеплювати", виділяючи тим самим місце для нової секції даних. Ця остання секція буде завжди залишатися порожньою, перебуваючи в очікуванні нових записів, які ви будете періодично в неї включати.


При діапазоні секціонування спочатку визначають граничні точки. Якщо Ви визначаєте п'ять секції, то будуть потрібні тільки чотири граничні точки. Для того щоб розділити дані на п'ять груп, Ви визначаєте чотири граничних значення для секцій, а потім визначаєте, який з секцій буде належати кожне з цих значень: перша (LEFT) або другий (RIGHT).


У Вас завжди буде одна секція (крайня права для LEFT-функції, або вкрай ліва для RIGHT-функції), у якої не буде явно заданої граничної точки. Це пояснення може здатися дещо заплутують, проте пам'ятайте, що функція секціонування включає всі значення даних (- нескінченність зліва і нескінченність праворуч).
Визначаючи режим LEFT або RIGHT, Ви визначаєте, чи є граничне значення верхньою межею першої секції (LEFT) або нижньою межею другої секції (RIGHT). Іншими словами, якщо перше значення (граничне умова) функції секціонування буде "20001001", тоді значення в межах сусідніх секцій розподіляться так:



Оскільки Ваші діапазонні секції напевно будуть визначатися по стовпцях з типом даних datetime, то вам слід знати про імплікації (implication – "залучення").


Примітка: Імплікація (від лат. Implico – тісно пов'язую) – приблизний логічний еквівалент обороту "якщо …, то …"; операція, формалізуються логічні властивості цього обороту.


Застосовуючи тип даних datetime, Ви завжди використовуєте ОДНОЧАСНО і дату і час. Дата без певного значення часу увазі нульовий час – 12:00 am. Якщо, приміром, LEFT-функція базується на цьому типі даних, то тоді дані за 1 жовтня 12:00 am потраплять у 1-у секцію, а інша частина жовтня – у 2-у. За логікою, краще всього використовувати початкові значення (набору даних другій секції) з RIGHT-функцією і кінцеві значення (набору даних першої секції) з LEFT-функцією. Три наступні висловлювання створюють логічно ідентичні структури секціонування:






RANGE LEFT FOR VALUES (“20000930 23:59:59.997”,
“20001231 23:59:59.997”,
“20010331 23:59:59.997”,
“20010630 23:59:59.997”)
OR
RANGE RIGHT FOR VALUES (“20001001 00:00:00.000”,
“20010101 00:00:00.000”,
“20010401 00:00:00.000”,
“20010701 00:00:00.000”)
OR
RANGE RIGHT FOR VALUES ("20001001", "20010101", "20010401", "20010701")

 

Примітка: Використання типу даних datetime додає складності, оскільки Ви повинні будете упевнитися в тому, що встановили правильні граничні значення. У випадку з RIGHT-функцією все гранично просто, тому що час за умовчанням дорівнює 12:00:00.000 am. Для LEFT додаткова складність зумовлена точністю типу даних datetime. Причина, по якій ви ПОВИННІ вибирати в якості граничного значення 23:59:59.997, полягає в тому, що тип даних datetime не гарантує точність в 1 мілісекунду. Замість цього, datetime-дані абсолютно точні в межах 3.33 мілісекунд. Значення такту таймера процесора (Tick) однакову 23:59:59.999 не доступно для SQL Server, замість цього значення округляється до найближчого такту, яким є 12:00:00.000 am наступного дня. Через таке округлення кордони можуть бути невірно визначені. Проявляйте обачність при завданні значень в мілісекундах для типу даних datetime.


Примітка: Функції секціонування також дозволяють як визначення використовувати інші функції. Ви можете використовувати функцію DATEADD (ms, -3, "20010101") замість явного визначення "20001231 23:59:59.997".


За додатковою інформацією зверніться до розділу BOL: "Date and Time" in the Transact-SQL Reference.


Для того щоб зберігати по одній чверті даних таблиці Orders в чотирьох активних секціях (які мають календарні квартали) і мати п'яту секцію для подальшого використання (як полігон для долучення / виключення даних з секціонованими таблиці), використовуйте таку LEFT-функцію секціонування з чотирма граничними умовами:






CREATE PARTITION FUNCTION OrderDateRangePFN(datetime)
AS
RANGE LEFT FOR VALUES (“20000930 23:59:59.997”,
“20001231 23:59:59.997”,
“20010331 23:59:59.997”,
“20010630 23:59:59.997”)

 

Пам'ятайте, що чотири граничні точки створюють 5 секції – з однієї порожньої секцією праворуч, якщо функція секціонування визначена як LEFT, і одним порожнім секцією ліворуч, якщо функція визначена як RIGHT. Подивіться які набори даних створюються цією функцією секціонування:



Незалежно від моделі (LEFT або RIGHT), функція діапазонною секціонування повинна включати всі значення: від нескінченно малого до безмежно великого. Для функції LEFT остання гранична точка визначить Останнім абсолютне значення секцій, але оскільки функція повинна охоплювати всю область даних, то для значень, більших ніж значення останньої граничної точки, повинна існувати заключна секція. При використанні LEFT-функцій завжди буде існувати одна додаткова секція в кінці, і одна додаткова секція спочатку – для RIGHT-функцій.


CREATE PARTITION SCHEME


Як тільки Ви створили функцію секціонування, Ви повинні пов'язати її зі схемою секціонування, для того щоб адресувати секції певним файловим групам. Коли Ви визначаєте схему секціонування переконайтеся, що Ви визначили файлові групи для КОЖНОЇ секції, навіть якщо кілька секцій будуть розташовуватися в одній і тій же файлової групі. Створена раніше функція OrderDateRangePFN формує 5 секцій, остання (порожня) буде розташовуватися у файловій групі PRIMARY. Немає ніякої необхідності в особливому розміщенні цієї секції, оскільки вона ніколи не буде містити даних.






CREATE PARTITION SCHEME OrderDatePScheme
AS
PARTITION OrderDateRangePFN
TO ([2000Q3], [2000Q4], [2001Q1], [2001Q2], [PRIMARY])

 

Примітка: Якщо всі секції повинні розташовуватися в одній і тій же файлової групі, то в цьому випадку можна застосовувати спрощений синтаксис:






CREATE PARTITION SCHEME OrderDatePScheme
AS
PARTITION OrderDateRangePFN
ALL TO ([PRIMARY])

 

Створіть секціонованими таблицю


Тепер, коли логічна (функція секціонування) і фізична (схема секціонування) структури визначено, таблиця може бути секціонованими. Таблиця визначає, яка "схема" повинна використовуватися, а схема визначає функцію. Для того щоб пов'язувати ці три поняття разом, Ви повинні визначити стовпець (и) секціонування. Діапазонні секції завжди відображаються виключно на один стовпець таблиці, сумісний з типом даних граничних умов, визначених у функції секціонування. Крім того, якщо в таблиці необхідно спеціально обмежувати інтервал допустимих значень (а не [-; +]), то слід додати обмеження цілісності (check constraint).






CREATE TABLE [dbo].[OrdersRange]
(
[PurchaseOrderID] [int] NOT NULL,
[EmployeeID] [int] NULL,
[VendorID] [int] NULL,
[TaxAmt] [money] NULL,
[Freight] [money] NULL,
[SubTotal] [money] NULL,
[Status] [tinyint] NOT NULL,
[RevisionNumber] [tinyint] NULL,
[ModifiedDate] [datetime] NULL,
[ShipMethodID] [tinyint] NULL,
[ShipDate] [datetime] NOT NULL,
[OrderDate] [datetime] NOT NULL
CONSTRAINT OrdersRangeYear
CHECK ([OrderDate] >= “20030701”
AND [OrderDate] <= “20040630 11:59:59.997”),
[TotalDue] [money] NULL
)
ON OrderDatePScheme (OrderDate)
GO

 


Створіть індекси: секціонованими або звичайні


За замовчуванням індекси, що створюються в секціонованими таблиці, будуть використовувати ту ж саму схему секціонування і стовпець секціонування, що і таблиця. У цьому випадку індекс буде "вирівняний" по відношенню до таблиці. Вирівнювання не є обов'язковою умовою, тим не менш, часто бажано, щоб таблиця та індекси були вирівняні. Вирівнювання таблиці та її індексів забезпечує більш легке управління та адміністрування, особливо при роботі за сценарієм "ковзного вікна". Не дивлячись на це, індекси не обов'язково повинні бути вирівняні. Індекси можуть бути засновані на інших функціях секціонування або не бути секціонованими зовсім.


Наприклад, у разі, коли створюються унікальні індекси, стовпець секціонування повинен бути одним з ключових шпальт; це буде гарантувати те, що для забезпечення унікальності потрібно перевірити тільки підходящу секцію. Тому, якщо Вам необхідно секціонованими таблицю по одному стовпцю, а створити унікальний індекс по іншому стовпцю, то тоді вони не зможуть бути вирівняні; індекс може бути або секціонованими за унікальним стовпцю (якщо унікальний ключ базується на кількох стовпцях, то тоді це може бути будь-який з ключових стовпців), або взагалі не секціонованими. Запам'ятайте, що цей індекс повинен бути видалений і створений заново, якщо якісь дані "включаються" або "виключаються" з секціонованими таблиці.


Примітка: Якщо Ви плануєте завантажити таблицю c існуючими даними і потім додати до неї індекси, то найчастіше найбільш ефективним способом буде завантаження даних в НЕ секціонованими, НЕ індексовану таблицю з наступним створенням індексів і секціонуванням таблиці. Засновуючи кластерний індекс на схемі секціонування, ви тим самим ефективно секціоніруете таблицю. Це прекрасний спосіб секціонування таблиць. Для того щоб створити таблицю як НЕ секціонованими, а кластерний індекс як секціонованими кластерний індекс, замініть визначення ON оператора CREATE TABLE на одну-єдину файлову групу і потім, після того як дані будуть завантажені, створіть кластерний індекс на основі схеми секціонування.


Зберемо все докупи: конкретні приклади


Після знайомства з концепцією, перевагами і невеликими фрагментами коду, пов'язаного з секціонуванням, у вас вже напевно склалося достатнє розуміння процесу секціонування. Однак для кожного з кроків доступні специфічні параметри налаштування та опції, які в певних випадках повинні задовольняти різноманітними критеріями. Наступна частина статті допоможе Вам поєднати всі отримані Вами знання воєдино.


Секціонування діапазону – відомості про продажі


Характер використання відомостей про продажі часто мінливий. Як правило, дані поточного місяця – це оперативні дані, дані попередніх місяців – це великою мірою дані, призначені для аналізу. Найчастіше аналіз проводиться щомісяця, щокварталу, або щорічно. Оскільки різним аналітикам можуть знадобитися значні обсяги різних аналітичних даних одночасно, то секціонування краще за все дозволить ізолювати їх діяльність. У розглянутому далі сценарії дані стікаються з 283 вузлів і поставляються у вигляді двох файлів стандартного формату ASCII. Всі файли відправляються на центральний файл-сервер не пізніше 3.00 am першого дня кожного місяця. Розміри файлів коливаються, але в середньому складають приблизно 86.000 замовлень на місяць. Кожне замовлення в середньому становить 2.63 позиції, тому файли OrderDetails складають в середньому по 226180 рядків. Кожен місяць додається приблизно 25 мли

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*