Что такое NoSQL? Базы данных для облачного будущего

Один из наиболее важных вариантов, который следует сделать при разработке приложения, - использовать ли базу данных SQL или NoSQL для хранения данных. Обычные базы данных SQL (т. Е. Реляционные) являются продуктом десятилетий развития технологий, передовой практики и реальных стресс-тестов. Они разработаны для надежных транзакций и специальных запросов - основных бизнес-приложений. Но они также обременены ограничениями, такими как жесткая схема, которые делают их менее подходящими для других типов приложений.

Базы данных NoSQL возникли в ответ на эти ограничения. Системы NoSQL хранят данные и управляют ими таким образом, чтобы обеспечить высокую скорость работы и большую гибкость со стороны разработчиков. Многие из них были разработаны такими компаниями, как Google, Amazon, Yahoo и Facebook, которые искали лучшие способы хранения контента или обработки данных для крупных веб-сайтов. В отличие от баз данных SQL, многие базы данных NoSQL можно масштабировать по горизонтали на сотни или тысячи серверов.

Однако преимущества NoSQL не бесплатны. Системы NoSQL обычно не обеспечивают такой же уровень согласованности данных, как базы данных SQL. Фактически, в то время как базы данных SQL традиционно жертвуют производительностью и масштабируемостью ради свойств ACID, лежащих в основе надежных транзакций, базы данных NoSQL в значительной степени отказались от этих гарантий ACID для скорости и масштабируемости.

Короче говоря, базы данных SQL и NoSQL предлагают разные компромиссы. Хотя они могут конкурировать в контексте конкретного проекта - например, в том, какое приложение выбрать для этого или этого приложения, - они дополняют друг друга в более широкой картине. Каждый из них подходит для разных вариантов использования. Решение - это не столько вопрос или / или, сколько вопрос о том, какой инструмент подходит для работы.

NoSQL против SQL

Принципиальная разница между SQL и NoSQL не так уж и сложна. У каждого есть своя философия того, как данные должны храниться и извлекаться.

В базах данных SQL все данные имеют внутреннюю структуру. Обычная база данных, такая как Microsoft SQL Server, MySQL или Oracle Database, использует схему - формальное определение того, как будут составляться данные, вставленные в базу данных. Например, данный столбец в таблице может быть ограничен только целыми числами. В результате данные, записанные в столбце, будут иметь высокую степень нормализации. Жесткая схема базы данных SQL также позволяет относительно легко выполнять агрегирование данных, например, посредством JOIN.

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

  1. Базы данных документов (например, CouchDB, MongoDB). Вставленные данные хранятся в форме структур JSON произвольной формы или «документов», где данные могут быть любыми, от целых чисел до строк и текста произвольной формы. Нет необходимости указывать, какие поля будут содержать документ.
  2. Хранилища "ключ-значение" (например, Redis, Riak). Доступ к значениям произвольной формы - от простых целых чисел или строк до сложных документов JSON - осуществляется в базе данных с помощью ключей.
  3. Магазины с широкими колонками (например, HBase, Cassandra). Данные хранятся в столбцах, а не в строках, как в обычной системе SQL. Любое количество столбцов (и, следовательно, множество различных типов данных) может быть сгруппировано или агрегировано по мере необходимости для запросов или представлений данных.
  4. Базы данных графов (например, Neo4j). Данные представлены в виде сети или графа сущностей и их взаимосвязей, причем каждый узел графа представляет собой фрагмент данных произвольной формы.

Хранение данных без схемы полезно в следующих сценариях:

  1. Вам нужен быстрый доступ к данным, и вас больше волнуют скорость и простота доступа, чем надежные транзакции или согласованность.
  2. Вы храните большой объем данных и не хотите блокировать себя схемой, поскольку изменение схемы позже может быть медленным и болезненным.
  3. Вы получаете неструктурированные данные из одного или нескольких источников, которые их производят, и хотите сохранить данные в исходной форме для максимальной гибкости.
  4. Вы хотите хранить данные в иерархической структуре, но хотите, чтобы эти иерархии описывались самими данными, а не внешней схемой. NoSQL позволяет данным быть самодостаточными способами, более сложными для эмуляции баз данных SQL.

Запросы к базам данных NoSQL

Язык структурированных запросов, используемый в традиционных базах данных, обеспечивает единообразный способ связи с сервером при хранении и извлечении данных. Синтаксис SQL очень стандартизирован, поэтому, хотя отдельные базы данных могут обрабатывать определенные операции по-разному (например, оконные функции), основы остаются теми же.

Напротив, каждая база данных NoSQL имеет свой собственный синтаксис для запросов и управления данными. CouchDB, например, использует запросы в форме JSON, отправленные через HTTP, для создания или извлечения документов из своей базы данных. MongoDB отправляет объекты JSON по двоичному протоколу с помощью интерфейса командной строки или языковой библиотеки.

Некоторые продукты NoSQL могут использовать синтаксис, подобный SQL, для работы с данными, но только в ограниченной степени. Например, Apache Cassandra, база данных хранилища столбцов, имеет свой собственный SQL-подобный язык, язык запросов Cassandra или CQL. Некоторые элементы синтаксиса CQL взяты прямо из учебника SQL, например ключевые слова SELECT или INSERT. Но в Cassandra нет способа выполнить JOIN или подзапрос, и, следовательно, соответствующие ключевые слова не существуют в CQL.

Архитектура без общего доступа

Общим для систем NoSQL вариантом дизайна является архитектура «без совместного использования». В схеме без совместного использования ресурсов каждый серверный узел в кластере работает независимо от всех остальных узлов. Система не должна получать консенсус от каждого отдельного узла, чтобы вернуть часть данных клиенту. Запросы выполняются быстро, потому что их можно вернуть с любого ближайшего или наиболее удобного узла.

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

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

Ограничения NoSQL

Если NoSQL предоставляет столько свободы и гибкости, почему бы не отказаться от SQL полностью? Простой ответ: многие приложения по-прежнему требуют ограничений, согласованности и гарантий, которые предоставляют базы данных SQL. В таких случаях некоторые «преимущества» NoSQL могут превратиться в недостатки. Другие ограничения связаны с тем, что системы NoSQL относительно новы. 

Нет схемы

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

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

Конечная последовательность

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

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

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

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

Блокировка NoSQL

Большинство систем NoSQL концептуально схожи, но реализованы по- разному. У каждого есть свои метафоры и механизмы запроса данных и управления ими.

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

Если вы переходите, скажем, с MongoDB на CouchDB (или наоборот), вы должны делать больше, чем просто переносить данные. Вы также должны ориентироваться в различиях в доступе к данным и программных метафорах - другими словами, вы должны переписать те части вашего приложения, которые обращаются к базе данных.

Навыки NoSQL

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

Для справки, Indeed.com сообщает, что по состоянию на конец 2017 года объем объявлений о вакансиях для обычных баз данных SQL - MySQL, Microsoft SQL Server, Oracle Database и т. Д. - за последние три года остается выше, чем объем вакансий. для MongoDB, Couchbase и Cassandra. Спрос на опыт NoSQL растет, но он по-прежнему составляет небольшую часть рынка для обычного SQL.

Слияние SQL и NoSQL

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

С другой стороны, базы данных NoSQL добавляют не только SQL-подобные языки запросов, но и другие возможности традиционных баз данных SQL. Например, как минимум две базы данных документов - MarkLogic и RavenDB - обещают быть совместимыми с ACID.

Вот и есть признаки того, что будущие поколения баз данных будут колебаться между парадигмами и будут предлагать функциональность как NoSQL, так и SQL. Microsoft Azure Cosmos DB, например, использует набор примитивов под капотом для взаимозаменяемого воспроизведения поведения обоих типов систем. Google Cloud Spanner - это база данных SQL, которая сочетает в себе высокую согласованность с горизонтальной масштабируемостью систем NoSQL.

Тем не менее, чистые системы SQL и чистые системы NoSQL еще долгие годы будут иметь свое место. Обратите внимание на NoSQL, чтобы получить быстрый и хорошо масштабируемый доступ к данным в свободной форме. Это связано с некоторыми затратами, такими как согласованность чтения и другие меры безопасности, общие для баз данных SQL. Но для многих приложений эти меры безопасности вполне могут стоить обмена на то, что предлагает NoSQL.