Ринок СУБД для Сховищ даних 2007. Підсумки року, тенденції, Інші СУБД, Бази даних, статті

Короткий огляд ринку


Сьогодні можна вже з упевненістю говорити, що СУБД (DBMS, Data Base Management System) для Сховищ з традиційних засобів зберігання даних, що підтримують BI-користувачів, еволюціонували в аналітичні інфраструктурні репозиторії підприємств.
Ринок знаходиться в постійному русі, тому що, незважаючи на активні розробки та маркетингові кампанії великих постачальників, з’являються все нові і нові учасники. Багато організацій впроваджують технічно тонкі рішення, але більшість все-таки слід девізу: «простота впровадження, швидкий запуск, задоволення 80% вимог».


Звичайно, великі DBMS-постачальники за цей рік багато чого домоглися, намагаючись досягти балансу між масштабом та інноваційної функціональністю. Проте дрібні розробники часто пропонують більш цілеспрямоване і продумане рішення. Поки особливий статус і хороші шанси на виживання мають деякі компанії, що спеціалізуються в області пристроїв для ХД.


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


Серед традиційних лідерів на цьому ринку (IBM, Oracle, Teradata) тепер присутня і Microsoft SQL Server 2005. (Продукт Microsoft SQL Server 2008, вихід якого планується на першу половину 2008 року, забезпечить ряд нових можливостей, що відповідають вимогам до сучасної СУБД для ХД, а отже, зміцнить позицію виробника).
Для організацій, яким потрібно точкове рішення для конкретної аналітичної задачі або групи кінцевих користувачів, можуть виявитися корисними кошти Netezza, DatAllegro, Sybase і ряд інших.


Крім того, можна помітити, що ринок переходить від виконання звичайних функцій СУБД (у тому числі і підтримки аналітичних програм в реальному часі) до вирішення критично важливих для бізнесу задач шляхом автоматизації ключових процесів. Деякі постачальники, що ставлять перед собою саме таку задачу, за минулий рік істотно просунулися і займають лідерські позиції на ринку.
Прикладом може бути перенесення обчислювальних потужностей на рівень ближче до рівня зберігання (наприклад, вертикальні СУБД фірм Sand technology, Sybase IQ і Vertica підтримують ефективні підбір (sub-selection) збережених даних і скорочення введення / виводу). Крім того, розмір баз стає менш важливим. У минулому, покупці вважали, що лідером є постачальник СУБД, що підтримує найбільше сховище. Однак сьогодні і середні ХД (5-20Тбайт) вирішують основні аналітично завдання організації.


В цілому, всі ці проблеми ускладнюють завдання IT по задоволенню клієнтського бачення Сховища, в тому числі і за рівнем сервісу.
На думку експертів та аналітичних компаній, в новому 2008 році на ринку з’являться нові постачальники СУБД (наприклад, EnterpriseDB GridSQL, i-lluminate, ParAccel and Vertica), які сьогодні вже задовольняють численности, хоча і не всім вимогам.
Продовжується і «лихоманка» з пристроями для ХД, які вперше міцно зміцнилися на цьому ринку тільки в 2006 році. Успіх DATAllegro і Netezza на грунті надання преконфігурірованних, збалансованих рішень у вигляді пристроїв підстьобнув ряд виробників устаткування та програмного забезпечення до співпраці на даному ринку. У 2007 році ця тенденція отримала подальший розвиток. Наприклад, що з’явився в кінці 2006 року продукт, створений компанією Greenplum у співпраці з Sun, також зайняв гідне місце серед конкурентів.


Змішана навантаження


Ще більше значення набуває «змінюється змішана навантаження» (changing mixed workload), що впливає на ефективність ХД. Це одна з перших проблем, з якою стикаються постачальники і про яку ми вже згадували в торішньому огляді. Серйозні аналітики застосовують структуровані складні запити, а також швидко виконуються тактичні запити, що вимагає великих ресурсів процесорів, пам’яті і дискового простору. У всіх компаній свої вимоги до рівня сервісу, але з кожним роком тривалість затримки даних скорочується.


Підводячи підсумки за позаминулий 2006 рік, ми згадували чотири типи навантаження:



Сьогодні потрібно згадати ще два типи навантаження:



Шість типів навантаження ставлять перед постачальниками істотно більш складні завдання, ніж раніше. Найближчі 2-3 роки ефективність обробки змішаної навантаження залишиться найголовнішою проблемою. Критично важливою є і балансування фізичного переміщення даних в електронній та цифровому середовищі, розподілу дискових і оперативних ресурсів пам’яті.
У зв’язку з наростанням змішаної навантаження, що супроводжується безперервним завантаженням даних і зростанням числа автоматизованих транзакцій з функціональної аналітики в OLTP, отримають перевагу транзакційні СУБД, що дозволяють добитися більш високої ефективності в цій ситуації.


Оптимізація і ефективність


Ще один з ефектів зростаючої складності та обсягу даних полягає в тому, що компанії по-різному оцінюють необхідні ресурси для підтримки корпоративного Сховища і супутніх вітрин даних.


Частково, такі відмінності можна пов’язати з поєднанням:



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


В інших випадках оптимізація вимагає проектування і розробки фізичних таблиць, які формуються в результаті ETL-процесів в мікропакетах, протягом дня або навіть години. СУБД, раніше класифікуватися як «Общецелевие» (такі як DB2, Oracle та SQL-сервер), вимагають невеликих адміністративних ресурсів, оскільки постачальники автоматизували велику кількість службових і керуючих функцій. У той же час, навіть спеціалізовані DBMS вимагають більш автоматизованого системного управління. Так як обсяги даних, витягнутих з вихідних систем, коливається в середньому від 5 до 20 Тбайт, то особливо важливим у проектуванні ХД стає застосування галузевих стандартів.


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


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


У міру старіння ХД, співвідношення падає, тому що більш детальні обсяги даних не обов’язково вимагають додаткового простору для оптимізації. Крім того, оскільки розмір всього Сховища зростає, то обсяг простору для зберігання індексів починає падати і, відповідно, знижується і коефіцієнт. І тому дуже важлива робота з бізнес-підрозділами, щоб можна було виявити реальну необхідність у детальних даних і в підсумкових даних у Сховище. Багато клієнтів повідомляють про зберігання інформації за десять років, хоча на практиці цілком достатньо відомостей за останні п’ять років.


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


Нові розробки та оптимальні методики


Недавні розробки (2006-2007 рр..) Вказують на зростання популярності «розподілених Сховищ даних», що використовують єдину логічну модель з безліччю фізичних місць розташування. Дані логічно розділяються на домени (наприклад, всі записи, що стосуються окремого регіону, до всіх даних клієнтів з одного місця і т.п.) і розподіляються без дубльованих записів по різним точкам (locations). Причин для використання такого підходу безліч – починаючи від створення фізичних зон безпеки даних і закінчуючи аналітичними операціями, що грунтуються на тимчасових зонах. Не можна плутати цей підхід з інтегрованою моделлю (federated), яка включає дискретні логічні моделі з використанням таблиць транслітерації і є не найкращим практичним методом технології ХД.


У 2006 році (за ініціативою компанії Kognitio) з’явилася практика надання Сховищ даних як керованого сервісу. Постачальник СУБД розробляє і забезпечує функціонування Сховища на своєму сервері і пропонує його клієнту. Перші подібні проекти з’явилися на рівні бізнес-підрозділів (так як окремому підрозділу дешевше і зручніше придбати послугу, замість того щоб використовувати корпоративне сховище і постійно вдаватися до IT-і консалтинговим послугам).
Однак такі розробки не завжди були вдалими і економічними. У 2007 році дана модель була розширена: запропоновано (зокрема, компанією Greenplum) використання Сховища у вигляді послуги в масштабах організації. І тепер передбачається подальше розширення частки ринку, де буде застосовуватися така модель, особливо для конкретних відділів або специфічних DW-додатків. Ймовірно, все це переродиться в SaaS-модель (модель використання ПЗ в якості послуги) для організацій малого та середнього бізнесу, яким не вистачає досвіду і коштів для підтримки власного великого Сховища.


Вітрини даних


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


Крім того, останнім часом спостерігається зростання вітрин даних, спеціально використовуються в аналітичних цілях. Це пов’язано не тільки з аналітичної навантаженням Сховища, але і з тим, що ряд СУБД тепер володіє розвиненою аналітичної функціональністю, особливо СУБД, орієнтовані на зберігання даних по колонкам (ParAccel, Sand / DNA Analytics, Sybase IQ), які дають істотно вищі результати щодо ефективності в порівнянні з традиційними СУБД. Однак виконання складної системи запитів з множинними операціями об’єднання (joints) при такому підході дає аж ніяк не кращі, а іноді і гірші результати. Тому СУБД, де застосовується зберігання по колонках, не ідеальні для корпоративних Сховищ.


Висновок


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

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


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

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

Ваш отзыв

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

*

*