NoSQL

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:43, 24 марта 2018.

NoSQL (англ. not only SQL, не только SQL), в информатике — термин, обозначающий ряд подходов, направленных на реализацию хранилищ баз данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL. Применяется к базам данных, в которых делается попытка решить проблемы масштабируемости (англ. scalability) и доступности (англ. availability) за счёт атомарности (англ. atomicity) и согласованности данных (англ. consistency). Под термином NoSQL скрывается большое количество продуктов с абсолютно разными дизайнами и, иногда, при обсуждении разговор может идти о разных системах. [Источник 1]

История

Этот термин стал использоваться в конце 90-х, но реальный смысл в том виде, как он используется сейчас, приобрел только в середине 2009 года. Изначально так называлась опенсорсная база данных, созданная Карло Строззи, которая хранила все данные как ASCII файлы и использовала шелловские скрипты вместо SQL для доступа к данным. Термин “NoSQL” имеет абсолютно стихийное происхождение и не имеет общепризнанного определения или научного учреждения за спиной. Это название скорее характеризует вектор развития ИТ в сторону от реляционных баз данных. Расшифровывается как Not Only SQL, хотя есть сторонники и прямого определения No SQL.

Причины появления

  1. Первый тренд — увеличение объемов хранимых данных. Сегодня хранилища достигли таких невероятных размеров, что даже трудно себе представить. Только за 2009 и 2010 годы в базах было сохранено больше информации, чем за всю предыдущую историю человечества.
  2. Второй тренд — взаимосвязанность данных. Информация перестала быть изолированной. Каждый кусочек знаний как-то связан с данными в других хранилищах информации. Страницы в интернете ссылаются на другие страницы. Тэги связывают помеченную информацию из разных источников. Онтологии устанавливают взаимосвязи между различными терминами, и тд
  3. Третий тренд — использование слабоструктурированной информации. Возьмем простой пример: описание товара в магазине. Если раньше было достаточно 5-6 полей, чтобы описать мужскую сорочку (размер, цвет, материал, фотография товара, …), то теперь количество параметров может доходить до нескольких десятков. Причем, для разных сорочек будет использован разный набор параметров. В таких условиях становится крайне сложно заранее определить структуру таблицы, в которой хранится описание товара.
  4. Четвертый тренд — архитектура. В 80-х годах прошлого века типичная архитектура использовала один большой компьютер (mainframe) и одну базу данных. В 90-х, распространение получила клинт-серверная архитектура. В новом веке активно используются web-сервисы, каждый со своим backend-ом (грубо говоря, со своей базой данных) и другие распределенные решения.

В таких условиях у реляционных баз данных резко падает производительность. И если для большинства web-сайтов производительности еще хватает, то для таких приложений как современные социальные сети или поисковые сервисы, SQL базы данных оказались несостоятельны.

Основные черты

Традиционные реляционные СУБД основаны на принципах ACID:

  1. Atomicity - атомарность
  2. Consistency - согласованность
  3. Isolation - изолированность
  4. Durability - надежность

NoSQL основаны на принципах BASE, данный термин был предложен Эриком Брюером:

  1. Basic Availability - базовая доступность — каждый запрос гарантированно завершается (успешно или безуспешно).
  2. Soft State - гибкое состояние — состояние системы может изменяться со временем, даже без ввода новых данных, для достижения согласования данных.
  3. Eventual Consistency - согласованность в конечном счёте — данные могут быть некоторое время рассогласованы, но приходят к согласованию через некоторое время.

Cпособы доступа к данным

  1. RESTful интерфейсы. В рамках данного подхода предполагается, что каждый объект, которым мы можем манипулировать, имеет свой уникальный адрес. Обращаясь по этому адресу, мы можем запрашивать, создавать, редактировать или удалять указанный объект. При этом на сервере не сохраняется никакого состояния, то есть каждый запрос обрабатывается независимо от других запросов.
  2. Отличные от SQL языки запросов: GQL (SQL-подобный язык для Google BigTable), SPARQL (язык запросов Семантического Веба), Gremlin (язык обхода графов), Sones Graph Query Language (язык запросов к Sones Graph)
  3. API запросов: Google BigTable DataStore API, Neo4j Traversal API


Основные типы данных

Хранилище "ключ-значение"

В своей основе оно использует ассоциативные массивы, данные представлены как набор пар ключ-значение. Является наиболее простой моделью, ключи могут сортироваться в лексикографическом порядке, что еще больше повышает производительность. Такие хранилища используются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в системах, спроектированных с прицелом на масштабируемость.
Примеры - Oracle NoSQL Database, Redis, Amazon DynamoDB.

Документо-ориентированные базы данных

Эти СУБД служат для хранения иерархических структур данных. Основной идеей является введение понятия "документ". Хотя все базы данных имеют чем-то отличающиеся определения, все они полагают, что документ хранит и инкапсулирует данные в каких-либо стандартных форматах, например XML или JSON. Каждому документу присваивается свой уникальный ключ, для каждой базы данных такого типа есть свой язык запросов или API для доступа к данным. Обычно в базах данных такого типа присутствует богатая структура документа.
Примеры - CouchDB, Couchbase Server, MarkLogic, MongoDB.

Графовые базы данных

Такая база данных предназначена для данных, отношения которых хорошо представлены как граф, состоящий из элементов, связанных с конечным числом отношений между ними. Типом данных могут быть социальные сети, общественные транспортные связи, дорожные карты или сетевые топологии.
Примеры - AllegroGraph, ArangoDB, Neo4j.

Колоночные базы данных

Сильной стороной колоночных баз данных является способность хранить большое количество данных с большим количеством атрибутов. В отличие от РБД, которые хранят данные по строкам, колоночные БД хранят данные в колонках. Колонки хранятся в отдельных файлах. Это способствует улучшенному сжатию за счет информации о типе данных колонки. Также это ускоряет запросы.
Примеры - Apache HBase, Apache Cassandra, Apache Accumulo.[Источник 2]

Методы хранения данных

Есть базы данных, которые вообще никак данные не хранят, у них все содержится в памяти. Соответственно, любая перезагрузка процесса влечет за собой потерю данных. Другие базы данных используют такие методы как snapshot, запись данных в лог и in-place updates.

  • Snapshot – слепок базы данных на текущий момент. Минусом этого способа является необходимость наличия дополнительной памяти. В зависимости от активности, которая происходит на сервере, может понадобиться до двукратного запаса памяти.
  • Запись данных в лог – когда базе данных приходит команда на запись, происходит запись в лог и продолжается работа. Данные, которые попали в лог, не подлежат изменению.
  • In-place updates – база данных имеет свою копию, которая обновляется при каких-либо изменениях в базе данных. Такая модель не безопасна, так как при возможном отключении питания во время обновления копии данные потеряются.

CAP теорема

Распределенная система не может одновременно обладать более чем двумя из следующих трех характеристик — это доступность (availability), согласованность (consistency) и устойчивость к разрывам сети (partition tolerance).

  • Согласованность – каждое «чтение» получает самую последнюю запись или ошибку.
  • Доступность – каждый запрос получает ответ (без ошибок) - без гарантии, что он содержит самую последнюю запись.
  • Устойчивость к разрывам сети – Система продолжает работать, несмотря на произвольное количество сброшенных сообщений (или задержанных) сетью между узлами.

На самом деле, выбор только из двух вариантов — либо доступность, либо согласованность, потому что устойчивость к разрывам сети везде есть по умолчанию. Если система называет себя CP (т.е. consistency и partition tolerance), то при разрыве, если мы обращаемся на узел, и узел видит, что он не может надежно обеспечить эту запись, что у него нет, то он просто откажет приложению в этой записи, и она не удастся. Если система называет себя AP, то она будет всеми силами стараться удовлетворить запросы приложения путем отдачи ему устаревших данных. Она может принять себе запрос на запись и куда-то ее себе записать, чтобы потом выполнить на всем кластере. В AP системах есть термин Eventual consistency (Возможная согласованность) - если не было конфликтующих записей, то когда-нибудь позже кластер придет в согласованное состояние. Конфликты можно разрешить по времени, использовать счетчики, использовать тип данных «множество».[Источник 3]

Достоинства NoSql баз данных

  • Высокая масштабируемость
  • Прототипирование
  • Высокая доступность
  • Кэширование
  • Буферизация
  • Очередь заданий
  • Счетчики
  • Полнотекстовый поиск
  • Репликация
  • Шаринг

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

  • Небольшой функционал
  • Недостаточная гибкость
  • Немалое потребление ресурсов
  • Не всегда хорошо работают «из коробки»
  • Необходимость специализированных знаний для работы с базой данных


Ссылки

  1. Wikipedia - NoSQL


Источники

  1. NoSQL// Wiki. [2017 - 2017]. Дата обновления: 20.09.17. URL: https://ru.wikipedia.org/wiki/NoSQL (дата обращения: 28.11.2017).
  2. Обзор NoSQL систем// Habrahabr. [2009 - 2017]. Дата обновления: 11.12.09. URL: https://habrahabr.ru/post/77909// (дата обращения: 28.11.2017).
  3. NoSQL базы данных// Habrahabr. [2012 - 2017]. Дата обновления: 27.09.12. URL: https://habrahabr.ru/post/152477// (дата обращения: 28.11.2017).