Tag на русском

OrientDB или здравствуй дерево !

Несмотря на избитость и некую внешнюю пошарпанность темы, я все-таки подниму ее из пыли земной, слегка отряхнув, зажгу и воткну пылающим факелом знаний в темную ж… БД-невежества.

«Если в руке SQL база, то все вокруг кажется таблицами»

Народная программистская пословица

2D Тупик

И года не может пройти в нашем беспокойном мире без революций в той или иной сфере, конечно, не считая вечно кровавого политического болота. К счастью не политики, а именно окружающий мир (где они, к сожалению, тоже присутствуют) и определяет как будут выглядеть базы сегодняшнего и завтрашнего для. Наблюдается опеределенная тенденция — устаревшие реляционные 2D базы со своим псевдо-стандартным SQL отходят в прошлое, их место занимают более востребованные облачные БД с новыми возможностями и новыми языками запросов (NewSQL), а порой вовсе без них (NoSQL). Двухмерные таблицы старых БД не в состоянии обеспечить поддержку, по крайней мере, двух самых насущных парадигм, применяемых при решении современных социально-ориентированных задач, в которых первостепенную роль играют связи (виды связей) и/или отношения между обьектами. Первая парадигма — это иерархичность (трехмерность) классов обьектов и связей между ними (for ex. тот же социум со своими связями разного масштаба, производственные процессы, базы знаний и т.д.) Вторая — обьектно-ориентированная природа данных в задачах и, как следствие, желание естественным образом сохранить ее в БД. Увы, 2D базы никогда не были в состоянии хранить и более менее сносно осуществлять поиск в древовидных и графоподобных структурах данных, так как тяжеловесность доступных алгоритмов просто выходит за всякие рамки. Приведу яркий пример для MySQL (привет фэйлбук !) — табличка времени исполнения, на современном 4-ядерном лаптопе с 8GB RAM, запроса выдачи дерева друзей для всего 1000 юзеров при разной, и совершенно не впечатляющей глубине, (до 5) дерева [взято из книги "Neo4j in Action"] :

ГлубинаВремя выполнения (секунд) для 1`000 юзверейРезультат (записей)
20.028~900
30.213~999
410.273~999
592`613.150~999

Вот оказывается почему большинство социальных сетей жутко тормозит и глючит ;)

А если мы усугубим ситуацию и добавим поиск сразу по нескольким разным классам отношений между обьектами, например — выдать дерево всех друзей юзеров и их друзей и друзей их друзей и т.д., которые смотрели фильм X И играют в игру Y, поиск производить по уровню вложенности не более 5, результат ограничить уровнем вложенности 3 ? Думаю любая 2D база тупо загнется при таком JOIN запросе даже на смешном, по понятиям социальных сетей (несколько тыщ), количестве пользователей. А если типов связей больше сотни и дерево глубиной в сотни тысяч уровней ? Об осуществлении каких либо сложных аналитических операций над таким обьемом данных здесь можно сразу напрочь забыть, тут бы как-то справится со стандартной web нагрузкой. Та база, о которой пойдет речь в этой заметке легко осуществляет такой поиск за единицы миллисекунд — можете сопоставить ее мощность с вышеприведенными данными для 2D баз. Эх, как же сложно выживать фэйлбукам в обнимку с MySQL, т.е. с орками^H^H^H^H^HOracle в этом жестоком мире …

От синематографа к HD3D

Занимаясь, на досуге, разработкой облачной персональной базы знаний, я вновь уперся в старое и уже порядком доставшее противоречие — невозможность эффективного использования современных (в том числе и облачных) БД для простеньких задач представления знаний. Эти БД — просто «не тянут», применяемый там язык SQL похоронен под бетонным непрактичным стандартом (несмотря на трезвый анализ могучего Стонебрейкера «Future Trends in Database Systems», сделанный еще в конце 80-ых, который видимо пофигу, считающими себя не менее могучими, разработчикам современных БД), а их «универсальные» типы данных — это все тот же каличный набор от древних компьютерных мастодонтов 60-х, с небольшими вариациями.

Гуголь на вопрос «что же теперь делать ?» выдал две фотки грустных обезьянок, одну карикатуру на Гитлера, рисующего черной краской на стене надпись «П.здец всему» и ссылку на OrientDB. О, пожалуй, последнее стОит более тщательного рассмотрения …

«Выборы, выборы, кандидаты …» (C) Ленинград

Так какие же сытные ништяки обещает нам OrientDB по сравнению с общепринятыми решениями ?

Кратко :

  1. обьектная база по определению, что позволяет создавать афигенские типы данных включая, например, такую экзотику в БД как абстрактные классы (!)
  2. NoSQL с поддержкой SQL — вот такой вот хитрый и завораживающий микс
  3. поддержка ACID транзакций (вот Вам батенька и тупой NoSQL …)
  4. поддержка скриптовых языков на стороне клиента и сервера — из впечатляющих бонусов: Javascript (!).
  5. поддержка stored procedures, которые можно ваять на Javascript, Ruby, Scala, Java или печальном Groovy. Процедуры могут вызывать друг друга, поддерживаются рекурсия, вызов через REST, авто-маппинг параметров по имени и работа с обьектами от плагинов
  6. работа с деревьями, включая расширения SQL аля create vertex/edge и traverse с кипой примочек
  7. поддержка distributed и HA в ввиде master-master репликаций
  8. эффективная поддержка multi-tenancy и partitioned данных вплоть до уровня одной записи и легко вытекающая отсюда возможность использовать security at record level (horizontal security)
  9. open source, т.е. открыты исходники, протоколы и документация. Последняя в принципе далека от идеала, так что пользу придется извлекать в основном из первых двух источников
  10. неплохая скорость работы и отсутствие требований к гигабайтам свободной памяти как, к примеру, у БД от патентных троллей и скупщиков кр^H^H opensourc’а
  11. несмотря на то что сама база писана на джаве, имеются коннекторы под другие языки и довольно подробно описан бинарный протокол, зная который можно за короткий срок написать свой собственный коннектор под какой-нить новый супер-пупер язык (у меня ушло всего 2 дня на беглую реализацию варианта для C++). Есть коннекторы под PHP, NodeJS, etc. и наконец есть возможность работы просто через REST.

В общем лучший способ с чем-то познакомиться — это заюзать данную технологию, так что — приступим. Для начала можно поставить, создать базку, скормить ей тестовый набор данных, поиграться и потом сделать некие предварительные выводы.

Ставить, ясен пень, лучше с сырцов, так как общеизвестно, что новые баги делают нашу жизнь лучше и интересней, в отличие от старых и унылых one.

1. убеждаемся что в системе стоит jdk, если нет — качаем его с файлопомойки патентного тролля-неудачника

2. Набираем :

svn checkout http://orient.googlecode.com/svn/trunk/ orient-read-only
cd orient-read-only
ant installg

installg соберет и поставит в ../releases/orientdb-graphed-x.x.x-SNAPSHOT полную, так называемую graph версию базы, где есть поддержка tinkerpop blueprints и gremlin. Зачем оно надо прямо сейчас ? — хрен его знает, но все равно приятно, что оно на всякий случай есть под рукой ;)

3. Заходим в …/orientdb-graphed-x.x.x-SNAPSHOT/bin и запускаем server.sh При первом запуске в config файле БД автоматически сгенерятся пароли для админки сервера (root user password) и дефолтный юзер/пароль для вновь создаваемых БД (обычно user:admin, pass:admin). Как видим запуск этой БД очень прост даже для искушенных в своем невежестве юзверей. Конфиг лежит в …/orientdb-graphed-x.x.x-SNAPSHOT/config/orientdb-server-config.xml, там же можно разрешить запускать скрипты на сервере (для этого надо выставить параметр enabled в true для com.orientechnologies.orient.server.handler.OServerSideScriptInterpreter класса)

4. На другом терминале запускаем …/orientdb-graphed-x.x.x-SNAPSHOT/bin/console.sh и попадаем в командный монитор БД. Нужен он для выполнения базовых операций с БД, как-то: ее создание, администрирование, проверка запросов и т.д., все выделенные ниже команды запускаются именно из него.

Итак создаем базу :

create database remote:/test root root_pass local graph

Параметр remote говорит нам о том, что с базой будем работать по сети, тип storage local значит, что база будет располагаться на файловой системе сервера (можно указать тип memory — тогда база самоликвидируется при перезапуске сервера) и graph обозначает тип базы (graph или document). Первый тип используется когда нужна вся мощь работы с графами, второй имеет более простую и быструю их реализацию — связи могут быть только однонаправленными, не могут иметь properties, отключен blueprints и gremlin и т.д.

Также как и в обычных БД, OrientDB оперирует записями. Есть разные типы записей, но в основном используется понятие «документа» (document) — это запись, принадлежащая определенному классу и имеющая набор произвольных атрибутов.  Атрибуты иногда называют полями (fields) или свойствами (properties). Ну а что такое класс, должны хорошо знать те, кто читал Страуструпа первой редакции на ночь для достижения быстрого, крепкого и безмятежного сна.

Посмотреть какие классы есть у нас в базе можно командой classes, создать новый класс командой create class :

create class Contacts

Классы с натяжкой можно было бы приравнять к таблицам в обычной 2D БД, если бы не одно но:

insert into Contacts (name,surname) values (‘James’,'Bond’)

select * from Contacts

#RIDnamesurname
0#13:0JamesBond

Здесь мы можем наблюдать прикольное свойство OrientDB — не обязательно задавать тип и перечень полей записи при создании определенного класса или самой записи — это можно делать на лету (при вставке например). Но это еще не все — набор полей может быть разным/индивидуальным для каждой записи данного класса или произвольно меняться для любой записи в операциях insert/update.  Это свойство позволяет OrientDB гибко работать с данными, набор параметров которых, к примеру, изначально не известен или меняется по ходу работы приложения:

insert into Contacts (name,age) values (‘Batman’,30)
update Contacts set city = ‘Gotham’ where name = ‘Batman’

select * from Contacts where name = ‘Batman’

#RIDnameagecity
0#13:1Batman30Gotham

Ясен пень — работать в режиме стандартной БД, уныло вставляя все поля в соответствии с жесткой схемой, заданной для каждой записи тоже можно. Другая фишка OrientDB, которая прямо вытекает из вышеприведенной — это непосредственное управление (произвольный CRUD для произвольной записи) данными типа «associative array» или «map» внутри любой записи. Для этого команда UPDATE расширена подкомандами ADD (для массива) PUT (для map) и REMOVE для обоих типов :

update Contacts ADD tags = ‘superhero’
update Contacts PUT phones = ‘mobile’, ‘+007′ where name = ‘James’
update Contacts PUT phones = ‘office’, ‘+MI5′ where name = ‘James’
select * from Contacts where name = ‘James’

#RIDnamesurnametagsphones
0#13:0JamesBond[1]{mobile=+007, office=+MI5}

orientdb> display 0
—————————————————
ODocument — Class: contacts id: #13:0 v.3
—————————————————
name : James
surname : Bond
tags : [superhero]
phones : {mobile=+007, office=+MI5}

Ну а юзать массивы и maps внутри записей можно также, как это обычно и принято, конечно если БД такое умеет и позволяет. В случае с OrientDB это делается где-то так :

select phones from Contacts where phones.size() > 0
select phones from Contacts where phones.keys() in ‘mobile’

Продолжение впереди …

Революция в мире баз данных

Как-то занимаясь разработкой ТЗ для одного заказчика столкнулся в очередной раз с проблемой хранения/выборки данных в кластере — как уже надоело препарировать проекты под NoSQL базы ! И тут как будто кто решил разом прекратить все эти мучения и уткнул меня носом прямо в NuoDB. «Это что-то !», как любят говорить герои в буржуйских фильмах. NuoDB — это новое слово в технологиях баз данных от самого Джима Старки ! Да, того самого Старки, который в свое время придумал многоверсионные базы и тип BLOB, создал Interbase, участвовал в разработке FireBird и MySQL. В 2008 году он перешел из MySQL в стартап Nimbus чтобы плотно заняться разработками в области облачных баз данных. Проект NuoDB (переименованный из NimbusDB) - это без сомнения то, чего уже много лет ждали многие разработчики, пользователи и просто бизнесмены. И теперь с уверенностью можно сказать что они таки-да, дождались ;) Менеджмент компании NuoDB любезно разрешил мне перевести и опубликовать документ «Introduction to NuoDB» с целью поближе познакомить русскоязычное комьюнити с этим необыкновенным продуктом. Как говорят — «совершенная технология неотличима от магии», чего же больше в NuoDB первого или второго, ее будущим пользователям вскоре предстоит узнать самим.
Итак, встречайте — NuoDB !


NuoDB, обзор продукта

Масштабируемость, ACID Транзакции, SQL

NuoDB это первая в мире облачная база данных, которая поддерживает транзакции. Частные и общедоступные облака — это новый, захватывающий способ предоставления компьютерных услуг с наблюдаемой тенденцией вполне определенной экономической неизбежности их распространения. Но на этом поприще существует и большая техническая проблема: управление транзакционными данными обычно не масштабируется более чем на один сервер или небольшой кластер, который ведет себя как однин сервер. До сегодняшнего дня в мире баз данных не существовало решений, которые бы могли одновременно предоставить масштабируемость, транзакции и SQL. NuoDB изменила этот мир. Представьте себе, что вы сможете динамически расширять свои транзакционные базы данных путем простого удаления или добавления узлов в живую, работающую систему. Представьте, что есть возможность перемещения работающей базы данных из датацентра в Нью-Йорке на сервера в Токио без простоя ваших приложений. Представьте что вы можете указать вашей базе данных задействовать несколько запасных серверов в Лондоне и получить эту дополнительную мощность всего через несколько секунд. Или что вы можете иметь сколь угодно много работающих копий ваших баз данных одновременно с минимальным влиянием на общую производительность. Представьте, что часть вашей базы данных может работать на серверах вашего частного датацентра, а часть на общественном облаке или что в моменты пиковой нагрузки вы можете мгновенно увеличить мощность базы поключив какие либо другие, внешние вычислительные ресурсы. Представьте, что вы в состоянии на лету решать, какие базы данных и на каких серверах или облаках должны быть размещены. Что вам никогда больше не нужно будет вручную оптимизировать вашу базу, и при всем этом она будет иметь производительность, которая значительно превосходит традиционные клиент-серверные и клиент-кластерные решения.
Эти и другие новейшие достижения возможны благодаря радикально новой архитектуре баз данных основанной на P2P технологиях. NuoDB снаружи выглядит и ведет себя точно так же как и традиционные SQL базы данных, но внутри вкорне от них отличается. Это новый класс решений для нового класса центров обработки данных. Когда промышленность перешла от мэйнфреймов к клиент-серверным архитектурам, возникла необходимость в базах данных нового образца и появились базы данных архитектуры клиент/сервер. Так и в настоящее время, когда все двигаются по направлению к публичным и частным облакам возникла необходимость в базе данных изначально созданной для работы в облаках. NuoDB иногда даже называют «Святым Граалем» облачных вычислений. Ведь любой другой подход использования облачных баз данных заставит вас отказаться от всех ваших успешных наработок, инструментов и навыков, забыть про SQL и ACID транзакции. Неужели это все должно быть принесено в жертву только для того чтобы перенести БД в облачный датацентр будущего ? К счастью запатентованная технология NuoDB навсегда избавляет от этих проблем так как блестяще сочетает возможности масштабирования, ACID и SQL. Эта статья ставит своей целью познакомить читателя с возможностями продукта NuoDB.

NuoDB изначально создана для работы в облаках.

NuoDB это:

1. SQL
2. Транзакции
3. Масштабируемость (Elastic)
4. Multi-tenant
5. Не требует администрирования (Zero admin)
6. Гео-распределенность
7. Non-Stop
8. Расширяемость в реальном режиме времени
9. Высокая производительность

NuoDB основана на реляционной модели данных, с всеми современными расширениями. Поддерживается стандартный язык запросов SQL и API стандарт JDBC. Ее внешняя модель данных — те же строки и таблицы. С точки зрения клиента базы данных NuoDB, она ничем не отличается от обычных клиент-серверных баз данных, которые в настоящее время используются почти в каждом бизнесе на планете. Весь доступ к данным осуществляется через ACID транзакции: атомарные, согласованные, изолированные и долговечные. Все транзакции NuoDB или удачны или нет, т.е. выполняется принцип атомарности. Управление конкурентным доступом с помощью многоверсионности (MVCC) дает возможность каждой NuoDB транзакции иметь согласованное представление о данных — принцип согласованности. Ни одна транзакция не увидит незавершенные действия другой транзакции — принцип изолированности. И наконец соблюдение принципа долговечности достигается благодаря тому что в NuoDB данные распределяются в виде обьектов между всеми ее серверами в облаке, которые специально предназначены для хранения информации. NuoDB работает на динамически изменяемой группе машин, которая называется »Хор». Хор включает в себя два типа узлов: узлы транзакций и узлы архивирования, которые соответственно обрабатывают транзакции и выполняют операции записи и чтения с диска. Любое количество транзакционных и архивных узлов могут быть добавлено или удалено в любой момент, но минимальный хор должен обязательно содержать один транзакционный и один архивный узел. Добавление транзакционного узла не требует какой либо настройки для БД — вы просто указываете базе имя нового сервера и учетные данные для доступа к нему. Добавление транзакцонных узлов увеличивает общую пропускную способность БД, удаление соответственно уменьшает. Добавление архивых узлов увеличивает обьем и избыточность хранения данных в базе вместе с увеличением ее пропускной способности. Узлы в хоре NuoDB могут быть гетерогенными, состоять их произвольного набора различных серверов, аппаратных средств и операционных систем с совершенно разной производительностью. Любое количество экземпляров NuoDB может работать на любом наборе NuoDB узлов. Любой узел может быть выделен для отдельной БД или использоваться несколькими базами данных в любой конфигурации. Другими словами хоры могут иметь выделенные узлы, могут частично перекрываться узлами с другими хорами или могут даже полностью с ними совпадать. Традиционно SAAS поставщики предоставляют multi-tenant сервисы для приложений своих клиентов, разместив данные нескольких клиентов в одной клиент-сервер/клиент-кластер базе данных. Конечно, это решение будет работать и в NuoDB, но это более не является необходимым. Несколько баз данных NuoDB может запросто сосуществовать на общей серверной ферме. Это позволяет датацентрам применять решения, которые максимально используют их серверные и сетевые ресурсы. Т.е. персонал публичного облака, которое имеет более чем 10000 баз данных своих клиентов сам сможет решить, какие базы данных, в каком количестве и на каких машинах будут размещены, и все это можно проделать в режиме реального времени. Инсталляция NuoDB очень проста. В отличие от традиционных баз данных, которые могут потребовать несколько дней на конфигурацию прежде чем их можно будет использовать, NuoDB является простой системой, которая может быть запущена на любом узле в течение нескольких минут. Ценное время DBA должно быть потрачено на проектирование баз данных, а не конфигурацию компьютера.

Настройка традиционной базы данных занимает 10-15% всего времени администраторов баз данных.

NuoDB не требует тюнинга. Данные автоматически распространяются через хор, по необходимости. NuoDB не нуждается в partitioning, sharding или striping. На производительность NuoDB существенно не влияет ни размер дискового блока ни любые другие связанные с диском параметры. Отсутствие процедуры тюнинга БД как такового значительно сокращает обьем работы DBA. Балансировка нагрузки в хоре NuoDB происходит автоматически и не требует никаких усилий от DBA. NuoDB гарантирует, что все узлы под управлением данной базы данных в равной степени буду заняты и использованы. Таже не существует какого-либо отдельного механизма балансировки нагрузки. Более отзывчивые узлы в хоре просто получат больше работы. В сочетании с multi-tenant способностью использование облака может быть оптимизировано очень небольшими административными усилиями.

Репликация и High Availability (HA) составляют более 10% времени администрирования обычных БД.

NuoDB автоматически обеспечивает репликацию обьектов, которые находятся как в памяти так и и на диске. Все усилия администрирования сводятся к подключению по мере необходимости дополнительных узлов архива. Высокая доступность (HA) не является чем-то особенным для NuoDB — она является основой ее архитектуры. Эта база данных устойчива к отказам узлов, части облаков, датацентров или сетевой инфраструктуры. Архивные узлы в NuoDB содержат полноценные резервные копии данных — это значит, что больше не нужно заниматься бэкапами в традиционном их понимании. Естественно NuoDB позволяет это делать если по каким-то причинам это необходимо. Имея несколько архивных узлов вы можете просто перевести один в автономный режим и поместить его в хранилище. Или можете его отключить, сделать бэкап файловой системы и включить вновь. В подавляющем большинстве случаев вы можете смело забыть про необхоимость бэкапа вашей базы — намного проще и дешевле просто добавить еще один архивный узел для повышения избыточности ваших данных. Также удаленные или внешние архивные узлы смогут обеспечить актуальный бэкап даже в случае полного отказа вашего датацентра. Резервное копирование это просто еще одна DBA задача которая полностью автоматизирована в NuoDB. Апгрейд оборудования и/или операционных систем не влияет на работу NuoDB и может быть сделан постепенно прямо на живой системе. Машины можно отключать, обновлять и подключать вновь к работающему хору, без никакого влияния на приложения, работающие с данной базой данных. Машины могут быть заменены на совершенно другие с различной архитектурой, конфигурацией памяти, операционной системой и производительностью. В хоре более быстрые машины будут просто выполнять больше работы, чем более медленные. Также само программное обеспечение NuoDB можно обновлять постепенно — узел за узлом. В NuoDB при смене ПО базы данных на более новую версию нет необходимости в остановке обслуживания. Сравните ситуацию с обыкновенной реляционной базой: время перехода на новую версию БД может легко парализовать IT инфраструктуру на несколько дней. NuoDB может быть размещена одновременно в нескольких географически разнесенных центрах обработки данных, при этом будет обеспечиваться распределение нагрузки, отказоустойчивость и независимость такого разделения. Для таких инсталляций рекомендуется, чтобы каждый датацентр имел не менее двух транзакционных и двух архивных узлов. Дополнительные узлы могут быть добавлены и удалены по желанию. При этом если один из датацентров откажет или потеряет связь с другим — база данных останется полностью доступна для всех клиентов, которые все еще могут подключится к оставшейся части. Архивные узлы NuoDB могут быть размещены на удаленных серверах, например с целью резервирования. Живая копия базы может находится где-то в подземном бункере или на серверах любых компаний, которые предоставляют услуги хранения данных. СУБД облако NuoDB с двумя или более архивными узлами не имеет критических точек отказа — любой узел может выйти из строя или может быть удален, а оставшиеся узлы продолжат работу. Пока хотя бы один транзакционный и один архивный узлы продолжают работать, база данных остается доступной. NuoDB не нуждается в незагруженных или бездействующих серверах для обеспечения бесперебойности в ее работе. Целые сервера, в том числе и архивные узлы могут быть отключены для ремонта или апгрейда, после включения они сами синхронизируются и встанут в строй. Таким образом можно внутри облака постепенно обновлять и само ПО NuoDB особо не влияя на ее работу. Когда последний сервер будет обновлен, облако прозрачно переходит на новую версию БД. NuoDB не имеет ограничений по масштабируемости, следовательно производительность является простой функцией от количества машин, которые обслуживают базу. Помимо своей масштабируемости ядро системы по самой своей природе является чрезвычайно производительной базой данных. NuoDB можно рассматривать «базу данных-в памяти», в то же время не требующей, чтобы все данные хранились в памяти. Большинство высоконагруженных операций выполняется исключительно в памяти, по этой причине NuoDB быстрее на том же железе чем традиционные базы данных типичных клиент-сервер / киент-кластер архитектур.

Резюме

NuoDB является ключевым решением для облачных вычислений. Датацентры будущего будут основаны на масштабируемых, multi-tenant облаках из недорогих и взаимозаменямых машин. Существует все, необходимое для использования этой новой архитектуры центров обработки данных, как аппаратные средства, так и системное и прикладное программное обеспечение. А с NuoDB у нас теперь есть и решение последней оставшейся ключевой проблемы облаков :

NuoDB однозначно обеспечивает безгранично масштабируемые транзакции !

Copyright NUODB, Inc. All rigts reserved


P.S. Стал доступен общий технический обзор NuoDB, в частности есть сравнения по масштабируемости и производительности — http://vimeo.com/33785505 и обзор архитектуры + getting started - http://vimeo.com/48533135

Перепечатка и/или копирование данной статьи без письменного разрешения правообладателей запрещена.