Секціонірованние таблиці та індекси SQL Server 2005, Інші СУБД, Бази даних, статті

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


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


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


Таблицю, модель доступу до якої змінюється, можна також вважати великою, коли підмножини (або діапазони) рядків цієї таблиці мають різні моделі використання. І хоча моделі використання не обов’язково повинні змінюватися (і це зовсім не є вимогою секціонування), коли моделі використання все ж міняються, тоді можуть бути отримані додаткові переваги від секціонування. З точки зору продажів, дані поточного місяця зазвичай використовуються для читання / запису (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, і ​​т.д.).

Рисунок 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 складають в середньому по 226 180 рядків. Кожного місяця додається приблизно 25 мли

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


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

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

Ваш отзыв

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

*

*