Універсальне ядро для баз даних NoSQL з використанням випробуваних і перевірених технологій
Термін NoSQL (англ. Not Only SQL - не тільки SQL) став відомий відносно недавно і був введений для опису різних технологій баз даних, що виникли для задоволення вимог, відомих як "Web-scale" або "Internet-scale".
Є три вимоги до Web-scale додатків:
- Багато даних: найбільші з веб-додатків обробляють обсяги даних на порядки більше тих, що передбачалися для управління базами даних (Facebook - 50 терабайт для пошуку по вхідних повідомлень; eBay - всього 2 петабайта)
- Величезна кількість користувачів: обчислюються мільйонами, доступ до систем одночасно і постійно
- Складні дані: як правило, це програми не простий обробки табличних даних, які можна знайти в багатьох комерційних і бізнес-додатках.
Технології реляційних баз даних, які домінували в ІТ-індустрії з 1980 року, почали показувати свої слабкі місця при переході до веб-масштабам саме в цих трьох аспектах, тому все більше число людей почали шукати альтернативу. Так стали з'являтися NoSQL бази даних. Хоча різноманітність моделей зростає, всі вони мають загальні риси:
- Обробляють величезні обсяги даних, розділяючи їх між серверами
- Підтримують величезна кількість користувачів
- Використовують спрощену, більш гнучку, не обмежену схемою структуру бази даних
Всі найбільш успішні й відомі NoSQL бази даних були розроблені з нуля за останні кілька років. Дивно, але, схоже, що ніхто з розробників не подивився навколо, щоб побачити, чи є вже існуючі, успішно реалізовані технології баз даних, які могли б забезпечити надійну основу для відповідності вимогам Web-scale.
Якби вони це зробили, то, можливо, виявили б два продукти - GT.M ( fisglobal.com/Products/TechnologyPlatforms/GTM/index.htm ) І Inter-systems Cache ( www.intersystems.ru ), Чиї системи зберігання засновані на глобальний.
Короткий огляд глобальний
Глобал - це абстракція B-tree структури, яка зазвичай використовується в мові MUMPS ( ru.wikipedia.org/wiki/MUMPS ) Для зберігання великих обсягів даних.
Глобальний спочатку були розроблені в 1966 році для підтримки управління великими обсягами складних і слабоструктурованих медичних даних, і були спеціально спроектовані для ефективної підтримки того, що тоді вважалося нездійсненним - великого числа конкурентних інтерактивних користувачів на серйозно обмежених ресурсах PDP міні-комп'ютерів. Хоча це не "веб-масштаб", тим не менш, глобальний стали досягненням, яке інші технології баз даних в той час досягти не могли.
Характеристики глобальний:
- не обмежені схемою;
- ієрархічно структуровані;
- розріджені;
- динамічні.
Для того щоб зрозуміти, що таке глобал, уявіть собі зберігається асоціативний масив. наприклад:
account ( "New York", "026002561", 35120218433001) = 123456.45Загальна форма вираження записується в такий спосіб:
globalName (subscript1, subscript2, .. subscriptN) = valueТака комбінація імені, індексів і значення називається вузлом Глобал і є одиницею зберігання. Важливим моментом є те, що один глобал може містити вузли з різною кількістю індексів, наприклад:
myGlobal ( "a") = 123 myGlobal ( "b", "c1") = "foo" myGlobal ( "b", "c2") = "foo2" myGlobal ( "d", "e1", "f1") = "bar1" myGlobal ( "d", "e1", "f2") = "bar2" myGlobal ( "d", "e2", "f1") = "bar1" myGlobal ( "d", "e2", "f2") = "bar2" myGlobal ( "d", "e2", "f3") = "bar2"Тобто глобал представляє розріджений ієрархічне дерево вузлів. Наприклад, глобал вище ефективно представляє наступне ієрархічне дерево:
Ви можете створити будь-яку кількість глобальний. Іншими словами, база даних в GT.M або Cache буде складатися з одного або безлічі глобальний, кожен зі своєю ієрархією вузлів.
У такій базі даних немає явних зв'язків між глобальний, але можуть бути неявні відносини, які визначаються і управляються на рівні додатку. Також не існує явної схеми, визначеної для глобальний. Можна створювати або знищувати вузли Глобал в будь-який момент. Вони повністю динамічні і не вимагають попередньої декларації або схеми.
Обгортка для NoSQL рішень
Деякий час назад сайт TechRepublic опублікував статтю під назвою "10 речей, які ви повинні знати про базах даних NoSQL" ( com/10things/?p=1772> blogs.techrepublic.com.com/10things/?p=1772 ). Це перерахування 5 достоїнств і 5 недоліків NoSQL баз даних. Якщо оцінювати GT.M і Cache за цими десятьма критеріями, можна виявити, що вони відповідають усім перерахованим переваг, але, що більш цікаво, не мають 4 з 5 їхніх недоліків, ніж інші NoSQL бази даних не можуть похвалитися.
переваги
1. Лінійне масштабування:
Обидва продукти, GT.M і Cache, протягом вже багатьох років підтримують масштабування на кілька серверів і можуть використовувати при цьому недороге обладнання. У випадку з Cache фірмова мережева технологія ECP (Enterprise Cache Protocol) дозволяє створювати логічне відображення глобальний, в той час коли вони можуть бути фізично розподілені між декількома серверами.
2. Багато даних
Системи GT.M і Cache призначені для підтримки і управління величезними обсягами даних, далеко за межами можливостей реляційних баз даних, але при цьому забезпечують високу продуктивність.
3. До побачення, адміністратори БД!
Цікаво, що фірма InterSystems, виробник Cache, використовує цю перевагу в своїй маркетинговій політиці протягом багатьох років. Є історії систем на базі глобальних, які функціонували без адміністрування протягом десятиліть.
4. Економічність
Обидва продукти, GT.M і Cache, будуть беcпроблемно працювати на недорогих стандартних апаратних платформах і витягати з них максимальну продуктивність. Партнери з охорони здоров'я в Массачусетсі підтримували десятки тисяч інтерактивних користувачів впродовж 1980-х і 1990-х років на мережному кластері з сотень ПК з MSDOS і попереднику Cache.
5. Гнучкі моделі даних
Це сама суть сховища на глобальний, яка буде розкрита в цій статті трохи нижче.
недоліки
1. Зрілість
На відміну від нових NoSQL баз даних, GT.M і Cache мають довгу родовід і видатний послужний список, що підтримує великі і складні бази даних в складних умовах реальних бізнес-додатків. Це надійні та стабільні технології, які можуть бути впевнено використані в важливих бізнес-додатках.
2. Підтримка
GT.M активно використовується в деяких з найбільших в світі банківських систем, в той час як Cache домінує в охороні здоров'я. Однією з причин, по яким вони використовуються в цих галузях, є якість комерційної підтримки, що надається відповідними постачальниками.
3. OLAP і бізнес-аналіз
Обидва продукти, GT.M і Cache, підтримують підключення до інструментів SQL-БІЗНЕСАНАЛІТИКА. Також протягом багатьох років вони підтримують доступ до SQL і не-SQL баз даних. В даний час InterSystems активно рекламує продукт під назвою DeepSee ( intersystems.ru/deepsee ), Який призначений саме для цієї мети і є надстрокой над базою даних Cache.
4. Адміністрування
Як GT.M, так і Cache прості в установці і обслуговуванні і часто використовуються в ситуаціях, коли є хоч один, якщо такий взагалі є, кваліфікований ІТ-фахівець.
5. Спеціалізація
Це дійсно один з недоліків GT.M і Cache. Хоча число користувачів, зокрема, для Cache, неухильно зростає, число кваліфікованих фахівців, які мають досвід роботи з GT.M і Cache дуже малий, в порівнянні з кількістю фахівців реляційних СУБД.
Моделювання 4-х типів NoSQL баз даних з використанням глобальних
1) Ключ / Значення
Реалізація сховища типу ключ / значення з використанням глобальних тривіальна:
keyValueStore (key) = valueнаприклад:
telephone ( "211-555-9012") = "James, George" telephone ( "617-555-1414") = "Tweed, Rob"Цього достатньо для створення простих ключ / значення сховищ, але використання глобальний дозволяє зберігати кілька атрибутів для кожного ключа. наприклад:
telephone (phoneNumber, "name") = value telephone (phoneNumber, "address") = valueБази даних NoSQL зазвичай не надають автоматичних методів для індексації значень. Чи не роблять цього і глобальний. Якщо необхідно отримати доступ до даних за допомогою іншого ключа, то, відповідно, необхідно створити другий глобал з альтернативним властивістю як ключ. Для сховища, наведеного вище, індексний глобал на ім'я може мати наступну структуру:
nameIndex (name, phoneNumber) = ""наприклад:
nameIndex ( "James, George", "211-555-9012") = "" nameIndex ( "Tweed, Rob", "617-555-1414") = ""На діаграмі глобальний з даними і індексними значеннями буде виглядати наступним чином:
Індексний глобал дозволяє організувати нам доступ до номерів телефонів по імені, в той час як основний глобал з даними надає доступ до даних по телефонним номером.
Дуже важливою і потужною характеристикою глобальний є те, що вузли глобальний зберігаються як відсортований набір (як показано на малюнку вище).
Метод перебору вузлів дозволяє послідовно перебирати вміст кожного Глобал. Для того щоб зробити телефонний довідник (з сортуванням по імені) на основі нашої моделі, було б достатньо пройти по вузлах індексного Глобал nameIndex і потім використовувати метод get для доступу до даних Глобал з телефонами.
Такий метод перебору вузлів відомий як функція order, яка представлена тим або іншим способом в різних мовах і фреймворк. Наприклад, функція getNextSubscript клієнта node-mdbm Node.js ( github.com/robtweed/node-mdbm ):
mdbm.getNextSubscript ( 'nameIndex', [ 'James, George'], function (error, results) {});в нашому випадку поверне індекс вузла Глобал наступного за 'James, George':
{SubscriptValue: 'Tweed, Rob'}СУБД GT.M і Cache добре оптимізовані для обходу індексів подібним чином, і при наявності індексних глобальний пошук в даних буде дуже швидким.
2) колоночного сховища
Табличні або стовпчик NoSQL бази даних, такі, як BigTable, Cassandra або Amazon SimpleDB, дозволяють зберігати дані у вигляді розріджених таблиць, а це означає, що кожен рядок в таблиці може мати значення в деяких, але не обов'язково у всіх, шпальтах. База даних SimpleDB йде далі і дозволяє осередку в стовпці містити більше одного значення.
Схема реалізації за допомогою глобальних
columnStore (columnName, rowId) = valueнаприклад:
user ( "dateOfBirth", 3) = "1987-01-23" user ( "email", 1) = "[email protected]" user ( "email", 2) = "[email protected]" user ( "name", 1) = "Rob" user ( "name", 2) = "George" user ( "name", 3) = "John" user ( "state", 1) = "MA" user ( "state ", 2) =" NY "user (" telephone ", 2) =" 211-555-4121 "Глобал, створений вище, представляє наступну таблицю:
3) документи-орієнтовані
Документо-орієнтовані NoSQL бази даних, такі, як CouchDB і MongoDB, зберігають колекції пар ключ / значення, а всередині них рекурсивно колекції колекцій. Як правило, JSON , або JSON -подібні структури використовуються для подання таких "документів".
Відображення документа або об'єкта в глобальний: імена зберігаються як індекси, а значення як значення. Для масивів використовується числовий індекс для подання позиції в масиві. Розглянемо, наприклад, документ JSON:
{Key: "value"}Він може бути відображений в глобальний як:
document ( "key") = "value"Візьмемо більш складний JSON документ:
{ 'Name': 'Rob', 'age': 26, 'knows': [ 'George', 'John', 'Chris'], 'medications': [{ 'drug': 'Zolmitripan', 'dose' : '5mg'}, { 'drug': 'Paracetamol', 'dose': '500mg'}], 'contact': { 'eMail': '[email protected]', 'address': { 'street' : '112 Beacon Street', 'city': 'Boston'}, 'telephone': '617-555-1212', 'cell': '617-555-1761'}, 'sex': 'Male'}І його зберігання в глобальний:
person ( "age") = 26 person ( "contact", "address", "city") = "Boston" person ( "contact", "address", "street") = "112 Beacon Street" person ( "contact "," cell ") =" 617-555-1761 "person (" contact "," eMail ") =" [email protected] "person (" contact "," telephone ") =" 617-555-1212 " person ( "knows", 1) = "George" person ( "knows", 2) = "John" person ( "knows", 3) = "Chris" person ( "medications", 1, "drug") = " Zolmitripan "person (" medications ", 1," dose ") =" 5mg "person (" medications ", 2," drug ") =" Paracetamol "person (" medications ", 2," dose ") =" 500mg " person ( "name") = "Rob" person ( "sex") = "Male"4) графові сховища
Графові NoSQL баз даних, такі, як Neo4j, використовуються для представлення складних мережевих зв'язків в термінах вузлів та зв'язків між вузлами (так званий "ребер"), з парами ключ / значення додаються до вузлів і зв'язків.
Класичний приклад використання графових баз даних - це уявлення соціальних мереж. Розглянемо наступний приклад:
Він може бути представлений в глобальний як:
person (personId, "knows", personId) = "" person (personId, "knows", personId, key) = value person (personId, "name") = nameнаприклад:
person (1, "knows", 2) = "" person (1, "knows", 2, "disclosure") = "public" person (1, "knows", 2, "age") = "3 days" person (1, "knows", 7) = "" person (1, "name") = "Rob" person (2, "name") = "John" person (7, "knows", 2) = "" person (7, "knows", 2, "disclosure") = "public" person (7, "knows", 2, "age") = "2 years" person (7, "name") = "George"Узагальнена схема зберігання для графових БД може виглядати, наприклад, так:
node (nodeType, nodeId) = "" node (nodeType, nodeId, attribute) = attributeValue edge (edgeType, fromNodeId, toNodeId) = "" edge (edgeType, fromNodeId, toNodeId, attribute) = attributeValue edgeReverse (edgeType, toNodeId, fromNodeId) = ""5) Інші моделі даних
Область застосування глобальний не обмежується тільки NoSQL моделями. Вони також можуть бути використані для моделювання інших типів баз даних:
- XML DOM / XML бази даних. Продукт EWD ( www.mgateway.com/ewd.html ) За своєю суттю є реалізацією XML DOM на основі глобальний. По суті, це графовая структура, яка представляє вузли (і пов'язані з ними типи) і відносини між ними (наприклад, FirstChild, LastChild, NextSibling, батьків і т.д.). По суті, EWD дозволяє GT.M і Cache поводитися як native-XML базі даних.
- Реляційні таблиці. Обидва продукти, GT.M і Cache, моделюють реляційні таблиці на глобальний (в разі GT.M це здійснюється за допомогою додаткового продукту, відомого як PIP, а Cache має вбудовану підтримку реляційних таблиць). В обох випадках можна використовувати SQL-запити як всередині продуктів, так і через стандартні інструменти сторонніх виробників.
- Сховища збережених об'єктів. Cache в цьому випадку йде ще далі і надає пряме відповідність між збереженими об'єктами і реляційними таблицями. В останніх версіях Cache представлена нова технологія Java eXTreme ( www.intersystems.com/java ), Значно розширює можливості Java-розробників по збереженню об'єктів і даних.
висновок
СУБД GT.M і Cache можуть підтримувати будь-які або всі моделі баз даних, описаних вище, причому одночасно, якщо буде потрібно. Тобто можна мати аналоги Redis, CouchDB, SimpleDB, Neo4j, MySQL і XML сховищ, що працюють в одній і тій же базі даних в один і той же час.
GT.M і Cache мають інтерфейси для мов програмування і фреймворків, включаючи Python, Java, .NET і Node.js, що робить їх ідеальними кандидатами для NoSQL рішень.
Як GT.M, так і Cache в результаті є ідеальними кандидатами для підприємств, яким потрібні технології NoSQL, при додаткових вимогах до зрілості, міцності і надійності. Хоча обидва продукти мають комерційну ліцензію і працюють на широкому спектрі обладнання та операційних систем, GT.M особливо цікавий тим, що доступний як Open Source продукт при запуску на платформі GNU / Linux.
Підготував Олег ДМИТРОВИЧ
За матеріалами статті Роба Твіда і Джорджа Джеймса www.mgateway.com/docs/universalNoSQL.pdf
Com/10things/?