NoSQL – коротко о главном

Что такое NoSQL

Когда мы раз­би­ра­ли виды баз дан­ных, то ска­за­ли, что они быва­ют реля­ци­он­ные и все осталь­ные. Реля­ци­он­ные — самые рас­про­стра­нён­ные, вы встре­ти­те их под капо­том боль­шин­ства сай­тов, чаще все­го они управ­ля­ют­ся через систе­му MySQL.

Но одно реше­ние не может под­хо­дить всем и все­гда. Сего­дня пого­во­рим обо всех осталь­ных вари­ан­тах, кото­рые собра­ны под еди­ным боль­шим тер­ми­ном NoSQL — это общее назва­ние для нере­ля­ци­он­ных баз дан­ных.

Способ организации данных

В SQL-базах всё про­сто: есть, услов­но гово­ря, таб­ли­цы, и есть свя­зи меж­ду ними. Все дан­ные хра­нят­ся в этих таб­ли­цах.

В NoSQL-базах всё ина­че — там может не быть таб­лиц, а вме­сто них — свои моде­ли дан­ных. Каж­дая из них под­хо­дит под свои зада­чи, уни­вер­саль­ной нет. Вот основ­ные моде­ли:

Ключ-значение

У каж­дой запи­си есть назва­ние поля и его зна­че­ние. Напри­мер:

name: ‘Миша’
today: ‘9/09/2020’
president: ‘Путин’
writer: ‘Пуш­кин’
pogoda: ‘ну такая’

Пер­вая часть — это ключ, вто­рая часть — зна­че­ние. И мож­но под­сы­пать сколь­ко хочешь новых клю­чей.

Это полез­но, напри­мер, для сло­ва­рей или меха­низ­мов авто­за­ме­ны: «Если встре­ти­лось такое сло­во — заме­ни на вот такое».

Колонки

Пред­ставь­те себе одну огром­ную таб­ли­цу, в кото­рой хра­нят­ся все дан­ные в базе. Отли­чие от тра­ди­ци­он­ной схе­мы в том, что в SQL-базах рабо­та идёт со стро­ка­ми, а здесь — с колон­ка­ми. Напри­мер, если в такую базу зане­сти спи­сок из 250 луч­ших филь­мов с назва­ни­я­ми, актё­ра­ми и режис­сё­ра­ми, то все назва­ния мож­но полу­чить с помо­щью толь­ко одно­го запро­са и одно­го обра­ще­ния к базе. В слу­чае с SQL таких обра­ще­ний к базе было бы 250 — по одно­му на каж­дую стро­ку.

Графы

Если ваши дан­ные мож­но пред­ста­вить в виде гра­фа или дере­ва, то вам подой­дёт и база дан­ных с таким же под­хо­дом к хра­не­нию и поис­ку.

Дере­во — это когда дан­ные хра­нят­ся по систе­ме «роди­тель — отпрыс­ки». Есть некий роди­тель­ский кусок дан­ных, у него есть свя­зан­ные с ним отпрыс­ки. У тех тоже могут быть свои отпрыс­ки и так далее. Каж­дая еди­ни­ца дан­ных может быть чьим-то отпрыс­ком (но толь­ко кого-то одно­го) и иметь сколько-то соб­ствен­ных отпрыс­ков.

В дере­вьях удоб­но хра­нить дан­ные, напри­мер, для поис­ко­вых алго­рит­мов. В «дере­вьях» так­же хра­нят­ся фай­лы на вашем ком­пью­те­ре: есть кор­не­вой ката­лог, в нём вло­жен­ные пап­ки, в них ещё пап­ки, в них фай­лы. Один и тот же файл не может хра­нить­ся одно­вре­мен­но в двух местах.

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

Документы

Вот это кос­мос, смот­ри­те.

Если мы хра­ним дан­ные в таб­ли­це, у нас есть столб­цы и стро­ки. И если у нас про кого-то есть дан­ные, а про дру­го­го нет, — где-то в таб­ли­це будут про­пус­ки. А если в таб­ли­це нет нуж­но­го столб­ца, а нам нуж­но поло­жить в неё новый тип дан­ных, нам при­дёт­ся созда­вать новый стол­бец, и он для всех будет пустым:

Обзор NOSQL баз данных

В последние годы наблюдается стремительный взлет популярно­сти семейства технологий хранения данных, известных как NOSQL (дерзкий акроним от Not Only SQL (Не только SQL), или акроним от еще более категоричного No to SQL (Нет SQL)). Но сам по себе термин NOSQL означает лишь, что такие хранилища данных не явля­ются SQL-ориентированными реляционными базами данных, а ин­тересным и полезным набором разнообразных технологий хранения, имеющих множество эксплуатационных, функциональных и архи­тектурных характеристик.

Что послужило причиной создания этих новых баз данных? Какие задачи они призваны решить? Здесь будут рассмотрены некоторые из проблем обработки данных, которые возникли в течение последне­го десятилетия. Далее будут описаны четыре семейства NOSQL-баз данных, в том числе графовые.

Движение NOSQL

Исторически сложилось так, что большинство веб-приложений кор­поративного уровня использует реляционные базы данных. Но в по­следнее десятилетие мы столкнулись с настолько большими объ­емами данных, которые так быстро меняются и так разнообразны по своей структуре, что с ними невозможно работать, используя тради­ционные реляционные СУБД. Движение NOSQL создано для реше­ния этой проблемы.

Неудивительно, что количество хранимых данных резко возросло, и их объем стал основной движущей силой использования NOSQL- хранилищ. Объем можно определить просто как размер наборов хра­нимых данных.

Как известно, большие наборы данных очень сложно хранить в ре­ляционных базах данных. В частности, время выполнения запросов увеличивается вместе с увеличением размеров таблиц и ростом числа соединений (так называемая болезнь соединений). И это не вина самих баз данных. Это один из аспектов, лежащий в основе модели данных, заключающийся в извлечении множества возможных результатов за­проса с последующей их фильтрацией для получения лишь необхо­димых.

Чтобы избежать соединений и сопутствующих им болезней и тем са­мым улучшить обработку очень больших наборов данных, в NOSQL-мире предложено несколько альтернатив реляционной модели. Хотя они лучше справляются с обработкой очень больших наборов дан­ных, эти альтернативные модели, как правило, менее наглядны, чем реляционная (за исключением графовой модели, которая является даже более наглядной).

Но объем – это не единственная проблема, с которой сталкива­ются современные веб-системы. Помимо своего большого объема, со­временные данные обычно очень быстро изменяются. Скорость – это темп изменения данных с течением времени.

Скорость редко остается статичной. Внутренние и внешние изме­нения системы и контекста ее использования могут оказать значи­тельное воздействие на скорость. В сочетании с большим объемом данных переменная скорость требует от хранилища не только справ­ляться с устойчиво высоким уровнем объемов записи, но и оставаться работоспособным при пиковых нагрузках.

Существует еще один аспект скорости – скорость изменения струк­туры данных. Другими словами, вдобавок к изменению значений определенных свойств может меняться общая структура элементов, определяющих эти свойства. Это обычно происходит по двум при­чинам. Первой является динамизм прикладной области. При изме­нениях в прикладной области меняются и потребности в данных. Во- вторых, сбор данных часто является экспериментальным процессом. Некоторые свойства создаются «на всякий случай», другие добав­ляются позднее в связи с изменением требований. Те, что оказались нужными, остаются, прочие выбрасываются. Оба этих аспекта в реля­ционном мире вызывают проблемы, поскольку большой объем запи­си привносит высокие расходы обработки, а высокая изменчивость схем сопровождается высокими эксплуатационными затратами.

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

ACID или BASE

Первое знакомство с базами данных NOSQL часто происходит в хо­рошо знакомом контексте реляционных баз данных. Понятно, что данные и модели запросов будут другими (в конце концов, отсутству­ет поддержка SQL), но модели согласования данных, используемые NOSQL-хранилищами, также весьма отличаются от тех, что исполь­зуются реляционными базами данных. Разные NOSQL-базы данных используют разные модели согласования для поддержки разных объемов, скоростей изменения и разнообразия данных, упомянутых выше.

Давайте рассмотрим, какие функции согласованности помогают обеспечить безопасность хранимых данных и какие компромиссы до­пускаются при использовании (большинства)

В мире реляционных баз данных общеизвестны ACID-транзакции, некоторое время являвшиеся эталоном. Гарантии ACID обеспечива­ют безопасную среду для обработки данных:

• атомарность (Atomic) – все операции в транзакции либо успеш­ны, либо для всех них выполняется откат;
• согласованность (Consistent) – по окончании транзакции база данных является структурно согласованной;
• изолированность (Isolated) – транзакции не мешают друг другу. Спорные ситуации разрешаются базой данных так, что транзакции выполняются последовательно;
• долговечность (Durable) – результаты применения транзакции не должны теряться, даже при сбоях.

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

Для многих прикладных областей ACID-транзакции являются из­лишне пессимистичными. В мире NOSQL ACID-транзакции вышли из моды, поскольку хранилища смягчили требования к немедленной согласованности, актуальности данных и их точности, чтобы полу­чить другие преимущества, такие как масштабируемость и гибкость. Вместо ACID возник другой популярный подход BASE, описываю­щий принципы более оптимистичной стратегии хранения:

• обычно доступно (Basicavailability) – хранилище доступно большую часть времени;
• гибкое состояние (Soft-state) – хранилища не обязаны соблю­дать очередность записей, и разные реплики не должны посто­янно согласовываться;
• отложенная согласованность (Eventualconsistency) – храни­лища достигают согласованности с некоторой задержкой по времени (например, позже, во время чтения).

Принципы BASE значительно слабее гарантий ACID, и между ними нет прямого соответствия. Значения в BASE-хранилище до­ступны (потому что это является основой масштабирования), но это не предлагает гарантированной согласованности реплик при запи­си. BASE-хранилища обеспечивают менее строгий контроль: данные будут согласованы позднее, вероятнее всего, во время чтения (как, например, в Riak), или всегда будут согласованы, но только для определенных фиксаций, обработанных последними (как, например, в Datomic).

Разработчики должны учитывать такую свободную поддержку со­гласованности и уделять больше внимания согласованности данных. Им следует познакомиться с методами BASE конкретного храни­лища и научиться работать в рамках его ограничений. На практике в каждом конкретном случае делается выбор, приемлема ли возмож­ная противоречивость данных или же нужно потребовать от базы данных обеспечить непротиворечивость при чтении, согласившись с возникающими при этом задержками. (Чтобы гарантировать не­противоречивое чтение, базе данных необходимо сравнить все реп­лики элемента данных и в случае их несогласованности выполнить корректирующую обработку.) При разработке это добавляет сложно­стей, по сравнению с применением транзакций, которые берут на себя обязанности по достижению согласованности, но это не является не­разрешимой проблемой, просто это требует дополнительных усилий.

Классификация и секторы NOSQL

Познакомившись с базовой моделью согласованности данных в NOSQL-хранилищах, можно перейти к рассмотрению использова­ния многочисленных моделей данных. Для большей определенности нами разработана простая классификация, изображенная на рис. 1. Эта классификация делит современную область NOSQL на четыре сектора. Хранилища в каждом секторе предназначены для разных ти­пов функционального применения, хотя и нефункциональные требо­вания также могут сильно повлиять на выбор базы данных.

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

Рис. 1 Секторы NOSQL-хранилищ

Эволюция NoSQL, основные преимущества перед SQL

Нет сомнений в том, что методы работы веб-приложений с данными существенно изменились за последнее десятилетие. Собирается и используется всё больше данных, и всё больше пользователей одновременно получают доступ к этим данным. Это означает, что масштабируемость и производительность являются более сложной задачей, чем для реляционных баз данных, основанных на схеме, чьё масштабирование сложнее.

Проблема масштабируемости SQL была признана интернет-компаниями с огромными растущими потребностями в данных и инфраструктуре, такими как Google, Amazon и Facebook. Они придумали свои собственные решения проблемы – такие технологии, как BigTable, DynamoDB и Cassandra.

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

Во-первых, существовали запатентованные (с закрытым исходным кодом) типы баз данных NoSQL, разработанные крупными компаниями для удовлетворения их конкретных потребностей, такие как Bigtable от Google, которая считается первой системой NoSQL, и DynamoDB от Amazon.

Успех этих проприетарных систем положил начало разработке ряда аналогичных систем баз данных с открытым исходным кодом и проприетарных систем, наиболее популярными из которых являются Hypertable, Cassandra, MongoDB, DynamoDB, HBase и Redis.

Что отличает NoSQL?

Одним из ключевых различий между базами данных NoSQL и традиционными реляционными базами данных является тот факт, что NoSQL является формой неструктурированного хранилища.

Это означает, что базы данных NoSQL не имеют фиксированной структуры таблиц, как в реляционных базах данных.

Преимущества NoSQL

Базы данных NoSQL имеют много преимуществ по сравнению с традиционными реляционными базами данных.

Одно из основных отличий заключается в том, что базы данных NoSQL имеют простую и гибкую структуру. Они не используют схем. В отличие от реляционных баз данных, базы данных NoSQL основаны на парах ключ-значение.

Некоторые типы хранилища NoSQL баз данных включают хранение столбцов, документов, значений ключей, графов, объектов, XML объектов и другие способы хранения данных.

Обычно каждое значение в базе данных обозначается ключом. Некоторые хранилища баз данных NoSQL также позволяют разработчикам хранить сериализованные объекты в базе данных, а не только простые строковые значения.

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

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

Недостатки NoSQL баз данных

Конечно, базы данных NoSQL не идеальны, и они не всегда могут использоваться в качестве систем хранения данных.

Во-первых, большинство баз данных NoSQL не заточены на надёжность в той мере, в которой это относится к традиционным базам данных. Такие характеристики как атомарность, консистентность, изоляция и стойкость данных в системах NoSQL принесены в жертву производительности и масштабируемости.

Для поддержки функций надежности и согласованности разработчикам необходимо реализовать собственный проприетарный код, что усложняет работу системы. Это ограничивает использование NoSQL в областях, где важна безопасность и надёжность транзакции, таких как банковские системы.

Так же NoSQL базы данных не совместимы с запросами SQL. Это означает, что необходимо вручную переписывать запросы для работы с этим типом баз данных.

NoSQL против реляционных баз данных

Давайте сравним NoSQL с обычной базой данных: