Продуктивність сховищ даних: нові реалії, Інші СУБД, Бази даних, статті

Останні десять років кардинальним чином змінили ринок сховищ даних. На початку нинішнього століття більшість сховищ даних використовувалося для генерації декількох звітів, пакетного завантаження даних, запускається раз на день або навіть на тиждень, і час від часу для обробки декількох нерегламентованих запитів, що надійшли від невеликої групи користувачів. Сьогодні складні інтеграційні інструменти дозволяють інтегрувати дані практично в режимі реального часу, все більше і більше користувачів застосовують зручні в обігу кошти Business Intelligence. Нарешті, обсяги даних, що завантажуються в сховище, ростуть з неймовірною швидкістю і, здається, ніколи не досягнуть свого межі. Так, за оцінкою дослідницької компанії WinterCorp, великі сховища даних збільшуються втричі кожен дві року. Згідно з опитуванням серед корпоративних IT-фахівців в області сховищ даних, проведеним Інститутом Сховищ даних (The Data Warehousing Institute, TDWI), до 2012 року 59% з числа опитаних очікують, що їх сховище даних перевищить 3Тб.


Всі ці фактори призводять до того, що продуктивність сховищ даних останні роки починає падати, і сьогодні проблема продуктивності виходить на перший план. Як відзначають аналітики Gartner, в найближчі роки всі споживачі сховищ даних в тій чи іншій мірі зіткнутися з цією проблемою. У Gartner навіть ввели спеціальний термін – змішана навантаження, який відображає впливу зміни, що відбулися за останні роки – зростання обсягів даних, ускладнення запитів і т.д. (Докладніше див "Ринок СУБД для Сховищ даних 2007. Підсумки року, тенденції“).


Яким чином можна оцінити продуктивність сховища даних? Сьогодні експерти – члени консорціуму TCP1– Пропонують при оцінці продуктивності системи враховувати наступні параметри:



Стандарти оцінки продуктивності


Продуктивність сховища даних завжди була важливим питанням. Ще в далекому 1994 році консорціум TCP випустив свою першу специфікацію для оцінки продуктивності аналітичних систем – TCP-D. Даний документ визначав параметри оцінки і регламентував порядок проведення тестування продуктивності.


Критерії оцінки, закладені в TCP-D, пред'являли серйозні вимоги до технологій того часу – як до апаратної, так і програмної складової (СУБД). Відповідно до вимог стандарту тестуванню піддавалися сховища даних в третій нормальній формі, що містять 8 таблиць. З урахуванням очікуваного зростання даних, TCP-D передбачав збільшення необроблених даних від 1 Гб до 3 Тб, при яких підсистеми введення-виведення повинні були досягти меж своїх можливостей. При оцінюванні сховищ даних використовувалися зумовлені розміри баз даних, або коефіцієнти масштабування. Кожен коефіцієнт відповідав заданим обсягом необроблених даних в сховищі. Для оцінки оптимізаторів запитів використовувати 17 складних, довго виконуваних запитів, а також дві функції супроводу даних (insert і delete). Шість з восьми таблиць збільшувалися пропорційно коефіцієнту масштабування і заповнювалися даними, які були рівномірно розподілені.


Подальше широке поширення агрегатних / підсумкових структур (наприклад, індексів об'єднання, підсумкових таблиць, аналітичних вибірок), які не були закладені в TCP-D, привели до поява двох його модифікацій – TCP-H (стандарт оцінки продуктивності систем з нерегламентованими запитами) і TCP-R (стандарт оцінки продуктивності систем для випуску звітності) в квітні 1999 року.


У нових стандартах були додані шість нових запитів, а коефіцієнт масштабування збільшений до 10Тб. В іншому TCP-H та TCP-R ідентичні своєму попереднику. Різниця ж між TCP-H та TCP-R складається в наявності інформації про навантаження, яка буде використана для оцінки системи. TCP-H призначений для середовища, при роботі з якою адміністратори бази даних не знають, які запити будуть передані в систему. Отже, знання про запити і даних не можуть бути використані для оптимізації СУБД. При застосуванні TCP-R передбачається наявність вихідної інформації про запити, що може бути використане для визначення агрегатних / підсумкових структур. Оскільки TCP-R не отримав як значимого уваги, в січні 2006 року він був визнаний таким, що втратив силу.


На відміну від TCP-R стандарт TCP-H набув широкого поширення і активно використовується до цих пір. У грудні 2007 року кількість тестів, виконаних відповідно до цього стандарту, перевищила дві сотні. Наприклад, в серпні минулого року корпорація Oracle заявила про вражаючих результати тестування сховища даних на своїй СУБД Oracle Database 11g.


Основною величиною, за якою оцінюється продуктивність системи, є показник QphH @ size (Composite Query-per-Hour Performance Metric at Size – складний показник продуктивності запити, виконані за годину, на заданому обсязі даних), який відображає обчислювальні можливості системи по обробці запитів. Крім, даного показника при публікації результатів тестування в обов'язковому порядку вказується вартість системи для даного показника QphH @ size (виходячи з використовуваної при тестрірованіі програмно-апаратної конфігурації), дата випуску системи та інші додаткові характеристики, наприклад, час завантаження даних.


Нові стандарти оцінки продуктивності: фокус на завантаженнями


Навряд чи хтось стане заперечувати, що вимоги, що пред'являються сьогодні до систем сховищ даних, зазнали істотних змін з тих пір, коли був розроблений TCP-D і його "приймач" TCP-H. Саме тому, щоб продовжити життя TCP-H консорціум TCP збільшив розміри обсягів даних за допомогою ще двох коефіцієнтів масштабування – 30,000 і 100,000, що відповідає 30Тб і 100Тб необроблених даних.


Разом з тим, відмінності між сьогоднішніми системами сховищ даних і ті, для оцінки яких був спроектований TCP-H, істотні і різноманітні. Наприклад, схема сховища даних, яка була задовільно складною для тестування систем в 1999 році, не відображає сучасні реалії побудови складних аналітичних систем. Сьогоднішні схеми включають набагато більшу кількість таблиць і пішли від чистого третій нормальній формі до різновидів схеми типу "зірка".


Саме тому TPC розробив і випустив у січні 2006 року робочу версію нового стандарту TPC-DS, робота над якою триває і сьогодні.


Основними характеристиками розроблюваного стандарту є:



Останній пункт заслуговує окремої уваги. TPC-DS відводить головне місце можливості системи включати нові дані про міру зростання обсягів вихідних даних. Очевидно, що включення до складу тесту операцією по роботі з даними (трансформацією на основі SQL) дозволяє говорити про TPC-DS як про перший галузевому стандарті для оцінки ETL-процесів (рис. 1).


Так, на відміну від стандарту TCP-H у розрахунку основного параметра оцінки продуктивності системи по TPC-DS (Query-per-Hour Performance Metric at Scale Factor – показник продуктивності запити, виконані на годину, при заданому коефіцієнті масштабування) враховується як час створення бази даних (завантаження даних), так і час на супровід даних (процеси ETL):



де TQR1 – Час на виконання запитів першої серії,
TQR2 – Час на виконання запитів другої серії,
TDM – Час на виконання операцій по підтримці даних,
TLoad – Час на тестування завантаження бази даних,
S – число потоків, які виконуються при оцінці продуктивності,
SF – коефіцієнт масштабування. Проведення тестування системи відповідно до TPC-DS передбачає виконання наступній послідовності дій (див. рис. 1. Схема проведення оцінки продуктивності сховища даних у відповідності зі специфікацією TPC-DS ):


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


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


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


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



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


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


На закінчення варто зазначити, що актуальність процесів завантаження даних привела до того, що консорціум TPC перейнявся розробкою окремої специфікації для тестування ETL-процесів. Так, у 2008 році був сформований комітет з метою підготовки стандарту для порівняння різних ETL-систем.


Публікації



  1. Магічні квадранти Gartner для СУБД Сховищ даних, 2009 рік (Gartner Magic Quadrant for Data Warehouse Database Management Systems, 2009).
  2. Філіп Рассом (Philip Russom). Звіт про дослідження TDWI: "Платформи Сховищ даних наступного покоління" (Next Generation Data Warehouse Platforms). 3-й квартал 2009 року.
  3. Річард Вінтер (Richard Winter). "Масштабування сховища даних" (Scaling The Data Warehouse). Information Week. 17.10.2008.
  4. Джефф Келлі (Jeff Kelly) "Рішення проблеми експлуатації перевантажених сховищ даних: інструменти управління навантаженням -" (Workload management tools key to running busy data warehouses), 13.04.2010.
  5. Рагхунатх Намбіар (Raghunath Nambiar), Мейкел Поусс (Meikel Poess). "Створення TPC-DS" (The Making of TPC-DS).
  6. Мейкел Поусс (Meikel Poess), Рагхунатх Намбіар (Raghunath Nambiar), Девід Уолраф (David Walrath). "Навіщо використовувати TPC-DS: аналіз навантаження" (Why You Should Run TPC-DS: A Workload Analysis).

[1] Консорціум TPC (Transaction Processing Performance Council) – некомерційна організація, створена з метою розробки стандартів тестування продуктивності транзакційних систем і систем для підтримки прийняття рішення (сховищ даних), а також поширення результатів тестування.

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


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

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

Ваш отзыв

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

*

*