`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

NoSQL. И никаких «революций»

+1717
голосов

Раньше мы жили в эпоху PC, потом — в эпоху пост-PC, и вот теперь и то и другое почти никому не интересно и фактически не используется как термины (волна упоминаний сошла на нет ещё год назад). Сейчас, похоже, наступила новая эпоха — Internet of Things (IoT), Big Data и NoSQL. Похоже, в самом этом перечне специфики эпохи речь идёт даже не о взаимосвязанных явлениях, а о чем-то цельном, но мы ограничимся только рассмотрением NoSQL. И попробуем одновременно разобраться с этим понятием, взглянуть на конкретные его проявления и даже не забыть разные косвенные эффекты, порожденные «NoSQL эпохой». Естественно, с той степенью детализации, которая ещё не обрушивает на читателя миллиарды деталей, нюансов и сложностей (хотя некоторые детали не оставим без внимания).

(в предыдущем абзаце не обошлось без сарказма)

От всех модных в ИТ терминов (они какое-то время у всех на слуху, потом же как-то само собой забываются) NoSQL не отличается в главном — толком никто не знает, что это такое. Да, для NoSQL есть «определение» в Wikipedia. И, хоть среди снобов новой волны уже модно презирать Wikipedia как источник информации, на него стоит обратить внимание. Потому что... толком оно ничего не объясняет. Разве что подчёркивает очевидный факт: NoSQL — это не термин и не аббревиатура, и никто, опять же, толком и точно не знает — «не SQL» ли это, «не только SQL» или даже не «Network optimized Storages and Query Languages» ли (это я сам придумал, почему бы нет?).

Вот в таком невнятном, ещё и весьма скандальном (о чём придётся сказать пару слов), мы и будем разбираться. Хотя бы просто для наведения порядка в голове.

Для здравости восприятия мира примем, что слово NoSQL — волшебное заклинание, и не надо заниматься его десакрализацией. Означает оно некоторый фильтр, позволяющий разным специалистам в зависимости от квалификации по-разному просеивать все имеющие и возникающие как грибы системы управления базами данных (СУБД), а также близкие к ним по назначению разработки, которые не совсем СУБД, с целью обоснования уверенности утверждения: это — NoSQL, а вот то — нет, или наоборот. В качестве скрытых критериев этой фильтрации используется один фундаментальный — NoSQL СУБД не должна реализовывать реляционную модель данных, и, соответственно, не должна использовать язык запросов SQL. Пока просто умолчим о состоятельности этого фундаментального критерия. Но если ограничить NoSQL-фильтр только им, окажется, что история NoSQL стара как мир. Больше того. Реляционные СУБД сами стали следствием развития своих весьма специфических предшественниц, баз данных, разработчики которых не исповедовали и не использовали реляционную модель.

Именно из-за всего смутного исторического фона придется сделать отступление, иллюстрирующее возврат давно использованных технологий в NoSQL-эпоху. Например, некогда, в начале 1970-х годов, тогда молодая (сейчас — второй по масштабам немецкий производитель ПО, входящий в три десятка самых крупных в мире) немецкая компания Software AG выпустила СУБД ADABAS, ставшую заслуженно популярной везде, в том числе и в Армии США, и загадочным образом — даже всё ещё в находящемся за «железным занавесом» СССР (например, с 1987 года ADABAS де-факто стала основой вычислительного центра энергетической системы СССР). Та ADABAS радикально отличается от известной сейчас ADABAS D, основанной на реляционной модели данных. В основе той ADABAS была модель данных, представленная с помощью инвертированных списков (или инвертированных таблиц). Потом в самой Software AG перешли к реляционной модели данных, и очень характерно время, когда это произошло — середина 1990-х годов, причём в самой Software AG разработками реляционных баз, похоже, не занимались, в 1994 году компания купила немецкого же производителя с характерным названием «SQL-Datenbanksysteme GmbH», и вместе с ним все его наработки, которые и стали ADABAS D. Специфика такой трансформации позволяет говорить о том, что к середине 1990-х годов реляционные СУБД полностью, окончательно и на некоторое время победили, иначе производитель такого масштаба, с таким продуктом и с такой репутацией, как Software AG, ни за что не изменил бы курса, ещё и за счет фактически сторонней разработки. Возвращаясь к оригинальной ADABAS, СУБД на основе инвертированных списков, из сегодняшнего дня невозможно не заметить, что ключевые для современных web-сервисов мегапопулярные технологии, являются в некотором роде... откатом к той ADABAS. Например, Apache Lucene — библиотека-подсистема полнотекстового индексирования и поиска (которую используют настоящие монстры «вебдванолья» вроде Twitter, с их масштабами и требованиями ко времени отклика всей системы в целом), она по сути является механизмом, основанным на... инвертированных списках. То есть, по большому счёту, аналогом той самой древней ADABAS. То же самое можно сказать, например, и о ранних СУБД с иерархической моделью данных (IMS от IBM, конец 1960-х годов), и о более позднем развитии этой модели — сетевой, на основе которой была создана СУБД IDMS (первая половина 1970-х годов), наследники этих систем сейчас, в мире NoSQL, представлены более общими «графовыми» СУБД. И хоть NoSQL-фильтр у некоторых специалистов требует вычеркнуть ADABAS и подобные ему ранние разработки из списка «подлинных NoSQL», историю забывать не следует, слишком много «нового» выплывает из хорошо известного старого.

Теперь, наверное, надо немного поговорить о ещё одном важном. Мы располагаем фактом — NoSQL существует как явление. Стало быть, что-то в SQL СУБД должно быть когда-то где-то не так, иначе бы эта технология продолжала всегда и во всём править СУБД-миром. Или придётся признать, что практики, создающие гигантского масштаба непрерывно работающие «вебдванольные» (и не только) системы, ничего не смыслят (для любителей конспиративных теорий — сражаются с «заговором» ключевых производителей реляционных СУБД, что, в принципе, одно и то же). Третьего варианта нам не дано.

Мы не станем вдаваться в детали теории и практики реляционных СУБД, тем более, что ничего особо страшного во всём этом нет и тем ещё более, что «чистой теоретической реляционной СУБД» как овеществления идеи Эдгара Кодда (на основе которой была создана не одна алгебраическая теория) вообще не существует в природе. Ну и нельзя проигнорировать тот факт, что один из отцов реляционной теории баз данных, Кристофер Дейт, вообще считает современный язык запросов SQL сплошным искажением теории Кодда и сигналом необходимости возврата к подлинно реляционной модели данных («Третий манифест», К. Дейт и Х. Дарвен).

Буквально в одном абзаце — реляционная модель данных (и отражающий множественные нюансы практической ее реализация язык запросов SQL) предусматривают непременное наличие «схемы БД» — тщательно продуманной, отработанной и, наконец, в идеале, почти формальными способами доведенной до определённого уровня качества (нормализация) модели прикладной области, объекты (события etc) которой отображаются записями БД. Причём считающиеся классическими проектные процедуры построения схемы БД (в том числе и нормализация) ориентированы на достижение высоких показателей при решении с помощью СУБД типовых задач обработки транзакций. То есть, от СУБД в таких задачах требуется быстро и надёжно заносить в БД множество относительно небольших записей или обновлять содержимое уже занесенных записей. Здесь сразу следует вспомнить времена, когда формировалась реляционная теория. И соответствующие тем временам характерные запросы потребителей БД. Это совершенно «доинтернетовые» времена, что исключительно важно в контексте всех следующих рассуждений. Времена заказного проектирования «под большого стабильного заказчика», масштабы которого из сегодняшнего дня уже считать большими трудно (что ничуть не отменяет сложности). И в те времена разработка серьёзных БД не отличалась тривиальностью, что замечательно иллюстрируется ставшими уже культовыми провалами больших проектных процессов в смежных с БД мирах, вроде всевозможных CRM, ERP и во всём прочем, что по сути является надстройкой над БД. Наличие схемы БД предусматривает проектный процесс, в котором задействованы как специалисты в прикладной области со стороны заказчика БД, так и владеющие теоретическим аппаратом специалисты по БД и, наконец, практики, прекрасно знающие особенности и нюансы конкретной СУБД. Этот процесс итеративный и затратный во всех смыслах. И, что главное, итог его работы — схема БД, — является «замороженной конструкцией». Она согласована, утверждена и реализована. Любые модификации её требуют повторного итеративного процесса проектирования схемы. Безусловно, можно пытаться (и все пытаются) придумать такую схему реляционной БД, которая упрощает процессы модификаций, но если внимательно порыться поиском в интернете по ключевым словам «relational DB schema flexibility», можно понять, что это «вечнозелёная тема» — или до сих пор мучительная для практиков, или бесконечный источник вдохновения для академической науки. Кроме гибкости схемы, в мире реляционных БД есть ещё множество нюансов. Из них стоит выделить не лучшую пригодность реляционных СУБД для обработки сложных запросов, связанную с изначальной их транзакционной ориентацией (модель прикладной области разбивается на множество таблиц, после чего сложные запросы превращаются в композитные операции с этим множеством таблиц с помощью всех разновидностей операции JOIN) и потребность в ресурсоёмкой денормализации при возникновении задач анализа накопленного в БД как чего-то цельного многомерного (одно дело — ежесуточная или ежемесячная генерация отчётов, совсем другое — оперативная аналитическая работа с БД). И, наконец, есть ещё «Вьетнам мира СУБД» — механизмы отображения данных из мира СУБД в мир прикладных программ и обратно (например, ORM, Object-Relational Mapping). Изначально создатели СУБД ориентировались на замкнутую модель использования своих продуктов (это же были времена мейнфреймов), много позже вычислительные ресурсы стали доступнее и «размазаннее» по разным аппаратным средствам, возникли клиент-серверные архитектуры, и, соответственно, всевозможные прослойки между СУБД и миром прикладным программ, неутомимо доставляющие море наслаждения практикам в этой области. Эти нюансы можно назвать идеологически-технологическими, и разработчики реляционных СУБД здесь используют все возможные решения и приёмы, чтобы улучшить показатели своих систем. И, безусловно, достигли выдающихся результатов. Которые, увы, никак не отменяют фундаментальных проблем с гибкостью схемы БД, о чём косвенно свидетельствует де-факто всем известное и многократно подтверждённое практикой правило «масштабные системы, ориентированные на потребности бизнеса (ERP, CRM) требуют подгонки бизнеса под эти системы, если пробовать наоборот — получается очень дорого и долго». И, наконец, самое главное. Реляционные СУБД — выходцы из времён, когда термина «software engineering» ещё не существовало и когда миром ПО пыталась править «computer science» (которая, как потом выяснилось, не очень и понятно что такое вообще). Об этом почему-то никто не говорит вслух. Время шло и стройные и изящные теоретико-множественные построения Кодда не раз ударялись о суровость реальности, идеи сверх-унификации и достаточности одного стандарта (SQL) «для всего» тоже как-то вошли в противоречие с реальностью, потому что в количествах появились подмножества и надмножества стандартного SQL, «объектные мапперы» (ORM) внесли во всё это множество чарующих нюансов. А потом как-то сама по себе возникла «software engineering», не книжная, а практическая инженерия. Для разнообразия требований реальности стало появляться разнообразие программных компонентов. Потом инженеры столкнулись с проблемой «масштабирования на всех уровнях», затем изменился характер заказчиков и появились всякие «быстрые» и совершенно не вписывающиеся в традиционно-бюрократические каноны проектные процессы. И всё стало очень непросто. И, кажется, наконец всё пришло к главному итогу любой инженерии — для всякой специфики лучше использовать то, что изначально создавалось с учётом этой специфики. И наступила «эпоха NoSQL».

Они очень разные

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

На дни написания этой статьи классификатор мира NoSQL выглядит примерно так:

NoSQL. И никаких «революций»

Я специально не переводил термины (потому что для многих нет устоявшихся вариантов перевода в русском языке), впоследствии мы всё проясним. И, естественно, «на глаз» выбрал размеры секторов мира NoSQL. И да, для внимательных и сразу — не спешите возмущаться от страшного и по вашему мнению невозможного ACID NoSQL, всему своё время.

Column-oriented NoSQL СУБД основаны на как бы «вывернутой наизнанку» традиционной реляционной модели. Которая, в классической транзакционной реализации предусматривает хранение информации о множестве сущностей в таблице (или наборе таблиц, на этом уровне нам всё равно) примерно такого вида:

NoSQL. И никаких «революций»

Описание какой-либо сущности — это строка таблицы (кортеж в теоретических терминах). Заносится в БД информация о сущности — записывается строка, выбирается информация — находится и прочитывается нужная строка. Всё замечательно, особенно для транзакционных операций. И всё достаточно «несложно» (в смысле — объяснимо) даже на уровне хранения данных — строки таблицы преобразуются в последовательности байтов (механизмом сериализации, например) и записываются на какой-то носитель. Но как быть, если основное назначение СУБД изменяется, и уже не столько важны быстрые типовые транзакции, сколько быстрая реакция на всякие сложные «внезапные запросы»? И если долговременных данных очень много, и они «подаются» в специфическую поддерживающую «внезапные запросы» СУБД большими «пачками», а не отдельными мелкими транзакциями по каждому «чиху» в реальном мире? В таком случае возникает некоторое несоответствие между потребностями «внезапных запросов» (ad hoc queries) и возможностями традиционной модели построчного табличного хранения — системе надо «перелопачивать» бездну записей для формирования подмножеств из них. Ещё веселее становится от потребности, например, внезапной фундаментальной модификации таблицы. Например, к ней понадобилось добавить новый столбец, потому что было выявлено важное новое свойство сущностей, да ещё и обладающее значением по умолчанию. Такая простая на вид задачка становится вовсе неигрушечной при построчном хранении данных, да ещё и схеме с морем таблиц (что соответствует реальности). В общем, собирав все требования воедино — данных реально очень много и они не помещаются в оперативную память, данные собираются редкими записями больших «пачек», а не большим числом маленьких транзакций, от СУБД требуется очень быстрая реакция на сложные «внезапные запросы» (а не на множество простых типовых), — программная инженерия ответила на них довольно простым решением. Хранить данные не сериализованными построчно, а столбцами. Причём это очень давняя идея, имеющая древние и использовавшиеся десятилетиями реализации (конца 60-х годов). Потом о них временно забыли, потому что потребности прикладных областей увеличились незначительно, а вычислительные мощности и возможности реляционных (SQL) СУБД резко возросли. А потом «выстрелил» интернет с его поисковыми машинами, неисчислимым количеством источников информации и потребностью во «внезапной» аналитике, со старой идеи сдули нафталин и её реализации теперь есть у кого угодно — и в недрах Google (BigTable), и в доступном всем мире open source (Apache Cassandra и Hbase), и в знаменитых коммерческих продуктах (Oracle RDBMS Columnar Expression, Microsoft SQL Server 2012 Enterprise Edition, IBM DB2, Teradata, Sybase IQ), и ещё в куче всяких реализаций. Изобилие разнообразных Column-oriented NoSQL СУБД даже вынуждает ввести внутреннюю классификацию, разделив всё множество реализаций на «чистые NoSQL Column-oriented СУБД» (по сути — овеществления мощных распределённых персистентных карт, maps) и «реляционные эмуляторы», но эти нюансы разве что вносят некоторую путаницу (надо всегда разбираться что есть что), не меняя сути. Подводя итоги и подчёркивая — все эти специфические «нетранзакционные СУБД» с инженерной точки зрения соответствуют потребностям строго определённого класса задач, для которого допустима редкая и неспешная запись в базу данных больших «пакетов» интегративной информации, но крайне необходима очень частая и быстрая выборка подмножеств данных для сложной и быстрой же обработки в оперативной памяти и возможность гибко и с минимальными затратами всех ресурсов изменять схему базы данных добавлением новых столбцов (характеристик сущностей).

Document Store. Если column-oriented NoSQL СУБД ещё имеют что-то общее с реляционными (SQL) СУБД (фундаментальную табличную модель), то класс «хранилищ документов» или «документоориентированных» СУБД (оба термина звучат невнятно и неуклюже, посему оставим их английский прообраз без перевода) — это уж точно NO SQL! (как лозунг) без всяких разночтений. Потому что всё, основанное на табличном представлении, предусматривает обязательность жёсткой структуры хранимых данных (или потому что они от природы такие, или в результате усилий по укладыванию всего нечёткого в одно прокрустово ложе одной табличной структуры), а вот Document Store фундаментально предназначены для работы с «как бы структурированными» данными. Это странное понятие вовсе не означает, что у данных нет структуры вообще. Она, безусловно, у них есть. А неопределённость возникает в том, что структуры документов могут отличаться от документа к документу и никакой общей «схемы» придумать для этого нельзя, а «городить» под каждую структуру отдельную базу данных — просто страшно. Например, строгие бюрократические механизмы всяких государственных или внутрикорпоративных систем ещё могут себе позволить затраты на создание источников полностью соответствующих заданной схеме данных (все знают эти кошмарные бланки, которые надо заполнять непременно полностью и которые отвергаются при помарках, плохом почерке и прочем). В интернете же ж такое невозможно. Интернет-пользователя даже самым жирным калачом уже трудно заставить пройти подобную процедуру (да и какие калачи в интернете, виртуальные, что ли?). Даже такая простая причина (хоть она всего одна из многих, но данные-то надо откуда-то «вынимать») привела к тому, что огромные объёмы извлеченных из интернет данных и в жёсткую табличную схему не уложить, и выбросить жалко (потому что для аналитиков, например, они представляют ценность). На деле из-за множества причин и возникла реальная потребность в таких базах данных, где схема — понятие или очень гибкое, или даже его вообще нет. Да, реляционные СУБД вроде как имеют в арсенале нечто для хранения чего-то подобного — блобы (blobs, этимология слова как раз и указывает на бесформенность хранимого). Но. Блобы — это как бы «вещи в себе», внутренности которых расположены абсолютно вне пределов схемы и мира базы данных. В Document Store, напротив, «бесформенное» (в смысле — не укладывающееся в строку таблицы) вводится в мир БД как основа. Что, само собой, в реальном мире существенно модифицирует абстрактное плохо объяснимое понятие «бессхемности» до вполне обозримой и внятной (но вовсе не простой) специфики. Впрочем, и о самом понятии «документ», и о некоторых нюансах мы поговорим позже, когда будем рассматривать ярких представителей этого класса NoSQL СУБД. Пока же ограничимся достаточным очевидным — самое неприятное в Document Store СУБД кроется именно в «размытости» общей модели и довольно вольном употреблении термина «бессхемность» (schemaless), что очень сильно отрывает всякие высокоуровневые описания достоинств красивых и полезных (там, где их возможности действительно полезны) разработок от реального опыта их применения (кто-то видел сложную программную конструкцию, кроме, конечно, операционной системы Apple iOS, реальное применение которой породило бы исключительно восторги?).

Key-value store. Этот условный класс (все перечисленные здесь классы, как и все не основанные на чётких критериях классификации, безусловно условны) объединяет как бы не совсем и СУБД. Но и как бы СУБД. Это, грубо говоря, «недоDocument Store» (в некоторых случаях — вполне Document Store). Потому что в таких системах содержательная часть документа — как бы бесформенный блоб (разве что маленький или не очень), вовнутрь которого СУБД даже не пытается заглядывать. Все реализации key-value store умеют ставить в соответствие некоторому ключу (данным, значение которых принято в качестве «ключевого») некоторые данные, внутрь которых СУБД не заглядывает. Собственно, это всё. Но это всё реализовано в key-value store исключительно эффективно (с учётом ряда технологических ограничений). Настолько эффективно, что представителям этого класса требуется мало что фиксированное время для поиска конкретного ключа в множестве ключей, так ещё и измеряемое миллисекундами. Соответственно, при учете всех технологических особенностей и ограничений, key-value store могут очень эффективно не только решать простую задачку поиска данных по ключу, но и выполнять куда более сложные композитные операции, например, со множеством ключей. В общем, с инженерной точки зрения, для key-value storage надо знать нюансы реализации и помнить главное — эти системы «не заглядывают в данные», они не для того. Деталей же мы коснемся позже.

Graph NoSQL store. Есть такая математическая теория графов, одновременно очень красивая, абстрактная и интенсивно используемая в самых разных прикладных областях. Граф, как математическая абстракция, всего лишь упорядоченное множество пар, образованных элементами двух множеств — узлов (вершин) и ребер. Казалось бы, что может быть проще. Но вот для прикладных задач нужны очень разные вариации представлений такого множества. Настолько разные, что, например, табличными возможностями реляционной СУБД один раз и для всех задач описать граф хорошо пока что ни у кого не получалось. Особенно если граф очень большой. Близкое к табличному матричное представление для графов двойственное (матрицы смежности и инциденции), и для решения одних задач подходит какое-то одно представление, для других оно же уже совершенно не годится (и безразлично, какое машинное представление матриц при этом используется, оно не является фундаментальным). Между тем, потребности в работе с графами только растут. Например, когда социальные сети стали явлением, ранее сугубо теоретический интерес к очень большим графам стал вполне практическим. То же самое можно сказать о современных реализациях больших нейронных сетей, о моделировании масштабных беспроводных систем, о сквозном машинном проектировании громадных технических систем (типа самолёта Boeing 787 Dreamliner), и о прочем, чего еще полтора-два десятка лет назад в нынешних масштабах никто не предполагал. Соответственно, свято место пусто не бывает, и после целого ряда специфических языков программирования, «заточенных» под работу с графами, появились и очень специфические базы данных. Пока мы о них скажем просто — если задача очевидно требует работы с большим графом, не стоит пытаться изобретать паровоз и моделировать граф с помощью каких-либо других СУБД. Это будет неэффективно по определению. А вот требует ли задача графового представления и можно ли получить благодаря этому представлению какие-либо ощутимые результаты на уровне совокупных характеристик всей информационной системы в целом — это уже вопрос к знатокам конкретной предметной области, специалистам в теории графов и практикам построения систем.

ACID NoSQL. Это не недоразумение. И не вопиющая ошибка. И не авторский волюнтаризм. Несмотря на то, что ещё полгода назад такое сочетание казалось настолько невероятным, что особо нервные могли за него и побить. Но всё меняется. И тут придётся опять вдаваться в некоторые пояснения. Многие разработчики NoSQL СУБД разных категорий, похоже, негласно сошлись в одном проектном решении — обеспечение полноценной ACID (атомарности, согласованности, изолированности и надёжности сложных транзакций) плохо сочетается с масштабированием, востребованным для типовых применений их разработок. Поэтому и полноценных ACID NoSQL СУБД долго не было. При этом, естественно, требования реальности в таких СУБД не забыты. И, например, большинство key-value storage обеспечивают атомарность и изолированность на уровне простых транзакций. Например, СУБД Apache Cassandra, key-value storage с возможностями, приближающими её к Document Storage, начиная с версии 1.1 обеспечивает атомарность операции записи в один набор «ключ — данные». Что означает — «пакетные» операции обновления одного набора мало что гарантированно сделают то, что должны сделать «по написанному», но и во время выполнения таких обновлений (операций записи) прочие операции чтения никогда не выдадут частично обновлённых данных. Многострадальная mongoDB обеспечивает атомарность операции записи на уровне документа (об этом будет позже), а так как документ в mongoDB — далеко не простая сущность, то и на уровне всего, что вложено в документ. Отказ от высокоуровневых ACID транзакций позволил существенно упростить протоколы взаимодействия и вообще отказаться от сложных многофазных распределённых commit-протоколов, заменив их самыми разнообразными, но куда более простыми, механизмами. Естественно, эта замена «не за бесплатно» — если возникает потребность в сложных транзакциях, программисту надо или дробить их на простые, или взваливать на себя заботу о реализации ACID на уровне приложения, работающего с такой СУБД. Или, если задача действительно строится на сложных транзакциях, грамотный архитектор вообще сразу выберет традиционную SQL СУБД и всё будет работать так, как должно работать. В том-то и дело, что NoSQL системы изначально разрабатывались для тех приложений, где сложные транзакции излишни. К слову, о всей этой специфике NoSQL старательно забывают очень многие авторы, пытающиеся «развенчать» и «вывести на чистую воду» NoSQL системы, апеллируя, например, к результатам рекордов TPC, дескать, раз в рекордсменах нет NoSQL систем, то и говорить нечего, «не могут» они. Да, не могут. Потому что вообще не для того, что измеряет TPC, сделаны. И потому их вообще не мучают такими тестами.

Итак, для NoSQL довольно долго был менее популярный синоним NoACID. Но теперь ситуация изменилась, и новые игроки предлагают системы, обещающие, например, характерные для key-value storage NoSQL производительность и масштабируемость в сочетании со строгим соблюдением принципа ACID для всех транзакций. Впоследствии мы уделим внимание двум представителям ACID NoSQL.

Functional NoSQL. Для программиста термин «функциональный» в первую очередь означает «с immutable данными» (значение которых изменить нельзя). И, хоть это кажется удивительным, СУБД, поддерживающие функциональную модель данных (что означает невозможность изменения уже имеющихся в БД записей) существуют. И представляют не только интерес для решения ряда полезных задач, но и обладают собственными уникальными свойствами. Об одном образчике такой СУБД мы поговорим, тем более, что пример будет интересен с архитектурной точки зрения, и как ACID NoSQL СУБД.

За пределами этой условной классификации остаются гибридные СУБД (представляющие собой надстройку традиционной SQL системы над NoSQL хранилищами). Это грамотное инженерное решение никак не сказывается на принципах NoSQL «бэкэндов».

После такого краткого обзора, наверное, нужно что-то сказать о почти обязательных и модных в определённых кругах полярных точках зрения, выражающихся в погромных статьях, непременно начинающихся со слов «Почему я ненавижу ...» (можно подставить название любой SQL или NoSQL СУБД, непременно найдётся не одна сотня страниц в блогах и статей в онлайновых журналах) или «Использование ... считается вредным» (considered harmful). А также о неисчислимых «развенчаниях N+1 мифов» что NoSQL, что SQL, в зависимости от лагеря, откуда исходят развенчания. Об этом непременно нужно что-нибудь сказать, потому что такого вала вдохновенного творчества, какой породили NoSQL СУБД, не наблюдалось давно. Он, безусловно, не даёт скучать и придаёт всей NoSQL-истории характер склочного детектива (скандалы, интриги, расследования), но и, так сказать, загораживает виды.

Давайте ещё раз вспомним, что вся история NoSQL — это, по сути, история практической «программной инженерии», не той, которая требовала рисования UML-диаграмм и следования «лучшим практикам» и шаблонам проектирования, а вполне реалистичной, в которой бюджеты и сроки — не досадные ограничения, а самые что ни на есть жёсткие требования, и дешёвое commodity hardware — не оскорбление, а платформа. Множество NoSQL разработок сделаны со вполне определёнными целями во вполне определённых компаниях, известных своими масштабами. Зачем они «выпущены в мир» что на уровне достаточных для повторения описаний, что вообще на уровне кода — вопрос десятый и особенно не интересен. Большинство систем весьма нетривиальны даже на уровне ключевых идей (где ещё придётся изучать, например, векторные часы, vector clock, со всеми тонкими нюансами их использования?) и требуют очень хорошего понимания их назначения и применимости, а также всех деталей, например, грамотного проектирования «бессхемных» баз данных (для которого ещё и нет какой-то определённой школы). При этом доступность и подкупающая простота развёртывания программных реализаций многих NoSQL СУБД позволяют буквально за минуты и без усилий получить работающую инсталляцию. Добавим к этому очевидный факт — очень многие разработки были выброшены на рынок в традиционном «не совсем готовом» состоянии (времена такие — 80% функциональности уже достаточно, но на оставшиеся 20% всё равно по классике инженерии требуется 80% усилий). Всё это, в сочетании с некачественной NoSQL журналистской «поддержкой» порождает иллюзию простоты и «рреволюции». Которых и в помине, конечно, нет. Потом оказывается, что всевозможные на уровне озарения откровения (вроде «key-value storage — это же обычная реляционная СУБД с одной таблицей из двух столбцов, один для ключа, второй — для данных») разлетаются в щепки, что быстродействие созданной для построения больших распределённых систем СУБД при исполнении на ноутбуке как-то вот не соответствует ожиданиям, что надо тщательнейшим образом изучать нюансы атомарности и изоляции операций, иначе всё работает не так, что schemaless вовсе не означает «как хочу, так и пою», и т.д., и т.п. Ну и самое главное, — надо не только прекрасно знать специфику задачи, для которой планируется использовать NoSQL СУБД, но и понимать, какая именно из существующего множества классов и реализаций именно в этом случае рациональна.

Чтобы поставить точку в этой части статьи, осталось сказать главное. Если вы видите что-то, в заголовке которого есть броское «NoSQL революция», не тратьте на это что-то время. Никакой революции не произошло. Большинство идей в мире NoSQL прекрасно известны, многие унаследованы от разработок дремучей старины, но модифицированы с учётом возможностей современных дешёвых аппаратных средств и сетей. И это очень хорошо, что никаких революций. Наоборот, в истории с NoSQL мы наблюдаем здоровую техническую эволюцию, которая никогда не предполагала существования единственно пригодных «для всего» сверхрешений или «серебряных пуль». Так что обилие NoSQL-систем — это всего лишь следствие обилия задач со специфическими требованиями и ограничениями реальности.

+1717
голосов

Напечатать Отправить другу

Читайте также

Можно посылать в журнал, что бы читали студенты :)

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

Испугаю - будет ещё больше, это начало четырёх статей, пришлось разбить на куски :)

А если будет еще, можно как-то разбавить реальными примерами систем и их реализаций? А так, интересно, но совсем уж абстрактно (IMHO).

Почитайте про Redis - популярное нынче хранилице Key-Value, атомарное и очень быстрое (и при определенных усилиях, доводимое до состояния ACID с поддержкой SQL, но оно на это не рассчитывалось).
Пример реализации: RhoConnect - фреймворк синхронизации данных - использует Redis для промежуточной синхронизации данных мобильных клиентов с "облаком" (из которого всё уже уезжает в нужные корпоративные хранилища). За счет использования Key-Value получается быстро и экономно (что важно для мобильного устройства, т.к. количество переданных данных - это не только деньги, но и батарейка). Для программиста всё сводится к написанию интерфейса к корпоративному бек-енду, и паре строчек кода в клиенском приложении.
Это вкратце, ессно, есть куча нюансов - но есть и куча видео на YouTube и туториалов.

Весело было читать. Не прошло и 20 лет, как сбылись мои предсказания об ущербности реляционных моделей.

Кстати, зря забыли очень хорошую dbVista, потом Raima Data Manager. Моя биллинговая система, спроектированная и написанная более 20 лет назад, целиком использовала смешанную сетевую+иерархическую модель данных этой СУБД. В итоге, выборки нужных данных практически не зависли от объема данных, а потребление ресурсов было настолько мизерное, что до 20 удаленных пользователей при более 100 тыс абонентов, спокойно обслуживались обычным Sparc Station. А еще ранее, моим товарищем, был прикручен Лисп как язык запросов к ней же. На ту смешанную сетевую+иерархическую модель Лисп ложился просто идеально.

Эххх... молодость :)

Андрей, спасибо, очень хорошая статья. Жду продолжения, ибо сам до сих пор являюсь аполегетом NoSQL.

не пройшло й 20 років, як прийшов час для того, для чого 20 років тому не було застосування, і ніяка ущербність тут ні до чого

Было, еще и как было. И кто понимал - использовал или писал себе сам. Но против Оракла не попрешь :)

Хороший обзор. "А. Зубинский" это бренд: и эрудировано, и без ляпов, и оригинально(а не пересказ доки), с юмором и показом фона (а то технари думают о себе что они ж не блондинки, и вау эффектам не подвержены).
Жду с нетерпением остальных частей. Будет кого цитировать :)

чудово, дякую, чекаємо продовження

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT