Технології нішевих баз даних: ретроспективний погляд

1. Сьогодні комерційні системи керування базами даних і допоміжні інструментальні засоби (засоби проектування...
2. прискорювачі
3. Засоби моніторингу і налаштування продуктивності
4. Розширення моделі з першої нормальної формою
5. Підтримка типів, які не є алфавітно-цифровими
6. Засоби забезпечення цілісності даних

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

На ринку баз даних панує «Велика трійка» - IBM, Microsoft і Oracle. У початковій стадії в комерційних РСУБД підтримувалися реляційна модель даних з першої нормальної формою і мова запитів SQL, а також базове управління транзакціями і засоби авторизації доступу. Майже всі системи виконувалися на кількох Unix-платформах. За останні два десятиліття істотно розширилися межі функціональних можливостей цих систем, зросла складність, значно підвищилася продуктивність. Тепер вони можуть функціонувати майже на всіх моделях комп'ютерів під управлінням більшості існуючих операційних систем. Однак провідні постачальники часто витрачали неприпустимо довгий час на усунення різних недоліків РСУБД, і в період їх становлення це призвело до появи рішень, які я буду називати технологіями «нішевих баз даних» 1. Зазвичай нишевая технологія з'являлася на світ як засіб подолання одного великого недоліку в тих, що були на той момент РСУБД 2. Розроблялися постачальниками технології і вживали ними зусилля з просування цих технологій на ринок часто спонукали провідних постачальників до впровадження в свої продукти тих же технологій. Що володіють необхідними фінансовими засобами, які спираються на підтримку клієнтів і на свої маркетингові можливості, великі виробники просто витісняли творців нішевих технологій. В результаті виробники нішевих рішень - за винятком близько десяти компаній - так і не змогли перетворитися в стабільні і великі бізнес-структури. Сьогодні зрілість сучасних РСУБД, очікування традиційних клієнтів і панування на ринку «Великої трійки» роблять вихід на ринок нових виробників нішевих рішень надзвичайно складним.

У даній статті я представлю ретроспективу нішевих технологій баз даних, привівши їх короткі описи та розповівши про те, як вони були (або не були) запозичені провідними системами. Розглянемо наступні п'ять категорій нішевих технологій: прискорювачі (performance engines) для деяких операцій і середовищ баз даних; засоби моніторингу та налаштування продуктивності; розширення реляційної моделі з першої нормальної формою; підтримка типів даних, які не є алфавітно-цифровими; засоби підтримки цілісності даних. Різні типи допоміжних засобів баз даних, такі як інструменти для формування запитів і генерації звітів, засоби проектування баз даних, генератори додатків, засоби перегляду баз даних і т.п., обговорюватися не будуть. Хоча вони не є додатками кінцевих користувачів, я не вважаю їх і додатками РСУБД.

прискорювачі

На продуктивність РСУБД впливали, насамперед, потреби додатків оперативної обробки транзакцій (online transaction processing, OLTP). Зазвичай такі додатки витягають малу частину вмісту великої бази даних, оновлюють деякі дані і зберігають їх в тій же базі. Наявність великої кількості одночасно виконуваних транзакцій змушує запускати РСУБД на потужних серверах і мультікомпьютерних системах. У число методів підвищення продуктивності, впроваджених в РСУБД, входять, крім інших, методи доступу, оптимізація запитів на основі оцінки витрат, архітектури процесів, оптимізоване управління транзакціями, параметрезованих настройка продуктивності, паралельна масове завантаження даних. Методи доступу включають в себе індекси на базі B + -дерев, хеш-таблиці, попередньо відсортовані таблиці і сегменти дискових сторінок. Таблиця повністю зберігається в одному сегменті дискових сторінок, і кожна дискова сторінка форматується таким чином, щоб забезпечити швидкий доступ до окремих записів, а також швидку «прив'язку» до іншої сторінки. Метод оптимізації запитів на основі оцінки витрат на увазі розрахунок оціночної вартості всіх розумних «планів» обробки кожного заданого запиту, одержуваних шляхом використання всіх наявних методів доступу до всіх таблиць, які зачіпаються запитом, і вибір плану з найменшою вартістю. У високого рівня оптимізовані застосовуються при управлінні транзакціями механізми управління паралелізмом і відновлення. Мінімізовано кількість команд, необхідних для перевірки наявності та установки блокувань елементів даних. Для скорочення числа операцій введення / виводу мінімізовано кількість записів про оновлення даних в журнал у вторинній пам'яті. У РСУБД є безліч параметрів, встановлюючи які належним чином, адміністратори баз даних можуть оптимізувати продуктивність для своїх середовищ додатків. У числі цих параметрів - розмір дискового сегмента, обсяг вільної пам'яті, що резервується в кожної дискової сторінці для забезпечення можливості в майбутньому вставляти нові записи, часовий інтервал «компактификации» дискової пам'яті за рахунок її очищення від записів, позначених як вилучені, але не видалених фізично і т.д. Для забезпечення повного використання ресурсів центрального процесора при наявності обмінів з дисками в РСУБД підтримується многопроцессность і многопотоковая організація. Ця структура процесів також істотна для РСУБД, виконуваних на SMP-системах і на кластерах, коли є кілька центральних процесорів. У РСУБД впроваджені методи паралельної обробки запитів, при застосуванні яких складний запит декомпозіруется на послідовність підзапитів так, що деякі підзапити обробляються паралельно на різних комп'ютерах, і для скорочення загального часу відгуку підзапити обробляються в конвеєрному режимі. Крім того, методи паралельної обробки застосовуються в РСУБД для масової завантаження даних, резервного копіювання даних, створення індексів і т.д.

Хоча робота по підвищенню продуктивності ведеться вже понад два десятиліття, є, щонайменше, дві особливі ситуації, з якими не справляються традиційні РСУБД. Є програми, бази даних яких вміщаються в основний пам'яті, і додатки, яким потрібно, головним чином, «скануючий» доступ до бази даних. Системи управління базами даних в основній пам'яті, такі як TimesTen, Altibase, Datablitz, Prisma і т.д. завантажують дані з вторинної пам'яті в основну пам'ять і виконують всі операції з базою даних без потреби у введенні / виведенні. У цих системах для більшості операцій число команд скорочено за рахунок зняття проблеми доступу до вторинної пам'яті. У підсумку, системи управління базами даних в основній пам'яті часто можуть демонструвати продуктивність, у багато разів перевищує продуктивність традиційних РСУБД. Звичайно, традиційні РСУБД, що виконуються на комп'ютерах з основною пам'яттю більшого обсягу, можуть мати більш високою продуктивністю, ніж системи, що працюють на комп'ютерах з основною пам'яттю меншої ємності, і переваги систем управління базами даних в основній пам'яті над традиційними системами можуть бути частково компенсовані використанням основної великої ємності. Технологія систем управління базами даних в основній пам'яті має цікавий потенціалом, який може бути реалізований при наявності підтримки операційними системами 64-розрядної архітектури, що дозволяє домогтися дуже великого обсягу основної пам'яті, і при істотному зниженні вартості основної пам'яті. До числа проблем, які потрібно вирішити в даній області, відносяться потреба в підтримці здебільшого можливостей мови запитів SQL і опір з боку системних адміністраторів, які не відчувають бажання адмініструвати ще одну систему на додачу до традиційних РСУБД.

«Сканирующий» доступ до баз даних передбачає наявність потреби в одноразовому, а можливо, і багаторазовому скануванні всієї таблиці (або всієї бази даних) для виконання однієї операції. У число прикладів скануючого доступу входять запити, в яких потрібно групування всіх записів таблиці відповідно до значень деякого стовпця; запити, що обчислюють агрегатні функції на деяких шпальтах таблиці; запити, для виконання яких потрібна попередня сортування таблиці; запити з низькою селективністю; операції, реструктуризується таблицю і т.д. Наприклад, группирующий запит може групувати всі записи Person (людина) за значеннями стовпчика Age (вік). Агрегує запит, може, наприклад, обчислювати Average Salary (середню зарплату) для всіх записів Person. Запитом з низькою селективністю є, наприклад, запит, які обирають записи, які стосуються усіх некурящих людей. Операції, що виробляють реструктуризацію таблиць, включають, наприклад, операцію розбиття стовпця на два або більше число стовпців (наприклад, один стовпець Address (адреса) розбивається на стовпці StreetAddress (адреса на вулиці), City (місто) і State (штат)) або операцію заміни безперервних числових значень стовпця (наприклад, значення Salary 55400 дол.) на значення, що визначають категорії (скажімо, категорію Salary від 50000 до 59999 дол.).

Такі методи доступу, як індекси і хеш-таблиці, виявилися дуже корисними при виконанні запитів для OLTP-додатків. Але вони виявляються марними при виконанні запитів, орієнтованих на сканування. Додатки оперативної аналітичної обробки даних (online analytical processing, OLAP), зазвичай «аналізують» великі обсяги даних, а не вибирають лише невелике число записів з великої бази даних. Як правило, для аналізу даних потрібно підсумовування і агрегування даних відповідно до кількома вимірами (грубо кажучи, стовпцями); в якості прикладу можна навести загальний обсяг продажів певної моделі комп'ютера по регіонах (Region), місяцях (Month), по магазинам (Store) і т.д. По суті, для цього зазвичай потрібно вибірка і дослідження вмісту всієї таблиці. Такі програмні продукти, як MaxScan і Sybase ASIQ, розроблені з метою забезпечення швидкого виконання запитів, орієнтованих на сканування. З цим завданням вони справляються, в середньому, в 10-20, а іноді і в 100 разів швидше, ніж традиційні РСУБД. Для досягнення високої продуктивності в системі MaxScan використовуються спеціальні схема компонування пам'яті, схема стиснення даних і методи хешування. У Sybase ASIQ всі дані в таблицях кодуються щоб зменшити розміри таблиць та прискорити виконання запитів. Незважаючи на вражаючі показники продуктивності, з цими продуктами пов'язані ті ж проблеми, що і згадувані в зв'язку з СУБД в основний пам'яті.

Потреба OLAP-додатків в підсумовуванні даних по багатьом вимірам привела до появи систем M-OLAP, таких як IRI Express (придбана компанією Oracle), Arbor Essbase (придбана компанією Hyperion) і Pilot Decision Support System (придбана компанією Accrue). Системи M-OLAP є сервери OLAP, які попередньо обчислюють зведення даних по всіх можливих вимірах і зберігають їх в системі зберігання, званої багатовимірної системою управління базами даних. Оскільки зведення попередньо зберігаються, відповіді на запити надходять швидко. Однак попереднє обчислення зведень, як правило, займає чимало часу, а обсяг пам'яті, необхідної для зберігання зведень (якщо не виключаються невизначені значення), часто перевищує розмір вихідних даних. Далі, поновлення вихідних даних роблять зведення неспроможними, і їх потрібно обчислювати заново. На відміну від систем M-OLAP, для яких потрібна особлива система зберігання, MicroStrategy, Cognos і іншими компаніями були запропоновані системи R-OLAP. В якості системи зберігання даних в системах R-OLAP використовується будь-яка РСУБД, але ці системи зазвичай є набагато більш повільними, ніж системи M-OLAP. Як аналітичного сервісу своєї СУБД SQL Server корпорація Microsoft пропонує як засоби M-OLAP, так і R-OLAP.

Засоби моніторингу і налаштування продуктивності

Складність сучасних РСУБД, операційних систем, під керуванням яких вони функціонують, додатків, об'ємність баз даних, різноманіття і потужність ресурсів комп'ютерів виключно ускладнюють стоїть перед адміністраторами баз даних завдання забезпечення оптимальної продуктивності РСУБД і додатків. На продуктивність можуть несприятливо впливати SQL-запити, управління буферами баз даних, обміни з дисками, конкуренція за ресурси бази даних (блокування, семафори, очікування подій) і навіть операційна система (ЦП, організація введення / виведення і використання пам'яті). Поряд з провідними постачальниками РСУБД, є кілька компаній, які пропонують інструментальні засоби, призначені для допомоги адміністраторам в здійсненні моніторингу та налаштування продуктивності РСУБД. У числі цих компаній - Computer Associates, BMC Software, Embarcadero, Quest Software і ін.

Розширення моделі з першої нормальної формою

Протягом останніх двадцяти років багато фахівців висловлювали претензії до реляційної моделі з першої нормальної формою, підтримуваної в традиційних системах. Головний принцип реляційної моделі з першої нормальної формою говорить, що кожен стовпець кожного запису містить атомарні дані. Атомарні дані - це дані, які зберігаються і витягуються як єдине і не розкладається на складові ціле. Такий підхід є досить неприродним при управлінні наборами даних або даними, які можна описати з більшим ступенем деталізації. Припустимо, в стовпці Children (діти) таблиці Person користувач може зберегти імена двох дітей (Tom, Dick); але РСУБД трактує це як один елемент даних, а не як два окремих елемента. Далі, в стовпці Hobby (хобі) таблиці Person користувач може зберегти детальну інформацію про захоплення людини, наприклад, (name: tennis, years-played: 5, hours-spent-a-month: 10). І знову РСУБД буде трактувати дані стовпця Hobby як єдине ціле, не помічаючи компонентні елементи даних.

Потреба в природному моделюванні і запитував вкладеної структури деяких даних, таких як дані в стовпці Hobby, привела до появи РСУБД, що не відповідає принципам першої нормальної форми. Прикладом може служити UniData (придбана компанією Ascential Software) 3 .

Обмеження реляційної моделі з першої нормальної формою знову стали об'єктом пильної уваги в 80-і роки, коли роблять різні сторони і дослідники взялися за створення систем управління об'єктно-орієнтованими базами даних (ООСУБД). На перших порах термін «об'єктно-орієнтована база даних» приводив до великої плутанини, особливо, в співтоваристві фахівців в області РСУБД. Те, що розуміли під ООСУБД перші постачальники, такі як Mosaic (пізніше перейменована в Ontos), ObjectDesign (нині іменується eXcelon) і Servio Logic, було всього лише системою об'єктно-орієнтованого програмування зі стабільним зберіганням об'єктів. Ontos і ObjectDesign хотіли запропонувати систему програмування C ++ зі стабільним зберіганням об'єктів, а Servio Logic - стабільну систему програмування Smalltalk. По суті справи, на перших порах основна ідея полягала лише в тому, щоб об'єкти C ++ або Smalltalk зберігалися в «базі даних», щоб користувачі отримували їх за допомогою покажчиків на ці об'єкти і маніпулювали витягнутими об'єктами в основний пам'яті. Об'єкти представляють собою сукупність елементів даних і методів разом зі зв'язком спадкування на класах. Вихідна концепція ООСУБД була чужа членам спільноти РСУБД, які були привчені вважати, що система баз даних повинна підтримувати мову запитів, заснований на SQL, і засоби управління транзакціями. Це призвело до того, що протягом деякого часу табори ООСУБД і РСУБД обмінювалися досить плутаними докорами. З табору РСУБД звучало, що ООСУБД - це не системи баз даних, оскільки в них не підтримуються непередбачені запити, і користувачам нав'язується навігація по базі даних на основі покажчиків, підхід, від якого відмовилися при переході технології баз даних з ери ієрархічних баз даних в еру РСУБД. Табір ООСУБД відбивався, стверджуючи, що немає сенсу застосовувати незграбні SQL-запити в той час, коли заснована на покажчиках навігація по об'єктах в основний пам'яті забезпечує набагато більш високу ефективність. Пізніше виробники ООСУБД (і піонери цього напрямку, і ті, хто приєднався до них на більш пізніх етапах, наприклад, O2) вбудували в свої системи мови для непередбачених запитів і засоби управління транзакціями, що зробило ООСУБД більш схожими на традиційні системи баз даних, хоча і зберегли навігацію на основі покажчиків по об'єктах, що розташовуються в основній пам'яті) 4 .

Тим часом, в компанії UniSQL - а за нею і Illustra - усвідомлювали безплідність пікіровки між двома таборами і шукали можливість розширення реляційної моделі з першої нормальної формою до об'єктно-орієнтованої моделі в тому вигляді, в якому вона втілювалася в об'єктно-орієнтованих мовах програмування. На початку 90-х років вони запропонували ідею об'єктно-реляційних систем (ОРСУБД). Об'єктно-реляційна модель включає в себе принцип вкладення класів, унікальні ідентифікатори об'єктів, методи, приписувані до класу, успадкування атрибутів і методів у відповідності з ієрархією класів, а також зв'язку узагальнення / спеціалізації між класами, розташованими на різних рівнях ієрархії класів.

Illustra була пізніше придбана компанією Informix, яка, в свою чергу, перейшла у власність корпорації IBM. Технологія Illustra була інтегрована в РСУБД Informix. Технологія UniSQL пізніше стала надбанням ряду різних корпорацій в США і в країнах Далекого Сходу. Робота, розпочата в UniSQL і Illustra в 90-х роках, привела, врешті-решт, до розширення мови SQL до SQL3 шляхом додавання до SQL об'єктних розширень, а також впровадження об'єктно-орієнтованої моделі Oracle 9i і DB2 8.1. Цілком ймовірно, що в доступному для огляду майбутньому і інші великі РСУБД стануть безпосередньо підтримувати SQL3 і тим самим перейдуть в категорію ОРСУБД.

Далі, виробники РБД в даний час підтримують стабільний зберігання об'єктів для об'єктно-орієнтованих мов програмування, включаючи C ++ і Java. По суті, вони забезпечують обгортку (wrapper) між об'єктно-орієнтованої програмою і ОРСУБД, що згладжує відмінності між моделлю об'єктно-орієнтованої мови і моделлю ОРСУБД.

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

Поряд з об'єктами, протягом довгого часу темою досліджень була підтримка темпоральних даних. До темпоральних даних належать історичні дані і дані часових рядів, а також поняття часу транзакції (transaction time) і часу дійсності (valid time). Час транзакції - це час введення даних, а час дії - це час, протягом якого дані зберігають дієвість. Є кілька прототипів, таких як T Helper, ORES і Tzolkin; крім того, є також ряд пропозицій по розширенню мови SQL, таких як SQL / Temporal, TSQL, TLSQL і т.д. Однак власна підтримка темпоральних даних в провідних РСУБД відсутня. У кількох великих РБД для підтримки темпоральних даних використовуються модулі data blade.

Підтримка типів, які не є алфавітно-цифровими

На першому етапі традиційні РСУБД проектувалися для підтримки алфавітно-цифрових типів даних. Пізніше в них була впроваджена підтримка великих бінарних об'єктів (binary large object, BLOB) і великих символьних об'єктів (character large object, CLOB). У Illustra була запропонована ідея вбудовування в РСУБД програмних модулів, які забезпечують підтримку спеціальних типів даних, які не є алфавітно-цифровими. У Illustra такі програмні модулі отримали назву data blade ( «лезо даних»). У Oracle з'явилися модулі data cartridge ( «картридж даних»), а IBM додала до DB2 механізм database extender ( «розширювач баз даних»). Ці програмні модулі визначають і реалізують певний тип даних і різні операції для цього типу даних.

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

Деякі постачальники спеціалізованих продуктів розширили процесори реляційних баз даних шляхом додавання власних коштів підтримки просторових типів даних і просторових операцій. У число просторових типів даних входять точка, лінія, прямокутник, багатокутник, ламана лінія, коло і т.д. До числа просторових операцій відносяться операції «частково перекриває», «примикає», «містить», «вище», «нижче», «лівіше», «правіше», «найближчий» і т.д. Для підтримки виконання просторових запитів, тобто запитів, що містять просторові дані і просторові оператори, в цих продуктах зазвичай застосовується механізм індексування, заснований на R * -дерева. Компанія KT Data розширила процесор об'єктно-реляційних баз даних UniSQL просторовими типами даних і операціями. Компанії Paradise і Monet підтримують просторові типи даних і операції, а також методи паралельної обробки запитів. Компанія Intergraph пропонує MGE-GeoData Manager для управління просторово-часовими даними. Oracle також впровадила в свою РСУБД інтегровану підтримку просторових типів даних і просторових операцій. Ці системи є більш амбітними, ніж РСУБД, які підтримують просторові типи даних з використанням data blade і координують обробку запитів засобами звичайної РСУБД і окремого просторового модуля.

Розширювана мова розмітки XML є ще одним типом даних, які не є алфавітно-цифровим і привертає велику увагу. За останні кілька років XML став стандартним засобом представлення різноманітних даних, яким властива ієрархічна структура. Вкладена структура XML природним чином відображається на агрегаційну ієрархію об'єктної моделі. Тому такі постачальники, як ObjectStore / eXcelon і Poet використовували свої об'єктно-орієнтовані системи для зберігання XML-даних і для обробки запитів до таких даних. В системі BADA IV корейської компанії ETRI забезпечуються власні кошти підтримки XML. Провідні виробники РСУБД спочатку підтримували тип даних XML на основі модулів data blade. Однак тепер Oracle забезпечує власну підтримку XML, використовуючи можливості вкладених таблиць.

Деякі великі постачальники РСУБД додають, також, підтримку деяких мультимедійних типів даних, включаючи зображення і відео. У Informix, DB2 і Oracle для цих типів даних і операцій над ними забезпечуються модулі data blades. У цих модулях реалізовані технології розпізнавання і індексування мультимедійного контенту, розроблені такими компаніями, як Excalibur (придбана Convera) і Virage.

Засоби забезпечення цілісності даних

У РСУБД підтримуються різні механізми підтримки цілісності даних, що зберігаються, однак вони не є повністю достатніми. Механізми підтримки цілісності, безпосередньо підтримувані в РСУБД, включають управління транзакціями, обмеження типів даних і обмеження цілісності 6. Управління транзакціями включає контроль паралельного доступу до одних і тих же даних з боку декількох користувачів (або транзакцій), відновлення після м'яких збоїв (які призводять до руйнування даних в основній пам'яті) і жорстких збоїв (призводять до руйнування дані у вторинній пам'яті). Обмеження типів даних -це обмеження на значення стовпців, визначених на заданому користувачем типі: цілі числа, рядки символів і т.д. Для деяких стовпців таблиці користувачі можуть вказувати обмеження цілісності. До них відносяться обмеження «первинний ключ - зовнішній ключ» на стовпці двох таблиць, обмеження UNIQUE на стовпець первинного ключа, обмеження NULL, яке дозволяє використовувати в стовпці невизначене значення.

Обмеження типів даних не є достатніми для того, щоб запобігти введення в базу даних невірних даних. Наприклад, обмеження діапазону значень целочисленного типу даних (18..65) може запобігти збереження, наприклад, в стовпці Age таблиці Person цілих значень, що виходять за межі вказаного діапазону. Однак РСУБД не може знати, чи є правильним значення 25 для стовпця Age деякої конкретної записи таблиці Person. Обмеження целочисленного типу даних не може нічого сказати про одиниці вимірювання значення «125», що зберігається, скажімо, в стовпці Weight (вага) таблиці Person. Аналогічно, обмеження типу символьних рядків не може запобігти збереження слів з орфографічними помилками, наприклад, в стовпці Name таблиці Person. Далі, через накладних витрат, що викликаються перевіркою обмежень, або через безтурботність частини користувачів, доречні обмеження типів даних і цілісності часто не вказуються. Наприклад, замість завдання діапазону значень (18..65) для стовпця Age таблиці Person користувач може Integer, допускаючи тим самим появу в стовпці Age будь-якого цілочисельного значення. Далі, таке обмеження, як «Середня зарплата будь-якої людини не повинна бути більш ніж на 30% нижче, ніж найвища зарплата», зажадає обчислення (або, принаймні, пошуку) середнього значення зарпла