Комерційні СУБД: еволюція чи революція?, Інші СУБД, Бази даних, статті

Марк Рівкін

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

Серед безлічі сучасних універсальних промислових СУБД сьогодні можна виділити трьох лідерів, які займають більше 90% світового ринку СУБД. Це СУБД першого ешелону – IBM DB2, Microsoft SQL Server і Oracle. У список СУБД другого ешелону входять Adabas, Cache, Firebird, Informix, Ingress, Interbase, Progress, Postgres, Sybase, Teradata, Лінтер і ряд інших. Існують СУБД для нішевих рішень, і постійно з’являються прототипи нових спеціалізованих СУБД: об’єктно-орієнтовані СУБД, ХML СУБД, СУБД для обробки потокових даних, СУБД для роботи з текстами і т.д.


Для формування прогнозів розвитку галузі, раз на кілька років збираються групи провідних фахівців в області СУБД і випускають звіти: Клермонтський звіт (травень 2008) [1], Лоуельскій звіт 2003 [2], Ассіломарскій звіт 1996 [3], звіт зборів в Лагуна-Біч 1989 [4]. Правда, велика частина цих прогнозів так і не збувається – виробники СУБД зазвичай керуються своїми власними міркуваннями. Більш прагматичний підхід до передбачення тенденцій на основі аналізу поточного стану і планів розвитку трійки продуктів, що лідирують на ринку СУБД, – аналіз стану та перспектив розвитку IBM DB2 9.5 і Cobra, MS SQL Server 2008 і Oracle 11.1 і 11.2 дозволяє робити цілком реалістичні прогнози тенденцій розвитку універсальних комерційних СУБД.


Революції не буде


За останні кілька років з’явилася серія статей Майкла Стоунбрейкера, в яких проголошується прийдешня революція в області СУБД і передвіщається швидка кончина універсальних комерційних СУБД [5-8]. Стоунбрейкера обгрунтовує свою позицію тим, що сучасні універсальні комерційні СУБД постійно збільшують свій функціонал без переписування ядра, в результаті чого стають складними (ніхто сьогодні не знає і не використовує весь наявний функціонал), громіздкими, повільними і дорогими. Гряде, на думку Стоунбрейкера, епоха спеціалізованих СУБД, які витіснять універсальні. Дане твердження ілюструється на прикладі продукції декількох стартапів (StreamBase, Vertica, ASAP, H-Store), що демонструють на спеціалізованих застосуваннях продуктивність на один-два порядки вище, ніж сучасні промислові дискові СУБД.


При найближчому розгляді виявляється, що багато хто з наведених Стоунбрейкера результатів не зовсім коректні. Наприклад, при тестуванні СУБД Vertica зі зберіганням даних по колонках використовується таблиця з більш ніж 200 шпальт, з якої вибирають лише кілька. Зрозуміло, що тут традиційна СУБД працює набагато повільніше, але і будь-яка операція вибірки записів з розумним числом полів з цієї таблиці на Vertica буде здійснюватися не швидко. Стоунбрейкера пропонує пожертвувати журналами транзакцій, відмовитися від одночасної роботи користувачів і від випадкових (ad hoc) запитів, а також працювати з базами, цілком розміщуються в оперативній пам’яті, всю логіку програми реалізовувати всередині СУБД (у вигляді збережених процедур) і т.д. – Все заради досягнення високої продуктивності за рахунок надійності, масштабованості і безпеки.


Продуктивність СУБД, безумовно, важлива, але користувачі роблять свій вибір, орієнтуючись на сукупність характеристик: надійність і безперервність роботи, масштабованість, безпека, простоту управління і розробки, можливість роботи з великими базами, підтримку спеціальних схем, алгоритмів і типів даних (OLTP, XML, годинне, тексти і т.д.), підтримку стандартів і національної мови. Крім того, дуже важлива поширеність даної СУБД в конкретній країні, наявність і можливість навчання, кількість вдалих впроваджень і т.п. Тут спеціалізовані СУБД конкурувати з універсальними не можуть.


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


Не варто забувати про надійність і популярність компанії-виробника СУБД – замовники та розробники додатків, як правило, вибирають не просто СУБД, а платформу для створення безлічі різнорідних додатків.


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


Потрібно багато часу, щоб нові можливості почали працювати швидко і без помилок. Так, Oracle вже десять років удосконалює архітектуру shared anything, яка надає засоби роботи в кластері, а IBM покращує оптимізатор запитів. Тільки лідери ринку можуть вкладати величезні кошти в довгострокові проекти, а нові ідеї та технології, породжені стартапами, вони дуже швидко сприймають або купують нову компанію разом з технологією. Єдине, що може вплинути на долю універсальних СУБД, – це революційні зміни в обладнанні, які можуть призвести до кардинальної зміни внутрішньої архітектури СУБД (наприклад, відмова від дисків на користь флеш-пам’яті або збільшення швидкості передачі даних по мережах, що перетворює безліч розкиданих по всьому світу комп’ютерів в один).


Десятка тенденцій


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


Віртуалізація і grid


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


Всі диски об’єднуються в один віртуальний, на якому розташовуються всі дані всіх додатків. Наприклад, в Oracle GRID [9] диски об’єднані в Storage Grid, а комп’ютери – в Database Grid (віртуальний сервер бази даних) і Application Grid (віртуальний сервер додатків). Для управління таким безліччю елементів використовується програма Grid Control, яка дозволяє працювати з безліччю об’єктів як з єдиним цілим.


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


Віртуалізація дозволяє створювати обчислювальний ресурс необмеженої потужності і не піклуватися про те, на яких комп’ютерах в дійсності працює програма. Головне – запросити і отримати потрібний обчислювальний ресурс. Система сама виконає балансування навантаження для програми, створить, якщо треба, базу даних з урахуванням віддзеркалення даних і зниження навантаження по вводу / виводу, задіє стільки елементів grid, скільки необхідно для забезпечення необхідної надійності і продуктивності.


Сьогодні вже реалізовані такі корпоративні grid першого покоління на рішеннях Oracle (Amazon, EDS ABNAMRO), а IBM активно проводить дослідження в області grid для наукових застосувань, просуваючи інструментарій Globus Toolkit.


Основою Database GRID у Oracle є архітектура Real Application Clusters, що реалізує підхід shared disk (всі вузли кластера одночасно працюють з єдиною базою даних), схожу архітектуру реалізує і СУБД IBM DB2 для z / OS.


Рішення Enterprise Grid першого покоління мали ряд обмежень. Наприклад, передбачалося виділення двох віртуальних комп’ютерів – Database Grid і Application Grid замість єдиного віртуального комп’ютера для СУБД, серверів додатків, Web-серверів, HTTP-серверів і т.д. Ресурси автоматично не перерозподілялися відповідно до заздалегідь заданої політикою, система не адаптувалася до змінного навантаження, програми не могли без зупинки роботи переїжджати зі слабких вузлів на більш потужні. Більшість з цих обмежень передбачається зняти в архітектурі Enterprise Grid 2, прикладом реалізації якої буде Oracle 11.2.


Самоврядування, самодіагностика, самолікування


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


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


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


Ще однією важливою тенденцією є зменшення кількості “ручок”, які може підкрутити адміністратор, замість цього пропонуються засоби завдання бізнес-критеріїв роботи: допустимий час простою при збої, максимальний час відгуку, мінімальна пропускна здатність системи і т.п.


Тестування змін


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


Є багато пакетів, що дозволяють імітувати навантаження на тестовій системі, проте вони часто створюють не реальну, а синтетичну навантаження, і в результаті багато проблем так і залишаються невиявленими. Функціонал, аналогічний Oracle RAT (Real Application Testing), очевидно, буде реалізований у всіх СУБД – він дозволяє на працюючій системі захопити реальну навантаження (з урахуванням часу виконання, одночасності, Залежно операцій) і відтворити її на тестовій базі, не встановлюючи там додаток. Захоплення і програвання навантаження дозволяють виявити з’явилися / зниклі / змінилися після виконання змін помилки, виявити проблеми зниження продуктивності як всієї системи, так і окремих запитів. Після аналізу результатів система дає рекомендації щодо поліпшення роботи SQL, дозволяє спробувати різні варіанти оптимізації роботи. Відкочуючись тестову базу назад, можна тестувати різні зміни та їх сукупність. І тільки після того, як всі проблеми виявлені і вирішені, можна виконувати зміни в виробничому середовищі.


Максимальна доступність


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


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


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


Вимірювання часу


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


Підтримка нових типів даних


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


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


Розумні механізми стискування і дедуплікаціі


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


Традиційні алгоритми стиснення дозволяють упаковувати дані в два-три рази “щільніше”, а деякі специфічні прийоми дозволяють збільшити цей показник на порядок, але при цьому сильно сповільнюється виконання операцій DML (Data Manipulation Language) з цими даними.


Удосконалення методів захисту


Сьогодні все частіше механізм управління обліковими записами користувачів виноситься з окремих СУБД і додатків в єдину централізовану систему організації (Identity & Access Management). Це спрощує управління в масштабах організації і дозволяє управляти обліковими записами виходячи з вимог бізнесу. Удосконалюються методи аудиту, буде з’являтися інтегрована середа збору та аналізу інформації всієї організації. Крім того, інтенсивно вдосконалюються засоби захисту даних, наприклад швидко розвивається механізм завдання політик перевизначення запитів на льоту – запит автоматично модифікується в залежності від різних параметрів (назва програми, час запуску на виконання, ім’я користувача, місце надходження запиту і т.д.).


Ще один перспективний напрямок – ізоляція адміністратора від даних. Такі засоби захисту, як Oracle Data Vault option, дозволять виконувати всі операції по адмініструванню, але не дають можливості бачити і змінювати дані.


СУБД в якості кеша


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


Сьогодні намітилася тенденція використання In memory СУБД в якості високошвидкісних кешей до дисковим СУБД, наприклад, Oracle використовує в такій якості СУБД Times Ten, а IBM – СУБД SolidDB. Додатки, вимагають високої швидкодії та гарантованого часу відгуку, практично працюють з таким кешем в пам’яті, який сам синхронізується з дисковою СУБД. При цьому розміри основної бази можуть бути дуже великими, але кешується за певною політиці лише частину даних.


Хмари і машини баз даних


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


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


Зазвичай при зростанні обсягів вузьким місцем стають канали передачі даних між сервером бази і пристроями зберігання, тому для збільшення пропускної здатності частина операцій по перегляду і вибіркою даних переноситься на рівень осередків зберігання. Така зв’язка обладнання та спеціального ПО називається машиною баз даних [10], реалізації яких сьогодні пропонують такі компанії, як Netezza, Datallegro і Teradata. Однак такі машини працюють зі спеціальним ПО і вимагають спеціальної кваліфікації для розробки додатків, не використовують універсальні СУБД, а універсальні СУБД не підтримували архітектуру машин. Зараз почався рух універсальних комерційних СУБД в сторону машин баз даних, і прикладом такого зближення стала спільна розробка Oracle і HP – машина баз даних з осередками зберігання Exadata.


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


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


При аналізі роботи застосовуються кращі практики і знання, накопичені адміністраторами СУБД, системи навчаються реагувати проактивно, виявляють причини, а не наслідки виникнення проблем.


Стиснення поколоночно збережених і заздалегідь відсортованих даних забезпечить їх “ущільнення” в десятки разів, проте всі спроби зміни таких таблиць в Oracle 11.2 показали, що час оновлення даних значно збільшується, хоча для сховищ даних та історичних даних такий підхід цілком прийнятний.


HP Oracle Database Machine забезпечує для звичайних додатків сховищ даних Oracle прискорення обробки даних до 70 разів без переписування додатків. У тому ж напрямку рухається Microsoft, що купила DATAllegro і інтегруюча її продукти з SQL Server.

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


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

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

Ваш отзыв

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

*

*