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

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


Оглавление статьи[Показать]


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

 

Движение NOSQL

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

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

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

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

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

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

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

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

 

ACID или BASE

Первое знакомство с базами данных NOSQL часто происходит в хо­рошо знакомом контексте реляционных баз данных. Понятно, что данные и модели запросов будут другими (в конце концов, отсутству­ет поддержка SQL), но модели согласования данных, используемые NOSQL-хранилищами, также весьма отличаются от тех, что исполь­зуются реляционными базами данных. Разные 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 на четыре сектора. Хранилища в каждом секторе предназначены для разных ти­пов функционального применения, хотя и нефункциональные требо­вания также могут сильно повлиять на выбор базы данных.

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

Секторы NOSQL-хранилищ

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

 

Вас заинтересует / Intresting for you:

Что такое база данных  и СУБД?
Что такое база данных и СУБД? 9051 просмотров Светлана Mon, 21 Oct 2019, 17:58:45
База данных как объект правово...
База данных как объект правово... 1567 просмотров Денис Wed, 27 Mar 2019, 03:16:24
Перенос корпоративных баз данн...
Перенос корпоративных баз данн... 2774 просмотров Дэн Fri, 27 Sep 2019, 07:52:18
База данных и СУБД: основные п...
База данных и СУБД: основные п... 15820 просмотров Дэйзи ак-Макарова Fri, 24 Nov 2017, 05:30:03
Войдите чтобы комментировать

Oracle_Admin аватар
Oracle_Admin ответил в теме #9851 3 года 1 мес. назад
Хороший обзор NoSQL баз данных. Благодарствуем, как говориться!)