Смутное время СУБД

На протяжении всей многолетней истории ИТ внимание ученых уделялось чему угодно, но не таким ключевым понятиям, как информация и данные, причем последние особенно пострадали. По умолчанию считался достаточным сам факт их существования, и почти никто не задумывался о таких принципиально важных вопросах, как соотношение между данными и информацией. В итоге сейчас, когда человечество столкнулось с проблемой Больших Данных, обнаружилась чудовищная избыточность хранения — одна и та же информация хранится в сотнях мест, плодятся паразитные данные, а единственным способом борьбы с нерациональным использованием пространства остаются ограниченные по своим возможностям методы дедупликации. Вне зоны внимания осталось то, какими собственными качествами обладают данные, как следует реагировать на изменения их потоков и многое другое. Такое положение сохранялось, пока область приложения компьютеров в бизнесе ограничивалась учетными задачами, а в других отраслях при расчетах с приемлемыми по объемам исходными данными ни у теоретиков, ни у практиков сложившаяся ситуация забот не вызывала. Но когда заговорили о Больших Данных, неожиданно обнаружилась неподготовленность ИТ к работе с невиданными прежде объемами. Выяснилось, что «священная корова» — господствовавшая идея сведения всего разнообразия данных к таблицам реляционных СУБД — морально устарела.

Любая неподготовленность обычно вызывает смуту в общественной жизни, а в случае с СУБД спешно стали появляться альтернативные реляционным решения для работы с неструктурированными данными, и их зачем-то тоже стали называть базами данных, хотя для этих новых форм хранения данных следовало бы придумать что-то иное, например data store. Если бы не произошло распространения понятия «базы данных» за реляционные границы, то и не было бы сравнений и противопоставления старого и нового. А если бы еще не привилось в данном контексте крайне неудачное новообразование «NoSQL», которое позже смягчили до «Not only SQL», то, возможно, градус дискуссии вокруг СУБД был бы заметно ниже.

На русском языке хроника баталий, развернувшихся в экспертном сообществе, с максимально возможной полнотой представлена в работах Сергея Кузнецова и его коллег, в которых отражены позиции всех ведущих специалистов по СУБД, поэтому их можно считать обязательными для всех, кто хочет разобраться в истории возникновения кризиса СУБД. В первую очередь стоит порекомендовать статью «Год эпохи перемен в технологии баз данных», в отношении которой, однако, можно предположить, что глубокая профессиональная заинтересованность авторов в реляционных СУБД отразилась на их оценке альтернативных взглядов специалистов-прагматиков. Дело, конечно же, не в самих СУБД — табличные данные были, есть и будут, но не все представление о мире можно уложить в прокрустово ложе табличных форм. Проблемы данных разнообразнее и шире, чем то, что укладывается в рамки реляционных моделей, и нет ничего удивительного в возникновении альтернативных подходов, уступающих по строгости академическим работам, но имеющих практический выход. Кстати, ситуацию в СУБД можно сравнить и с происходящим в общественно-политической жизни, когда политики — авторы многолетнего застоя — начинают предлагать пути выхода, исключающие все альтернативные варианты.

Проблемы данных

Десять лет назад мне посчастливилось пообщаться с Адамом Босуортом, в тот период техническим руководителем компании BEA, позже перешедшим в Google, а сегодня организовавшим собственную компанию. На вопрос «Как вы можете представить схему эволюционного процесса развития корпоративных систем?» Адам ответил следующее: «Корпоративные системы начались с плоских баз данных и c множества не связанных между собой приложений, но вскоре стало ясно, что «изоляционизм» приложений невозможен. Потребность в обмене данными лет тридцать тому назад была удовлетворена средствами систем обмена сообщениями (messaging backbone), но эта шина оказалась слишком «толстой», к тому же для согласования несвязанных между собой двоичных кодов требовались тяжеловесные адаптеры. Первая революция в области корпоративных систем, нацеленная на преодоление сложностей такого рода, совпала с появлением реляционных СУБД, обладающих качеством, которое можно назвать «самоописанием». Их преимущества заключаются в том, что, во-первых, используя словари и языки запросов, разные приложения смогли обращаться к общим информационным массивам. Во-вторых, средствами и возможностями реляционных баз смогли пользоваться люди, ничего не понимающие в их устройстве, появились клиенты. Работать стало легче и удобнее, хотя при этом приложения по-прежнему образовывали сложную путаницу, и именно эта сложность не была преодолена, поскольку до поры с ней можно было мириться».

Масштабировать «спагетти» невозможно, и первым решением, распутывавшим клубок на входе (front-end), стали Web-серверы. Затем потребовалось масштабировать нагрузку внутри системы (back-end), и эту задачу решили серверы приложений. В результате сложилось некоторое промежуточное «квазистабильное» состояние технологий. Вместе с XML стартовал очередной переходный процесс — вторая революция корпоративной архитектуры, которая пока еще пребывает в зародышевой стадии.

Для понимания происходящего нужно учитывать то, что динамика процессов изменения корпоративных систем имеет определенную специфику. Со стороны кажется, что все происходит быстро, но не стоит забывать, что и у реляционных СУБД ушло шесть – восемь лет на путь от изобретения до массового использования. Кроме того, кто, например, мог сто лет назад представить современную потребность общества в энергии? Потребность возрастает по мере формирования спроса: чем доступнее ресурс, тем больше на него спрос.

Волна сервисных архитектур (Service Oriented Architecture, SOA) поднялась двадцать лет спустя после появления СУБД, и сейчас она пребывает примерно в том же состоянии, что и электрификация в 1910 году. Все только начинается.

В чем заключается качественное отличие нового этапа эволюции корпоративных систем от предыдущего? На этот вопрос Босуорт ответил так: «Прежде всего — в отношении к данным, точнее, в изменении их доминирующей модели. В этой области предшествующие двадцать лет были периодом очевидного господства систем управления базами данных, а следующие двадцать станут годами управления самоописываемыми (self-describing), расширяемыми сообщениями. Повсеместно будет наблюдаться переход от складирования данных к их распределению». Невольно напрашивается бытовое сравнение: раньше по воду ходили с ведром к общему колодцу, а сейчас водоразборный кран есть в каждом домохозяйстве.

Чтобы лучше разобраться в динамике изменений, происходящих в масштабе отрасли, необходимо определить понятие, которое Адам назвал «разрушительной новацией» (disruptive innovation), отменяющей прежние представления и вызывающей очередную волну технической революции. Принципиально важно, что с каждой новой волной количество пользователей ИТ увеличивается, причем их привлекают не собственно технологии, а возможности, предоставляемые очередной новацией. В качестве примеров новых технологий можно привести изобретение микросхемы или Ethernet, а соответствующими им новациями стали персональный компьютер и локальная сеть. Новация — это новое потребительское качество, основанное на технологиях. Локальные сети приобрели популярность не благодаря техническим возможностям Ethernet, а потому, что появился более удобный и эффективный доступ к данным. В 90-е годы мы стали свидетелями двух революций, вызванных TCP/IP. Сначала развитие локальных сетей, SQL и ODBC стало толчком к развитию клиент-серверных архитектур, а позже стандарты HTML и HTTP сформировали импульс к тому, что мы сейчас называем интернет-технологиями.

Камень преткновения — теорема CAP

На пути к созданию современных распределенных систем работы с данными (и data store, и data base) имеется барьер в форме теоремы CAP — самой трудной проблемы управления данными. Изначально теорема CAP звучала очень лаконично: есть три возможных качества распределенных систем — Consistency, Availability и Partition Tolerance, выбирайте любые два. А при толкованиях ее обычно формулируют так: «Невозможно одновременно обеспечить следующие три свойства распределенной системы — согласованность, доступность и устойчивость к разделению сети». Теорема, которую еще называют теоремой Брюера, была предложена коллегой Майкла Стоунбрейкера по Калифорнийскому университету Беркли, профессором Эриком Брюером, основателем компании Intkomi, который сейчас работает в Google. Теорема CAP универсальна, ее действие распространяется за пределы СУБД, и она стала поводом для весьма серьезной дискуссии, одна из ветвей которой развернулась в блоге Стоунбрейкера. Основная заметка, с которой она стартовала, называется «Ошибки в системах баз данных, согласованность «в конечном счете» и теорема CAP», вся полемика переведена Сергеем Кузнецовым.

Применительно к распределенным системам согласованность в теореме CAP предполагается мгновенной (immediate consistency) — клиент может убедиться, что набор операций завершается одновременно. Распределенная система является доступной, если на каждый запрос, полученный не отказавшим узлом, должен быть получен ответ. Устойчивость системы к разделению сети предполагает сохранение жизнеспособности системы при потере отдельных узлов. Все эти качества объединяются в набор свойств BASE (Basically Available, Soft-state, Eventual consistency): Basically Available — система находится в состоянии готовности, но не всегда; Soft-state (мягкое состояние) противоположно Hard-state (жесткое состояние) — предполагается, что система может выйти из заданного состояния; Eventually Consistent — узлы согласованы, но не всегда.

Критики работы самого Брюера и его продолжателей, попытавшихся более формально доказать теорему, противопоставляют набору BASE классический набор качеств реляционных СУБД, известный как ACID: Атомарность (Atomicity) — что бы ни произошло, пользователь должен знать, в каком состоянии находится его транзакция; Согласованность (Consistency) — каждая успешная транзакция по определению фиксирует только допустимые результаты; Изоляция (Isolation) — события, происходящие внутри транзакции, должны быть скрыты от других одновременно выполняемых транзакций; Долговечность (Durability) — система должна гарантировать сохранность результатов при сбоях. Идея ACID была предложена Джимом Греем в середине 70-х, а аббревиатура появилась в начале восьмидесятых и с тех пор стала священной коровой СУБД, выхоленной и вылощенной со всей математической строгостью. И вдруг появляется «плебейская» теорема CAP со своим условием BASE, ее и теоремой-то признать сложно.

К сожалению, в многочисленных обсуждениях не отмечена одна чрезвычайно важная сторона теоремы CAP и то, как она соотносится с ACID. Условия CAP были сформулированы существенно позже, чем ACID, и случилось это в совсем ином технологическом окружении, когда распределение вычислений и хранения данных стало не просто естественным, а обязательным. Грей же представил свое видение, когда ничего, кроме централизованных компьютерных систем, еще не было, а если и существовали отдельные распределенные системы, то как экзотика. В силу этого теорема CAP имеет более широкий смысл, а ACID относится к ее частному случаю. Естественно, что частный случай может удовлетворять более строгим ограничениям, чем общий. Таким образом, теорема CAP исторически не имеет никакого отношения к реляционным базам данных, следовательно, противопоставление ACID и CAP с методологической точки зрения ошибочно.

Движение NoSQL

Сегодня масштабирование становится одной из важнейших характеристик информационных систем в целом, в том числе распределенных систем хранения данных, баз данных, и вот тут начинаются проблемы. Главное достоинство реляционных СУБД состоит в технологиях обеспечения надежного хранения с минимальными издержками на резервирование, но оказывается, что те же самые технологии становятся препятствием к масштабированию — они неудобны для терабайтных объемов данных. В итоге Amazon, Google и им подобные стали создавать собственные системы хранения нереляционного типа, где масштабирование достигается за счет использования тысяч идентичных серверов, по которым данные распространяются сегментированно. Изменения, возникающие в каком-то одном месте, асинхронно распространяются на все с ним связанные, поэтому согласованность достигается, но не сразу, то есть Eventually Consistent, как и в теореме CAP. Такие базы с 2009 года стали крайне неудачно называть NoSQL, и сейчас их насчитывается более сотни: Dynamo (Amazon) и BigTable (Google), Apache Cassandra, HBase (Hadoop) и Hypertable.

На самом деле термин NoSQL был предложен еще в 1991 году. Один из первых юниксоидов Карло Строцци в своей статье «NoSQL — A relational database management system« использовал его в совершено ином смысле, не предполагая отхода от реляционной модели. По мнению Строцци, было бы логичнее использовать хотя бы NoREL, что точнее соответствует сути явления. На конференции в Сан-Франциско в 2009 году один из основателей движения NoSQL Эрик Эванс «схулиганил», дав следующее определение: «NoSQL — это все те динамические альтернативы, которые позволяют решить проблемы, нерешаемые средствами РСУБД». Слово «динамические» использовано не случайно и отражает специфику предмета — область действия NoSQL (Web-приложения) практически не пересекается с областями, которые в корпоративных приложениях занимают реляционные СУБД.

Однако NoSQL — не единственные нарушители монополии реляционных СУБД, помимо них еще есть объектные и графовые базы, а также СУБД, ориентированные на XML (pureXML). Заметим, что самые первые СУБД были NoSQL и появились в середине 60-х, среди них MultiValue, входившая в состав операционной системы PICK и Mumps (предшественница Cache InterSystems). Позже была создана документальная база Lotus Domino, принципы которой унаследовала CouchDB, а вот то, что следовало бы назвать NoREL, началось с memcached — базы, целиком резидентной в памяти. Затем в 2004 году Google стала использовать базу BigTable, а после этого ежегодно стали возникать десятки новых СУБД и процесс получил название «движение NoSQL».

Почему именно движение, а не технология? Скорее всего потому, что входящие в него компании (сейчас их более сотни) объединены общими принципами, которых они придерживаются при создании новых баз, а не строгой, выработанной в академической среде теорией. В конечном итоге они не объединены в какое-то протестное движение. Само движение NoSQL возникло по следующим основным причинам:

• успехи в развитии процессоров и систем хранения сделали возможной работу с гораздо большими объемами данных, чем прежде, а существующие СУБД не отвечают требованиям времени;
• массовое распространение аналитических методов работы с данными требует создания систем, работающих в режиме, близком к реальному времени;
• готовность 24/7 достаточно просто получить для статичных HTML-файлов путем резервирования серверов, но проблематично для СУБД;
• появился ряд приложений, например RFID, требующих от СУБД способности мгновенно «заглатывать» огромные объемы данных, что, разумеется, не исключает традиционных процессов ETL (Extract, Transform, Load);
• изменилось качество данных — сегодня основную часть составляют неструктурированные данные.

Необходимость удовлетворения всем этим требованиям вынуждает вспомнить о теореме CAP и пойти на какие-то компромиссы, ослабляя одни условия, чтобы соблюсти другие. Вот почему приходится отказаться от строгости реляционных баз и искать иные решения. Характер компромиссов зависит от требований к приложениям: в одних случаях это может быть время реакции, в других — готовность, в третьих — масштабирование. Возможность для масштабирования в системах типа NoSQL основывается на том, что они реализуются из изолированных узлов, не имеющих общих ресурсов (shared nothing), такие системы пригодны для горизонтального масштабирования.

Очевидно, что соответствующие этим требованиям СУБД должны быть распределенными, но при разработке распределенных СУБД возникает целый ряд специфических вопросов. Как именно обеспечивать распределение? В реляционных СУБД это делается либо вручную, либо по какому-то заранее определенному правилу. СУБД должны быть предельно просты с точки зрения распределения, вплоть до полной автоматизации этого процесса, либо распределенность должна быть их внутренним качеством. Еще один компромисс связан с тем, что сложно обеспечить высокую реактивность одновременно и на записи, и на чтении.

Еще одна специфическая особенность большинства баз типа NoSQL заключается в отсутствии схемы данных, их называют schemaless. Без формальной, имеющейся заранее схемы у разработчика больше возможностей — он может включать в базу те данные, которые не были заблаговременно предусмотрены, но трудно сказать, к чему schemaless приведет в долговременной перспективе. Можно выделить несколько основных качеств, отличающих системы NoSQL:

• способность к горизонтальному масштабированию по большому числу серверов;
• способность реплицировать и распределять данные по большому числу серверов;
• упрощенный интерфейс;
• ослабленные по сравнению с ACID требования к согласованности;
• эффективное использование памяти и дисков;
• способность динамически наращивать атрибуты хранимых данных.

Эти качества обеспечиваются тем, что системы NoSQL строятся по принципу shared nothing, то есть из изолированных узлов, не имеющих общих ресурсов, чем обеспечиваются неограниченное горизонтальное масштабирование и высокая скорость выполнения операций записи и чтения. Однако при необходимости достижения максимальной производительности или масштабирования каждая из таких систем не всегда соответствует ограничениям ACID.

Системы NoSQL весьма разнообразны по своим функциональным возможностям, от простейших с распределенным кэшированием (Memcached) до сложных с распределенными таблицами (Google BigTable). Каждая из систем демонстрирует преимущества тех или иных технологических решений: например, Memcached — использование индексов в оперативной памяти (in-memory indexes) как средства для масштабирования, распределения и реплицирования данных по узлам; Dynamo была первой в согласованности типа Eventual Consistency, то есть с негарантированной актуальностью данных в текущий момент, но с гарантией, что обновление данных будет со временем распространено по всем узлам; BigTable — возможность распространения неизменных записей (persistent record) по тысячам узлов.

Системы хранения данных, попадающие в категорию NoSQL, можно разделить на три группы: системы с ключами (Key-value Store), документальные системы (Document Store) и системы с расширяемыми записями (Extensible Record Store).

Системы с ключами

Системы с ключами устроены достаточно просто — чаще всего они хранят совершенно произвольные данные (значения) и индексы для доступа к ним. Обычное решение такого типа сводится к хэшированию в оперативной памяти, но оно должно быть дополнено механизмами, обеспечивающими долговременность хранения, и такими дополнительными функциональностями, как репликация, версионность, блокирование и сортировка. Клиентский интерфейс позволяет взаимодействовать с данными: вносить, удалять и просматривать записи по ключам — причем в большей части подобных систем использование вторичных ключей исключено. Главное преимущество систем Key-value Stores в хорошей горизонтальной масштабируемости. Такие системы, как Voldemort, Riak и Tokyo Cabinet, помимо хэширования в памяти обеспечивают полноценную работу с дисками, а другие ограничивают работу с дисками только резервным копированием. Значительная часть систем NoSQL написана на имеющем датские корни функциональном языке программирования Erlang, предназначенном для создания распределенных вычислительных систем.

Представительный список Key-value Stores включает как минимум пару дюжин решений: Amazon SimpleDB, Berkeley DB, Chordless, Dynomite, GenieDB, GT.M/M.DB, HamsterDB, Hibari, KAI, KaTree, Kumofs, LightCloud, Membase, Memcachedb, NorthScale, Orient Key/Value Server, Pincaster, PNUTS/Sherpa, Project Voldemort, Redis, Riak, Scalaris, Tokyo Cabinet/Tokyo Tyrant. Кроме полноценных решений имеется ряд проектов, примечательных теми или иными находками.

Проект Voldemort поддерживается социальной сетью LinkedIn и назван в честь одного из персонажей эпопеи про Гарри Поттера. Здесь поддерживается контроль версий, согласованность изменений, но репликация выполняется асинхронно, поэтому полная согласованность данных не гарантирована, хотя и обеспечивается согласованность большинства реплик данных, поскольку имеется специальный механизм для разрешения возможных конфликтов. В кластер могут произвольным образом добавляться новые узлы — система сама их обнаруживает и вводит в работу. Система с открытыми кодами Riak была создана компанией Basho в середине 2009 года, и хотя это в основном решение key-value stores, создатели относят его и к document stores. Данные хранятся в текстовом формате JSON, используемом для обмена данными. Riak поддерживает только первичные ключи, по которым возможен поиск, а механизм обработки запросов отсутствует. Согласованность данных между узлами обеспечивается подсистемой чтения/записи. Система с открытым кодом Redis разработана программистом-одиночкой Салваторе Санфилиппо, живущим на Сицилии и при этом работающим на VMware. Система Scalaris аналогична по функциональности Redis и была разработана в Институте Цузе (Берлин), но отличается более совершенным механизмом доступа к узлам, что улучшает балансировку нагрузки. Система Tokyo Cabinet/Tokyo Tyrant состоит из сервера Tokyo Tyrant с интерфейсной билиотекой Tokyo Cabinet, то и другое написано одним программистом Микиро Хиробаяши. Система Membrain разработана в компании Schooner Tehnologies и отличается распространением методов хэширования на твердотельные диски. Помимо Membrain эта же компания выпускает полноценную реляционную СУБД SchoonerSQL.

Документальные системы

Документальные системы (Document Stores) отличаются тем, что их объекты хранения могут быть вложенными или объединены в списки, а атрибуты и имена могут изменяться в процессе работы. От кортежей в РСУБД эти объекты отличаются отсутствием общей для них схемы, что расширяет диапазон допустимых значений. Такая трактовка понятия «документ» отличается от принятой (текст или файл Word), а от Key-value Stores эти системы отличаются поддержкой вторичных ключей и возможностью использования различных типов документов в одной базе. Известные реализации Document Stores различаются не только на уровне технологий, но и по используемой их авторами терминологии, что усложняет сравнение. Серийно выпускаются SimpleDB, CouchDB, Jackrabbit, MongoDB и RavenDB, а среди экспериментальных разработок можно отметить OrientDB, RaptorDB, SisoDb и Terrastore.

Amazon SimpleDB — распределенная система, написанная на Erlang, поддерживается Amazon.com в рамках концепции Amazon Elastic Compute Cloud (EC2) и Amazon Simple Storage Service (S3) и является частью сервисов Amazon Web Services. Apache CouchDB — система с открытым кодом, поддерживаемая компаниями Couchbase и Cloudant. Ее основной автор и основатель Couchbase Дамье Кац в прошлом был разработчиком Lotus Notes, он решил перенести идеи Lotus Notes на простейшие кластеры, отсюда и название CouchDB как акроним от cluster of unreliable commodity hardware («кластер ненадежного бытового железа»). Название MongoDB образовано от слова «гомогенная» (humongous) — эта система с открытым кодом поддерживается компанией 10gen, созданной Дуайтом Мирриамом после того, как он продал Google свою прежнюю компанию DoubleClick.

Системы с расширяемыми записями

Системы с расширяемыми записями (Extensible Record Stores или Wide Column Stores) представлены всего четырьмя продуктами: BigTable, Cassandra, HBase и Hypertable. Немногочисленность понятна, сложность таких систем достаточно высока — это не поле деятельности для одиночек.

Стимулом для создания Extensible Record Store стал успех BigTable от Google, где в основе модели данных, действительно представляющей собой большую таблицу, лежат традиционные строки и колонки, распределяемые по множеству узлов. Строки делятся по узлам кластера в соответствии со значениями первичных ключей, без использования хэш-функций, следовательно, для выполнения запроса не приходится обращаться ко всем узлам. Колонки распределяются путем объединения в группы (column groups) с учетом того, какие колонки разумнее хранить рядом. Чтобы совместить деление по вертикали и горизонтали на практике делят всю таблицу сначала на таблицы меньшего размера по числу групп столбцов, а затем по горизонтали по значениям ключей.

Apache Cassandra — распределенная система управления базами данных, рассчитанная на создание высокомасштабируемых и надежных хранилищ огромных массивов данных. Проект был разработан в недрах Facebook, а позже был передан в Apache Software Foundation. Имеются промышленные решения на базе Cassandra в Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace и Twitter, хотя сама Facebook отдала предпочтение HBase. Кластер серверов, обслуживающий Cassandra, насчитывает более 400 машин и содержит данные размером в 300 Тбайт.

Apache HBase — это аналог BigTable, но вместо файловой системы GFS (Google File System) здесь используется распределенная файловая система Hadoop. История HBase началась с работ компании Powerset, которой потребовались средства для работы с большими объемами данных на естественных языках. Сейчас эта компания входит в состав Microsoft и в ней работает группа ученых мирового класса, например, Барни Пелл, сооснователь и CTO Powerset. В частности, HBase поддерживает обработку транзакций, что нетипично для систем NoSQL.

Hypertable — проект с открытым кодом, поддерживаемый бывшими сотрудниками компании Inktomi, где трудился Эрик Брюер, автор теоремы CAP. Они образовали компанию с целью создания базы для больших данных, ориентированной на критически важные приложения. В целом Hypertable аналогична HBase, но написана на C++, в то время как HBase — на Java, и, возможно, поэтому она заметно быстрее.

К движению NoSQL примыкают еще несколько типов СУБД:

• графовые базы, среди которых Neo4j, OrientDB и DEX, а также Blueprints, Apache Hamma, Google Pregel;
• переживающие второе рождение объектно-ориентированные системы управления базами данных (ООСУБД), в которых данные моделируются в виде объектов, атрибутов, методов и классов;
• близкие к ООСУБД объектно-ориентированные хранилища, и в первую очередь GemFire. После приобретения компании GemStone корпорацией VMware и выхода продукта VMware vFabric GemFire внимание к этому жившему своей отдельной жизнью продукту заметно усилилось.

Движение NewSQL

В отличие от всех трех разновидностей систем NoSQL классические реляционные базы имеют априорно заданную схему, язык запросов, а обработка транзакций удовлетворяет требованиям ACID, что критически важно для ряда бизнес-приложений, но вызывает проблемы с масштабированием. В 2004 году с выпуском СУБД MySQL Cluster был предпринят один из первых шагов для преодоления этой проблемы путем замены стандартного для MySQL движка InnoDB на распределенный NDB (Network DataBase). MySQL Cluster распределяет данные по множеству серверов, поддерживает архитектуру shared nothing, а данные могут находиться и в оперативной памяти, и на дисках. В MySQL Cluster реализован механизм синхронной репликации, поэтому он обеспечивает масштабирование, но в ограниченных пределах, существенно меньших, чем это удается в случае NoSQL.

Качественно новым шагом стало создание СУБД VoltDB, рассчитанной на хранение данных в оперативной памяти (in-memory database designed). С мая 2010 года доступна версия VoltDB Community Edition 1.0, распространяемая по лицензии GPLv3, а позже появилась коммерческая версия VoltDB Enterprise Edition. В основе VoltDB лежат результаты проекта по созданию экспериментальной базы H-Store, выполненного командой из нескольких университетов, в состав которой входили такие ученые, как Майкл Стоунбрейкер, Сэм Мэйдден и Даниэл Абади.

В отличие от VoltDB, MySQL Cluster и всех остальных, компания Clustrix предлагает комплексное решение (то, что сейчас принято называть appliance) — это специализированный компьютер для больших данных, полностью поддерживающий SQL и ACID, где объединено совместимое с MySQL программное и аппаратное обеспечение, а распределение данных по узлам осуществляется автоматически и полностью прозрачно для пользователя.

Продукт ScaleDB построен примерно по той же схеме, что и MySQL Cluster, — в нем InnoDB замещен собственным движком, но обеспечен доступ каждого из серверов, входящих в кластер, к каждому диску, что ограничивает масштабирование, однако архитектура shared everything architecture гарантирует соответствие ACID.

Компания ScaleBase не пыталась изменить что-то в существующих базах — ее балансировщик нагрузок ScaleBase Load Balancer позволяет собрать в кластер серверы, на которых установлены известные СУБД MySQL, Oracle Database, Microsoft SQL Server или IBM DB2. Решение ScaleBase обеспечивает координацию транзакций.

Создатели NuoDB/NimbusDB утверждают, что их система полностью поддерживает SQL и ACID, но при этом не имеет ничего общего ни с одной из существующих СУБД, секрет состоит в оригинальной дисциплине взаимодействия между узлами. Опубликованных материалов очень мало, для того чтобы понять принципы работы этой системы.

Перечисленные продукты составляют движение NewSQL, начавшееся в сентябре 2007 года, когда Майкл Стоунбрейкер и его коллеги опубликовали статью «Конец одной архитектурной эпохи (Пора все переписать)» («End of an Architectural Era (It's Time for a Complete Rewrite)»), в которой пересмотрели пройденный СУБД путь и наметили перспективы для выхода из сложившейся ситуации. В статье описывается проект базы H-Store, способной работать на кластерах, но авторы называют их гридами, видимо под влиянием Oracle. После коммерциализации этот проект вылился в СУБД VoltDB, ставшую родоначальницей направления, которое с 2011 года именуют NewSQL.

Со времени публикации основополагающей статьи прошло почти пять лет, и можно подвести некоторые промежуточные итоги, снова обратившись к Стоунбрейкеру. Юбилейный выпуск ежеквартальника The NoCOUG Journal, посвященный 25-летию пользовательской группы Northern California Oracle Users Group (ноябрь 2011), открывается интервью Стоунбрейкера, в котором ему был задан вопрос: «Считаете ли вы, что наступила пора полностью переписать существующие системы управления базами данных?». Вот его ответ: «Я полагаю, что в любом сегменте рынка продукция традиционных производителей может быть побита с преимуществом на порядок или два чем-то другим, новым. В области обработки транзакций — это NewSQL, в области хранилищ данных — это системы поколоночного хранения, в области комплексной аналитики — это массивы хранения (array stores), а в области работы с неструктурированными данными — это NoSQL». В блоге Communication of the ACM (BLOG@CACM) есть запись Стоунбрейкера «NewSQL как альтернатива NoSQL и Old SQL для новых приложений OLTP», где он, помимо OldSQL, вводит еще OldOLTP и NewOLTP, расставляя все по своим местам.

В рамках NewSQL возникла еще очевидная секта MoreSQL, основатель которой и самопровозглашенный «духовный лидер» Алекс Татьянц выступает с девизами: «Разработчики, присоединяйтесь к MoreSQL, назад, к золотому веку реляционных баз данных!» и «SQL везде» (SQL Everywhere).

Движение DBaaS

Облака могут оказать не менее революционизирующее воздействие на СУБД, чем просто количественный рост данных. Под их влиянием независимо от описанных движений формируется третье, представленное несколькими проектами. Среди них совместный проект Microsoft Research и университетов штата Миннесота, и калифорнийского в Сан Диего, претенциозно названный, как пятая книга Библии, Deuteronomy (второзаконие). В Google создается СУБД Tenzing, которая будет работать поверх MapReduce, а в знаменитой Лаборатории компьютерных наук и искусственного интеллекта Массачусетского технологического института создается СУБД Relational Cloud. Целью всех эти проектов является распространение реляционных подходов, SQL и ACID на облачные системы хранения данных.

***

Под влиянием Больших Данных и облаков обнаружилась неподготовленность ИТ к работе с невиданными прежде объемами информации, львиная доля которой хранится сегодня в РСУБД, — господствовавшая до сих пор идея сведения всего разнообразия данных к таблицам морально устарела. Вместе с тем предлагаемые сегодня решения также в большинстве своем носят фрагментарный характер, и на рынке все еще нет полноценных решений для обработки огромных массивов неструктурированных данных различной природы, поступающих в режиме реального времени из многочисленных источников.