NoSQL (первоначально ссылаясь на «не- SQL » или «нереляционный») [1] — это подход к проектированию баз данных , который фокусируется на предоставлении механизма для хранения и извлечения данных, которые моделируются средствами, отличными от табличных отношений, используемых в реляционных базах данных . Вместо типичной табличной структуры реляционной базы данных, базы данных NoSQL размещают данные в одной структуре данных. Поскольку эта нереляционная конструкция базы данных не требует схемы , она предлагает быструю масштабируемость для управления большими и обычно неструктурированными наборами данных. [2] Системы NoSQL также иногда называют «Не только SQL», чтобы подчеркнуть, что они могут поддерживать SQL -подобные языки запросов или располагаться рядом с базами данных SQL в многоязычных постоянных архитектурах. [3] [4]
Нереляционные базы данных существуют с конца 1960-х годов, но название «NoSQL» появилось только в начале 2000-х годов [5] , что было вызвано потребностями компаний Web 2.0 . [6] [7] Базы данных NoSQL все чаще используются в больших данных и веб-приложениях реального времени . [8]
Мотивы такого подхода включают простоту дизайна , более простое «горизонтальное» масштабирование до кластеров машин (что является проблемой для реляционных баз данных), [5] более тонкий контроль над доступностью и ограничение несоответствия объектно-реляционного импеданса . [9] Структуры данных , используемые базами данных NoSQL (например, пара ключ-значение , широкий столбец , граф или документ ), отличаются от тех, которые используются по умолчанию в реляционных базах данных, что ускоряет некоторые операции в NoSQL. Конкретная пригодность данной базы данных NoSQL зависит от проблемы, которую она должна решать. Иногда структуры данных, используемые базами данных NoSQL, также рассматриваются как «более гибкие», чем таблицы реляционных баз данных . [10]
Многие хранилища NoSQL идут на компромисс в вопросе согласованности (в смысле теоремы CAP ) в пользу доступности, толерантности к разделам и скорости. Препятствиями к более широкому внедрению хранилищ NoSQL являются использование языков запросов низкого уровня (вместо SQL, например), отсутствие возможности выполнять ad hoc соединения между таблицами, отсутствие стандартизированных интерфейсов и огромные предыдущие инвестиции в существующие реляционные базы данных. [11] Большинство хранилищ NoSQL не имеют настоящих транзакций ACID , хотя несколько баз данных, таких как MongoDB, сделали их центральными в своих проектах. [12]
Вместо этого большинство баз данных NoSQL предлагают концепцию « окончательной согласованности », в которой изменения базы данных распространяются на все узлы «в конечном итоге» (обычно в течение миллисекунд), поэтому запросы данных могут не возвращать обновленные данные немедленно или могут приводить к чтению неточных данных, проблема, известная как устаревшее чтение. [13] Кроме того, некоторые системы NoSQL могут демонстрировать потерянные записи и другие формы потери данных . [14] Некоторые системы NoSQL предоставляют такие концепции, как опережающее ведение журнала , чтобы избежать потери данных. [15] Для распределенной обработки транзакций в нескольких базах данных согласованность данных является еще большей проблемой, которая сложна как для NoSQL, так и для реляционных баз данных. Реляционные базы данных «не позволяют ограничениям ссылочной целостности охватывать базы данных». [16] Немногие системы поддерживают как транзакции ACID , так и стандарты X/Open XA для распределенной обработки транзакций . [17] Интерактивные реляционные базы данных разделяют методы конформационного релейного анализа в качестве общей черты. [18] Ограничения в среде интерфейса преодолеваются с помощью протоколов семантической виртуализации, благодаря чему службы NoSQL доступны большинству операционных систем . [19]
Термин NoSQL был использован Карло Строцци в 1998 году для названия его облегченной реляционной базы данных Strozzi NoSQL с открытым исходным кодом , которая не предоставляла стандартный интерфейс языка структурированных запросов (SQL), но все еще была реляционной. [20] Его СУРБД NoSQL отличается от общей концепции баз данных NoSQL, появившейся около 2009 года. Строцци предполагает, что, поскольку текущее движение NoSQL «полностью отходит от реляционной модели, его следовало бы более уместно назвать „NoREL“», [21] имея в виду «нереляционный».
Йохан Оскарссон, тогдашний разработчик Last.fm , вновь ввел термин NoSQL в начале 2009 года, когда он организовал мероприятие для обсуждения « распределенных нереляционных баз данных с открытым исходным кодом ». [22] Название было попыткой обозначить появление все большего числа нереляционных распределенных хранилищ данных, включая клоны с открытым исходным кодом Bigtable / MapReduce от Google и DynamoDB от Amazon .
Существуют различные способы классификации баз данных NoSQL с различными категориями и подкатегориями, некоторые из которых пересекаются. Ниже приведена неисчерпывающая классификация по модели данных с примерами: [23]
Хранилища типа «ключ-значение» (KV) используют ассоциативный массив (также называемый картой или словарем) в качестве своей фундаментальной модели данных. В этой модели данные представлены как коллекция пар «ключ-значение», так что каждый возможный ключ появляется в коллекции не более одного раза. [26] [27]
Модель ключ-значение является одной из самых простых нетривиальных моделей данных, и более богатые модели данных часто реализуются как ее расширение. Модель ключ-значение может быть расширена до дискретно упорядоченной модели, которая поддерживает ключи в лексикографическом порядке . Это расширение является вычислительно мощным, поскольку оно может эффективно извлекать выборочные диапазоны ключей . [28]
Хранилища ключей и значений могут использовать модели согласованности , варьирующиеся от окончательной согласованности до сериализуемости . Некоторые базы данных поддерживают упорядочивание ключей. Существуют различные аппаратные реализации, и некоторые пользователи хранят данные в памяти (RAM), а другие — на твердотельных накопителях (SSD) или вращающихся дисках (также известных как жесткие диски (HDD)).
Центральным понятием хранилища документов является понятие «документ». Хотя детали этого определения различаются в разных документно-ориентированных базах данных, все они предполагают, что документы инкапсулируют и кодируют данные (или информацию) в некоторых стандартных форматах или кодировках. Используемые кодировки включают XML , YAML и JSON , а также двоичные формы, такие как BSON . Документы адресуются в базе данных с помощью уникального ключа , который представляет этот документ. Другой определяющей характеристикой документно-ориентированной базы данных является API или язык запросов для извлечения документов на основе их содержимого.
Различные реализации предлагают разные способы организации и/или группировки документов:
По сравнению с реляционными базами данных коллекции можно считать аналогами таблиц, а документы — аналогами записей. Но они отличаются — каждая запись в таблице имеет одинаковую последовательность полей, тогда как документы в коллекции могут иметь совершенно разные поля.
Графовые базы данных предназначены для данных, отношения которых хорошо представлены в виде графа , состоящего из элементов, связанных конечным числом отношений. Примерами данных являются социальные отношения , маршруты общественного транспорта, дорожные карты, топологии сетей и т. д.
Производительность баз данных NoSQL обычно оценивается с использованием метрики пропускной способности , которая измеряется как количество операций в секунду. Оценка производительности должна уделять внимание правильным контрольным показателям, таким как конфигурации производства, параметры баз данных, ожидаемый объем данных и одновременные рабочие нагрузки пользователей .
Бен Скофилд оценил различные категории баз данных NoSQL следующим образом: [30]
Сравнение производительности и масштабируемости чаще всего проводится с использованием теста YCSB .
Поскольку большинство баз данных NoSQL не поддерживают объединения в запросах, схему базы данных обычно необходимо проектировать по-другому. Существует три основных метода обработки реляционных данных в базе данных NoSQL. (См. таблицу Поддержка объединения и ACID для баз данных NoSQL, поддерживающих объединения.)
Вместо того, чтобы извлекать все данные одним запросом, обычно делают несколько запросов, чтобы получить нужные данные. Запросы NoSQL часто быстрее традиционных запросов SQL, поэтому стоимость дополнительных запросов может быть приемлемой. Если необходимо чрезмерное количество запросов, один из двух других подходов будет более подходящим.
Вместо того, чтобы хранить только внешние ключи, обычно хранят фактические внешние значения вместе с данными модели. Например, каждый комментарий в блоге может включать имя пользователя в дополнение к идентификатору пользователя, тем самым обеспечивая легкий доступ к имени пользователя без необходимости повторного поиска. Однако, когда имя пользователя меняется, его теперь нужно будет изменить во многих местах в базе данных. Таким образом, этот подход работает лучше, когда чтение происходит гораздо чаще, чем запись. [31]
В базах данных документов, таких как MongoDB, принято размещать больше данных в меньшем количестве коллекций. Например, в приложении для ведения блога можно выбрать хранение комментариев в документе записи блога, чтобы при одном извлечении получить все комментарии. Таким образом, при таком подходе один документ содержит все данные, необходимые для определенной задачи.
База данных помечается как поддерживающая свойства ACID (атомарность, согласованность, изоляция, долговечность) или операции соединения , если в документации к базе данных указано это. Однако это не обязательно означает, что эта возможность полностью поддерживается способом, аналогичным большинству баз данных SQL.
База данных NoSQL, также называемая Not Only SQL
Многие сторонники NoSQL говорят, что это не означает «нет» SQL, а скорее означает «не только SQL».
Карло Строцци впервые использовал термин NoSQL в 1998 году в качестве названия для своей реляционной базы данных с открытым исходным кодом, которая не предлагала интерфейс SQL[...]
–value stores позволяют разработчику приложения хранить данные без схемы. Эти данные обычно состоят из строки, представляющей ключ, и фактических данных, которые считаются значением в отношении "ключ–значение". Сами данные обычно представляют собой некий примитив языка программирования (строку, целое число или массив) или объект, который маршалируется привязками языка программирования к key-value store. Эта структура заменяет необходимость в фиксированной модели данных и обеспечивает правильное форматирование.
ключей и значений предоставляют высокопроизводительную альтернативу системам реляционных баз данных в отношении хранения и доступа к данным. В этой статье представлен краткий обзор некоторых из доступных в настоящее время хранилищ ключей и значений и их интерфейс к языку программирования Ruby.