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 с обычной базой данных:

Понимание NoSQL

NoSQL относится к базе данных, которая не основана на SQL (Structured Query Language), языке, чаще всего ассоциирующимся с реляционными базами данных. По факту, NoSQL данные не являются реляционными, NoSQL БД обычно не имеют схем и они имеют более согласованную модель, чем имеющиеся в традиционных реляционных БД.

Термин «NoSQL» означает, что традиционные реляционные БД не позворяют решить все задачи, особенно те, которые связаны с большими объемами данных. Термин был расширен до значения «Not only SQL», который означает поддержку для потенциальных SQL-интерфейсов в каждом ядре нереляционной БД. Разработчики приложений, которые используют NoSQL решения, не обязательно исключают реляционные БД, а вместо этого видят ценность правильности использования каждого из хранилищ данных для решения соответствующей задачи.

Использование NoSQL

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

Кеширование

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

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

Некоторые NoSQL БД сохраняют пары ключ-значение для быстрого поиска, к примеру, в случае доступа вопрос/ответ. Реляционные БД более ориентированы на сохранение сложных структур данных и различных взаимосвязей между типами данных. Эта технология излишне усложняет, когда разработчик хочет реализовать способ быстрого сохранения и доступа к Q&A данным.

Хранение документов

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

Быстрый доступ к большим наборам данных

Реляционные БД теряют производительность при поиске в больших объемах данных. Исторически, разработчики строят системы, в которых пишутся SQL запросы для нахождения небольшого количества записей, которые удаляют для увеличения общей эффективности. Чем больше результирующий набор, тем более дорогим становится запрос. Большие объемы данных или запросы, которые включают обработку больших объемов данных, называются «data warehousing».

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

Менее жесткие требования согласованности

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

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

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

SQL является мощным, 40-летним стандартом, который был возможен потому, что все реляционные БД имели одну и ту же концепцию сохранения данных в таблицы и ссылку на них посредством внешнего ключа. Несмотря на то, что переход с одной реляционной БД на другую не на 100% прозрачен, он намного легче, чем переход между двумя различными NoSQL хранилищами. Разрабочики, изучившие SQL, сталкиваются с небольшими проблемами при переходе между вендорами.

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

примеры NoSQL баз данных

Доступно множество NoSQL хранилищ; ниже представлены наиболее популярные:

  • MongoDB. Документная БД с открытым исходным кодом.
  • CouchDB. БД, которая использует JSON для документов, JavaScript для MapReduce запросов, и обычный HTTP для API.
  • GemFire. Распределенная платформа управления данными, обеспечивающая динамическую масштабируемость, высокую производительность и сохранность как у БД.
  • Redis. Сервер структур данных, где ключами могут быть строки, хеши, списки, наборы и сортированные наборы.
  • Cassandra. БД, которая обеспечивает масштабируемость и высокую надежность без потери производительности.
  • memcached. Высокопроизводительная, распределенная в памяти и объектная система кеширования с открытым исходным кодом.
  • Hazelcast. Высоко масштабируемая распределенная платформа с открытым исходным кодом.
  • HBase. Hadoop БД, распределенное и масштабируемое хранилище больших объемов данных.
  • Mnesia. Распределенная система управления базами данных.
  • Neo4j. Высокопроизводительная, enterprise-класса графовая БД с открытым исходным кодом.

С оригинальным текстом урока вы можете ознакомиться на spring.io.

Учебные материалы

Spring data и поддержка NoSQL

Ниже приведены ссылки на Spring NoSQL проекты:

Каждый из этих проектов предоставляет упрощенный API для взаимодействия с соответствующим хранилищем. Они также используют Spring Data Commons для возможности написания базовых методов, таких как save(), delete(), update() и findXxxYyyZzz(), с автоматической генерацией запросов.

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

NoSQL подход в хранении данных

February 21, 2020 Jazz Team Технические статьи , 0

В данной статье описан иной, отличающийся от классического RDBMS, подход хранения данных — NoSQL. Описаны их общие отличительные характеристики — ACID, BASE, детали и требования к каждому типу базы данных (БД). Раскрываются типы NoSQL баз, приводятся примеры (реализации) каждого из типов и области их применения. Анализируется несколько видов модели: “один ко многим”, “многие к одному”, — и происходит обоснование для какой модели лучше применять RDBMS или NoSQL решение.

Сравнение NoSQL и RDBMS подхода

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


Основные причины внедрения баз данных NoSQL:

  • Потребность в больших возможностях масштабирования, чем у реляционных БД, включая обработку очень больших наборов данных или очень большую пропускную способность по записи.
  • Предпочтение свободного программного обеспечения вместо коммерческих продуктов.
  • Желание избавиться от ограниченности реляционных схем и стремление к более динамичным и гибким моделям данных.

Не смотря на обилие реализаций NoSQL, основные отличия от классических RDBMS решений таковы:

Виды NoSQL решений

В зависимости от модели данных, подходов к распределенности репликации, можно выделить несколько типов хранилищ:

  • БД на основе пар “ключ-значение”. Это тип NoSQL базы, в которой данные хранятся как совокупность пар “ключ-значение”. Ключ является уникальным идентификатором. Ключи и значения могут представлять собой любую простую, сложную составную или байтовую информацию (изображения). Этот тип БД имеет большие возможности для горизонтального масштабирования. Примеры БД — DynamoDB, Cassandra, Redis, Riak.
  • Документоориентированная БД. Этот тип БД предназначен для хранения иерархических структур данных в виде документов, которые легко поддаются чтению человеком (например, JSON). В документной базе нет четкого регламента на схемы документов — документы могут иметь одинаковую или разную структуру. Примеры БД — CouchDB, Couchbase, MongoDB.
  • Графовые БД. Эти БД применяются для тех задач, где необходимо хранить и отслеживать взаимосвязи. В графовых БД основными элементами являются узлы и связи (ребра). Узлы используются для хранения сущностей, а ребра — для хранения взаимосвязей между сущностями. Работа с БД представляет собой обход определённых типов ребер или всего графа целиком, что происходит очень быстро по причине хранения этой информации в ребрах. Пример использования — соц. сети, сервисы выявления фрода. Примеры графовых БД — Neo4j, Neptune, AllegroGraph.
  • Поисковые БД. Эти БД используют индексы для классификации общих характеристик для поступающих данных и основная цель этих БД — содействовать быстрому поиску. Поисковые БД оптимизированы для работы (поиска) с информацией, которая может быть велика и быть плохо структурирована. Обычно эти БД предоставляют методы для простого поиска по тексту, по регулярным выражениям и определенную обработку результатов поиска. Примеры БД — Elasticsearch, Splunk.

Проблема выбора: RDBMS или NoSQL. Что выбрать?

Проиллюстрируем возможность выражать некий объект, например, “резюме” — на языке реляционной схемы.

Профиль в целом определяется уникальным идентификатором user_id. Такие поля, как first_name и last_name, встречаются ровно один раз для одного пользователя, так что их можно сделать столбцами в таблице users.

Однако у большинства людей за время карьеры бывает больше одной работы (должности), а также могут меняться периоды обучения и число элементов контактной информации. Между пользователем и этими элементами существует связь “один-ко-многим”. В SQL-модели, в случае наиболее распространенного нормализованного представления “должности”, “образование” и “контактная информация” помещаются в отдельные таблицы со ссылкой на таблицу users в виде внешнего ключа, как показано на (см. Рисунок 1. Представление профиля).

Для структур данных типа “резюме”, обычно являющихся самостоятельным документом, вполне подойдет представление в формате JSON.

Пример 1. Представление профиля в виде JSON документа:

Преимущество данного формата в том, что он намного проще, чем XML, и удобно читаем для человека. Эту модель данных поддерживают документоориентированные БД, такие как Couchbase. У JSON-представления лучшая локальность, чем у многотабличной схемы (см. Рисунок 1. Представление профиля).

Для извлечения профиля в реляционном примере необходимо выполнить несколько запросов (по запросу к каждой таблице по user_id) или запутанное многостороннее соединение (Join) таблицы users с подчиненными ей таблицами.

В JSON-представлении же вся нужная информация находится в одном месте, и одного запроса вполне достаточно. В данном случае наблюдается связь “один ко многим”, что означает древовидную структуру данных.

Рисунок 1. Представление профиля

На (см. Рисунок 1. Представление профиля) поля region_id и industry_id представляют собой ссылки на внешние таблицы (foreign key), а не текстовые строки вроде “Seattle Area” или “Philanthropy”.
Сделано это по нескольким причинам:

  • Единообразие стиля, однозначность — например, написание названий городов с одинаковыми названиями, но в разных районах.
    Удобство модификации — имя хранится только в одном месте в его легко переименовать по всей системе.
  • Простая локализация — при переводе интерфейса на другие языки значения можно легко перевести из-за того, что эти значения хранятся в одном месте.
  • Хорошие возможности поиска — данный профиль может быть найден по поиску филантропов определённого региона.

Хранить ли ID или текстовую строку — вопрос дублирования данных. При использовании ID информация хранится только в одном месте, а при ссылке на нее везде применяется ID. Однако при непосредственном хранении значения такая информация дублируется в каждой записи. Продублированная информация может измениться, поэтому придется обновлять все имеющиеся копии. Это приводит к избыточности записи и риску несоответствий (когда обновлена лишь часть информации). Встает вопрос о нормализации БД.

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

Заключение

NoSQL, как и любая технология, имеет свои преимущества и недостатки. NoSQL базы данных являются более оптимальным решением, если ваши требования к БД:

  • Скорость. NoSQL базы данных обычно быстрее, а иногда намного быстрее, когда дело доходит до записи. Операции чтения также могут быть довольно быстрыми в зависимости от того, какую именно БД вы используете.
  • Требуется хранить большие объемы неструктурированных данных.
    Безсхемная разработка. Реляционные СУБД требуют четко описанную структуру данных до начала работы. NoSQL решения предлагают более гибкие решения.
  • Автоматизированная (или очень простая) репликация/масштабирование. NoSQL базы данных быстро развиваются — разработчики активно решают основные проблемы, одна из которых — репликация и масштабирование. В отличии от реляционных СУБД, NoSQL решения легко масштабируются и работают с кластерами.
  • Наличие лишь связей one-to-one и one-to-many между сущностями.
  • Экономия на подписке и поддержке, так как большинство NoSQL БД являются open source проектами.

NoSQL, базы данных: обзор, примеры и сферы применения

NoSQL представляют собой хранилище, которое не соответствует модели реляционных баз данных и их характеристикам, у них нет схем, они не объединяются, и не гарантируют свойство ACID. Масштабируется NO-система горизонтально и использует широкий объем основной памяти компьютера, решая проблему больших объемов информации.

Собственные проприетарные типы – это новая методология разработки нереляционных баз данных NoSQL, выполненная крупными компаниями для удовлетворения корпоративных нужд, такими, например, как BigTable от Google, который считается первой системой NoSQL, и Amazon DynamoDB. Успех этих систем положил начало разработке ряда похожих систем БД с открытым исходным кодом и проприетарных БД, наиболее популярными из которых являются Hypertable, Cassandra, MongoDB, DynamoDB,

Эволюция NoSQL

Проблема масштабируемости SQL была признана компаниями Web 2.0 с огромными, растущими потребностями в данных и инфраструктуре, такими как Google, Amazon и Facebook. Они нашли собственные решения проблем, внедрив технологии BigTable, DynamoDB и Cassandra. Растущий интерес привел к появлению ряда систем управления базами данных NoSQL (СУБД) с акцентом на производительность, надежность и согласованность. Ряд существующих структур индексации были повторно использованы и улучшены с целью повышения производительности поиска и чтения.

Термин был придуман Калором Строцци еще в 1998 году, а воскрешен в 2009 году сотрудником Rackspace Эриком Эвансом для решения проблем веб-компаний с большим объемом операций и информации.

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

Таким образом NoSQL не имеют фиксированной структуры таблиц, как в реляционной системе. В этой таблице приведено краткое сравнение возможностей NoSQL и SQL.

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

Типы информационных хранилищ

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

Все, что нужно для работы с предметами, хранящимися в базе данных — это ключ. Данные хранятся в виде строки JSON или BLOB (большой двоичный объект). Одним из самых больших недостатков этой формы является отсутствие согласованности на уровне БД. Это может быть добавлено во время разработки базы данных NoSQL программистами со своим собственным кодом, но это также требует больше усилий, из-за сложности реализации и времени. Самая известная БД NoSQL, построенная на хранилище значений ключей — это Amazon DynamoDB.

Хранилища документов (Document) аналогичны хранилищам значений ключей в том, что они не содержат схемы и основаны на модели значений. Следовательно, оба типа имеют одинаковые преимущества и недостатки. И той, и другой не хватает согласованности на уровне базы данных, что не позволяет приложениям предоставлять больше надежных функций. Тем не менее существуют некоторые ключевое различие между ними. В хранилищах документов значения (документы) обеспечивают кодировку для хранимых данных. Такими кодировками могут быть XML, JSON или BSON (двоичный код JSON). Самым популярным приложением БД, использующим хранилище документов, является MongoDB.

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

Хранилища столбцов имеют быстрый доступ для чтения/записи к сохраненным данным. В нем столбцы строки соответствую одному столбцу и хранятся, как одна запись на диске. Это обеспечивает более быстрый доступ во время операций чтения/записи. Наиболее популярные базы данных, которые используют хранилище столбцов баз данных NoSQL, примеры: Google BigTable, HBase и Cassandra.

В БД NoSQL Graph Bd для представления данных используется структура ориентированного графа. Граф состоит из ребер и узлов.

Принцип работы БД

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

  1. Горизонтальной масштабируемости с возможностью увеличения своего размера, увеличения пространства хранения в БД без ущерба для работы.
  2. Облачной технологии. Большинство БД NoSQL базируют свое хранилище в облаке, чтобы освободить больше места. Кроме того, у них есть узлы для репликации информации.
  3. Эффективного использования ресурсов. Компании в настоящее время находятся в процессе технологического перехода, поэтому практически необходимо, чтобы у них была БД, позволяющая им внедрять новые технологические инструменты. Данные NoSQL работают именно для этого — гибкая модель позволяет быстро адаптироваться к новым инструментам.
  4. Свободной схемы функционирования. NoSQL не имеют жесткой системы, поэтому у программистов есть свобода изменять данные по необходимости. Это означает, что если требуется изменить определение поля или типа данных, то в этом нет проблем в отличие от баз SQL, где изменения подобного рода связаны с большими сложностями.
  5. Скоростью отклика. Скорость в БД измеряется задержкой, которая является временем отклика, NoSQL озабочены максимально возможным уменьшением времени задержки.
  6. Использование индексов. SQL и NoSQL нуждаются в индексах, поскольку запросы не могут быть сделаны в миллионах записей, если индекс не был настроен. В NoSQL индексы генерируются в форме B-Tree, то есть узлы сбалансированы, а значит увеличивается скорость поиска.
Мастер Йода рекомендует:  10 полезных ресурсов по технологии blockchain

Системы управления

В следующей таблице приведено краткое сравнение между различными системами управления БД NoSQL.

MongoDB имеет гибкое хранилище схем — это означает, что хранимые объекты не обязательно должны иметь одинаковую структуру или поля. Он также имеет некоторые функции оптимизации, которые распределяют коллекции данных между собой, что приводит к общему улучшению производительности и более сбалансированной системе. Другие системы NoSQL, такие, как Apache CouchDB, также являются БД типа хранилища документов и имеют много общих возможностей с MongoDB, за исключением того, что к БД можно получить доступ с помощью API RESTful.

REST — это архитектурный стиль, состоящий из скоординированного набора архитектурных ограничений, применяемых к компонентам, соединителям и элементам данных в интернете. Он основан на кешируемом коммуникационном протоколе «клиент — сервер» без сохранения состояния, например, HTTP-протокол. Приложения RESTful используют HTTP-запросы для публикации, чтения и удаления данных. Что касается баз данных столбцов, Hypertable — это БД NoSQL, написанная на C ++ и основанная на Google BigTable. Hypertable поддерживает распределение хранилищ данных по узлам для обеспечения максимальной масштабируемости, как MongoDB и CouchDB.


Гибридная система Cassandra

Одна из наиболее широко используемых БД NoSQL — Cassandra, разработанная Facebook. Целью Cassandra было создание СУБД, которая не имеет единой точки отказа и обеспечивает максимальную доступность. Cassandra — это, главным образом, БД хранилища столбцов. В некоторых исследованиях она упоминалась как гибридная система, основанная на Google BigTable, которой является БД хранилища столбцов и Amazon DynamoDB, присущая типу «ключ-значение». Ключи в Cassandra указывают на набор семейств столбцов с опорой на распределенную файловую систему Google BigTable и функции доступности Dynamo (распределенная хеш-таблица).

Основные характеристики Cassandra включают в себя:

  1. Отсутствие единой точки отказа. Для этого она должна работать на кластере узлов, а не на одной машине. Это не означает, что данные на каждом кластере одинаковы. Когда происходит сбой в одном из узлов, данные на нем будут недоступны. Однако другие узлы и данные по-прежнему будут доступны.
  2. Распределенное хеширование — это схема, которая обеспечивает функциональность хэш-таблицы таким образом, что добавление или удаление одного слота не приводит к значительному изменению отображения ключей на слоты. Это позволяет распределять нагрузку на серверы или узлы в соответствии с их емкостью и минимизировать время простоя.
  3. Относительно простой в использовании клиентский интерфейс. Она использует Apache Thrift для своего клиентского интерфейса, который предоставляет RPC-клиент на нескольких языках, но большинство разработчиков предпочитают альтернативы с открытым исходным кодом, созданные на основе Apple Thrift, например, Hector.
  4. Репликация данных. По сути, он отражает данные для других узлов в кластере. Репликация может быть случайной или определенной для максимальной защиты данных, например, путем размещения в узле другого центра обработки данных.
  5. Политика разделения решает, где и на каком узле разместить ключ. Это может быть случайным или упорядоченным процессом. При использовании обоих типов политик разделения Cassandra может найти баланс между нагрузкой и оптимизацией производительности запросов.
  6. Согласованность. Репликация усложняет согласованность. Это связано с тем, что все узлы должны быть обновлены в любой момент времени с самыми последними значениями или во время запуска операции чтения.
  7. Чтение/запись действий. Клиент отправляет запрос одному узлу. Узел, согласно политики репликации, сохраняет данные в кластере. Каждый узел сначала изменяет данные в журнале фиксации и обновляет структуру таблицы, причем оба изменения выполняются синхронно. Запрос на чтение отправляется одному единственному узлу, который содержит данные в соответствии с политикой разделения/размещения.

Структуры индексации

Индексирование — это процесс связывания ключа с расположением соответствующей записи данных в СУБД. Существует множество структур индексирования данных, используемых в базах данных NoSQL. B-Tree является одной из наиболее распространенных структур индекса в СУБД. В ней внутренние узлы могут иметь переменное количество дочерних узлов в предопределенном диапазоне.

Одно из основных отличий от других древовидных структур, таких как AVL, заключается в том, что B-Tree позволяет иметь переменное количество дочерних узлов, что означает меньшую балансировку дерева, но большую потерю пространства. B + Tree — один из самых популярных вариантов B-деревьев. Это улучшение (в отличие от B-Tree) требует, чтобы все ключи находились в листьях.

Структура данных T-Trees была разработана путем объединения функций AVL-Trees и B-Trees. Деревья AVL относятся к типу самобалансирующихся деревьев двоичного поиска, тогда как деревья B — несбалансированы, а у каждого узла может быть разное количество дочерних элементов.

В T-дереве структура очень похожа на AVL-дерево и B-дерево. Каждый узел хранит более одного кортежа . Кроме того, двоичный поиск используется в сочетании с узлами и несколькими кортежами, чтобы обеспечить лучшую память и производительность.

T-дерево имеет три типа узлов: с правым и левым дочерним узлом, конечный узел без дочерних узлов и узел с половинным листом только с одним дочерним узлом. Считается, что у T-Trees лучшая общая производительность.

Распространенные ошибки применения БД

Существуют три распространенные ошибки, которые совершают организации, когда дело доходит до NoSQL:

  1. NoSQL — это больше, чем масштабируемость, нельзя приравнивать NoSQL к веб-шкале. Прародителями современных нереляционных баз данных были такие компании, как Google и Amazon, которые сосредоточились на том, чтобы решать проблемы масштабируемости в веб-среде.
  2. Разработчики должны развиваться. В одном высококлассном веб-проекте плохо отобранная команда по интеграции создала огромную проблему, и чтобы устранить ее, потребовались время и миллионы долларов.
  3. Усложненное распространение. Ничто не заменит знания и опыт ни в реализации, ни в процессе администрирования. Случается так, что запрос, который быстро выполняется на локальной машине разработки, не будет масштабироваться горизонтально на сотнях машин. Современное приложение имеет распределенную архитектуру и множество пользователей одновременно, которые требуют быстрых ответов.

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

Базы данных NoSQL и SQL конкурируют между собой, но, по мнению многих специалистов, первая имеет больше преимуществ по сравнению с традиционными реляционными базами данных:

  1. Имеют простую и гибкую структуру.
  2. Не имеет схем.
  3. Основана на парах «ключ-значение».
  4. Некоторые типы включают хранилище столбцов, документов, значений ключей, графиков, объектов, XML и другие режимы данных.
  5. Обычно каждое значение в БД имеет ключ. Некоторые хранилища позволяют разработчикам хранить сериализованные объекты, а не только простые строковые значения.
  6. NoSQL с открытым исходным кодом не требуют дорогостоящих лицензионных сборов и могут работать на недорогом оборудовании, что делает их развертывание рентабельным.
  7. При работе с NoSQL, независимо от того, являются ли они открытыми или проприетарными, расширение проще и дешевле, чем при работе с реляционными базами данных. Оно выполняется путем горизонтального масштабирования и распределения нагрузки по всем узлам, а не по типу вертикального масштабирования, который обычно выполняется в системах реляционных баз данных и заменяет основной хост более мощным.

Недостатки No-системы

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

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

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

Применение базы данных NoSQL

Академические работники, инженеры, архитекторы программного обеспечения, дизайнеры приложений и программисты требуют более глубокого знания структур данных, которые ранее не требовались для реляционных баз данных. Лидерами рынка являются — Hadoop и MongoDB, вслед за «Кассандрой», «Редисом», CouchDB и «Риаком». Современные исследования показывают, что есть два продукта NOSQL, которые доминируют над системными инженерами, архитекторами программного обеспечения, разработчиками среди десятка аналогичных технологий – это MongoDB и Hadoop.

Рынок показывает, что крупные компании используют новые методологии разработки баз данных NoSQL и интегрируют их в свои продукты (Oracle, IBM). Рынок БД понемногу превращается в стандарт PasS, Redis и MongoDB, Edlich. Такие продукты, как Neo4j, MongoDb и CouchDb, стали объектом поддержки и инвестирования венчурного капитала.

Модели и системы управления базами данных NoSQL

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

В данной статье речь пойдёт о популярных СУБД NoSQL, их функциях и целях.

Системы управления базами данных

Базы данных – это логически организованные хранилища для различных видов данных. Каждая БД имеет свою модель, которая определяет структуру данных. Системы управления базами данных – это приложения (или библиотеки), которые управляют различными базами данных.

Примечание: Чтобы узнать больше о системах управления базами данных, читайте эту статью.

Системы управления базами данных NoSQL

В прошлом десятилетии лучшим средством для хранения данных считались реляционные СУБД. Такие СУБД не очень гибкие, но позволяют создавать производительные и сложные базы данных. Раньше этого было более чем достаточно, однако сегодня у разработчиков возникают другие потребности.

Термин NoSQL появился более десяти лет назад как название для ещё одной реляционной БД. Однако эта БД основана на другой идее: она отказывается от использования стандартизированного SQL. В последующие годы появляются и другие подобные базы данных, и в результате они объединились под названием «нереляционные базы данных», или NoSQL.

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

Существует несколько различных операционных моделей и систем для баз данных NoSQL:

  • Хранилище «ключ-значение» (Redis, MemcacheDB и т.п.).
  • Хранилище колонок (Cassandra, HBase).
  • Документо-ориентированные СУБД (MongoDB, Couchbase).
  • Графовые СУБД (OrientDB, Neo4J).

Рассмотрим эти модели подробнее

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

Такие СУБД можно считать самой базовой реализацией NoSQL.

Они работают путём сопоставления ключей со значениями (как в словаре), между которыми нет ни структуры, ни отношений. Подключившись к серверу базы данных, (например, Redis), приложение может определить ключ (например, the_answer_to_life) и установить его значение (например, 42)ю позже эту пару можно извлечь посредством ключа.

СУБД типа «ключ-значение» часто используются для быстрого сохранения основной информации или второстепенных данных, полученных путём сложных вычислений. Они чрезвычайно производительны и, как правило, легко масштабируются.

Хранилища колонок

Эти хранилища основаны на подходе «ключ-значение», но расширяют и усложняют его.

Такие СУБД создают коллекции из пар «ключ-значение». В отличие от традиционных схем реляционных баз данных, хранилища колонок NoSQL не требуют предварительно структурированных таблиц для работы с данными. Каждая запись состоит из одной или больше колонок, в которых хранится информация, и каждая колонка каждой записи может отличаться от остальных.

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

Как правило, такие БД используются в случаях, когда обычного хранилища «ключ-значение» недостаточно и необходимо хранить очень большие объёмы данных. Кроме того, хранилища колонок легко масштабировать.

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

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

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

Несмотря на высокую производительность и множество преимуществ, документо-ориентированные СУБД имеют некоторые недостатки и уязвимости по сравнению с другими СУБД NoSQL . Например, извлекая значение записи, вы получаете огромный объём данных, а обновление данных негативно влияет на производительность.

Графовые СУБД

Графовые базы данных представляют данные совсем иначе, чем предыдущие три модели. Они используют древовидные структуры – графы, которые состоят из узлов и рёбер.

Графовые СУБД соединяют и группируют полученные данные, благодаря чему они намного быстрее справляются с некоторыми операциями.

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


Базы данных NoSQL на основе модели «ключ-значение»

Самыми популярными приложениями данной категории являются:

  • Redis (открытое сетевое хранилище данных).
  • Riak (открытая распределённая система управления базами данных).
  • Memcached / MemcacheDB (распределённая СУБД).
  • Кэширование: быстрое сохранение данных для их дальнейшего использования.
  • Создание очередей: многие хранилища типа «ключ-значение» (например, Redis) поддерживают списки, наборы, очереди и многое другое.
  • Распределение задач и данных: такие СУБД можно использовать для реализации Pub/Sub.

Базы данных NoSQL на основе хранилищ колонок

  • Cassandra: BigTable-подобная база данных, основанная на DynamoDB.
  • HBase: BigTable-подобное хранилище данных для Apache Hadoop.
  • Хранение неструктурированной информации: такие СУБД отлично подходят для длительного хранения больших коллекций атрибутов и значений.
  • Масштабирование: СУБД на основе хранилищ колонок легко масштабировать.

Документо-ориентированные СУБД

  • Couchbase: Memcached-совместимая документо-ориентированная база данных на основе JSON.
  • CouchDB: инновационное документо-ориентированное хранилище данных.
  • MongoDB: широко распространённая и многофункциональная БД.
  • Уплотнение информации: вы можете создавать очень сложные структуры данных.
  • Совместимость с JavaScript и JSON: одна из наиболее важных функциональных возможностей таких СУБД.

Графовые СУБД

  • Neo4J: высокопроизводительная база данных на основе графов.
  • Обработка сложных связей между данными: графовые БД очень продуктивны в обработке сложных и косвенных отношений между данными.
  • Моделирование и обработка классификаций: графовые БД отлично справятся с любой ситуацией, в которой важны отношения между данными, в том числе с моделированием данных и классификацией различной информации.

Реляционные СУБД vs. NoSQL

Чтобы подвести итоги данной статьи, сравним реляционные и NoSQL СУБД.

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

NoSQL базы данных: хранилища и доступность данных

Не только те разработчики, кто уже год-два работает с крупными проектами с миллионными бюджетами, но и самые обычные средние студии всё чаще сталкиваются с заказами, проектами, которые подразумевают сотни тысяч, а то и миллионы хитов в день. Как правило, это современные интернет-магазины с очень большой номенклатурой товаров (например, магазин с 500 000 карточек товаров и 3 млн SKU) . Но могут быть и информационные и корпоративные проекты. Всё это надо как-то уметь проектировать, обслуживать, как-то с этим работать.

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

Проблемы перед веб-студиями возникают как только они получают заказ на проект чуть более сложный, чем обычно. Немного более сложный, немного более большой, немного более высоконагруженный. (В рамках Bitrix Framework это означает, что как только запросы клиента выходят за пределы административной части, инфоблоков с контентом, то начинаются сложности.) В этом курсе мы постараемся дать простые методики как выжить в данном случае.

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

В первом случае полезна будет, в первую очередь, глава про эксплуатацию, во втором — глава про разработку.

Цель курса — помочь веб-студиям в организации работ, разработки и эксплуатации проектов. Этот курс — не столько теоретический, сколько практический, он построен на опыте разработки больших и малых, высоконагруженных и простых проектов.

Курс рассматривает вопросы создания высоконагруженных и сложных проектов без привязки к нашим продуктам. Примеры на базе платформы Bitrix Framework, приведённые в курсе, даны как один из вариантов реализации. Всё, что говорится на страницах ниже, можно применить и при работе с другими системами.

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

Скачать материалы курса в формате CHM. Файлы формата CHM обновляются ежемесячно, тем не менее, возможно некоторое отставание их от онлайновой версии курса.

Чтобы отключить подобное отношение к файлу необходимо:

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

Отсутствие кнопки Разблокировать возможно в двух случаях:

  1. Файл лежит не локально, а на сетевом ресурсе.
  2. Если файл лежит на локальном диске, но путь к нему содержит спецсимволы (# и прочие).

Преимущества и недостатки нереляционных баз данных

Сентябрь 29, 2020

Во многих источниках определение NoSQL баз данных подается достаточно неоднозначно, что может сформировать у читателя неверное или неполное представление о значении этого термина. Сама его суть сбивает с толку — равно как под определение “неодушевленные предметы” может попадать камень, лампочка и автомобиль — понятие NoSQL связывает между собой программные решения, зачастую совершенно не аналогичные.

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

Предпосылки появления

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

История популярности

Пик самого активного обсуждения NoSQL баз данных пришелся на 2009 год и принес с собой множество мифов и спорных теорий. Рассмотрев их, можно представить себе путь NoSQL решений и представления о них в головах людей.

NoSQL — это революция

А так же “у нас совершенно новая система, свежая идея, которая перевернёт полностью устоявшийся порядок” — подобное можно услышать в речах активно продвигающих NoSQL продукты людей. Но в реальности, никакого революционного прорыва не произошло. NoSQL базы данных развивались, как эволюция реляционной модели, благодаря появлению новых требований хранения и доступа к информации.

Принципиально новыми подходами NoSQL решения тоже не могут массово похвастаться — к примеру, концепция запущенной в 2008 году MongoDB — это более эффективная реализация модели работы БД Pick 1965-го года выпуска.

SQL базы данных обречены

Подобные разговоры ведутся уже почти второй десяток лет, и по-прежнему реляционные БД держат доминирующие позиции на рынке с огромным отрывом от любых NoSQL решений. Это происходит в первую очередь потому, что NoSQL базы данных не могут более эффективно решать задачи SQL. Наиболее удачные NoSQL решения, в первую очередь, нацелены на решения специфических задач и создаются гигантами IT-индустрии для собственных нужд — это продукты от Google, Amazon, Microsoft и Apache, обслуживающие конкретные проекты. Google AppEngine Data Store возможно использовать столько с веб-сервисами Google, хранилище SQL Data Services является частью платформы Microsoft Azure, а SimpleDB входит в состав Amazon WebServices.

Мастер Йода рекомендует:  Для веб-дизайнеров 15 универсальных WordPress-тем

Необлачные хранилища, которыми можно пользоваться, просто скачав и установив их у себя, зачастую являются достаточно молодыми открытыми проектами, которые так же создавались под конкретные нужды. Они не были созданы, чтобы решать весь объем задач, который позволяют решать SQL системы. Более того, назначение чаще всего не является ключевой преградой для массового внедрения NoSQL систем — они имеют определенный набор недостатков, который не критичен для гигантов IT-индустрии, но становится решающим для большей части обычных компаний.

Вся шумиха вокруг NoSQL и Big Data — это обман

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

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


Виды NoSQL баз данных

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

Хранилище вида “ключ-значение”

Хранилища “ключ-значение” представляют собой простейший вид базы данных, являясь, по сути, ассоциативным массивом — каждому значению сопоставляется свой уникальный ключ. Простота хранилищ этого типа открывает просторы невероятной масштабируемости. Не требуется никаких схем построения базы данных, нет никакой связи между значениями, по сути количество элементов ассоциативного массива ограничено лишь вычислительными мощностями. Именно потому данный вид хранилищ интересен в первую очередь компаниям, предоставляющим услуги облачного хостинга.

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

Именно потому подобные хранилища используются в тех случаях, когда конкретное содержимое отдельной ячейки не интересно оператору базы данных — иначе говоря, полностью отсутствуют связи между отдельными ячейками хранилища. Базы данных типа “ключ-значение” не очень хорошо подходят в качестве полной замены реляционных БД, но нашли своё применение в качестве кэшей для объектов — ведь между кэшированными объектами разных пользователей точно так же нет связей, важна лишь скорость доступа к кэшу, а так же возможность быстро менять масштаб системы.

Наиболее известные примеры СУБД данного типа это Amazon DynamoDB, Berkeley DB, MemcacheDB, Redis и Riak.

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

Документоориентированная БД представляет собой систему хранения иерархических структур данных (документов), имеющую структуру дерева или леса. Структура дерева начинается с корневого узла и может иметь несколько внутренних и листовых узлов. Листовые узлы содержат конечные данные, которые при добавлении заносятся в индексы базы, благодаря которым можно осуществлять быстрый поиск даже при достаточно сложной общей структуре хранилища. Фактически документоориентированные БД являются более сложной версией хранилищ “ключ-значение” — они все ещё не очень хороши для систем, подразумевающих множество связей между элементами, но позволяют осуществлять выборку по запросу без полной загрузки отдельных документов в оперативную память. Механизмы поиска позволяют находить как документы целиком, так и части документов, а древовидная структура позволяет организовывать отдельные коллекции документов одного типа или схожей тематики.

К примеру, при создании музыкального хранилища можно создать коллекцию музыки 80х годов, в ней сделать отдельные коллекции по годам, а внутри них отдельные документы с треками выпущенных в этот год альбомов. Но если пользователь пожелает увидеть рейтинг самых популярных композиций определенного десятилетия — этот запрос будет выполняться достаточно долго, ведь придется просмотреть каждый документ всей базы данных. Таким образом, можно сделать вывод что документоориентированные БД найдут своё применение в задачах, где требуется упорядоченное хранение информации, но нет множества связей между данными и не нужно постоянно собирать статистику по ним. Документы не требуют определения схемы — это значит что каждый отдельный документ может состоять из любого количества уникальных полей — в отличие от реляционных баз данных, в которых при попытке хранить разнородные данные неизбежно появляются пустые поля.

Примеры СУБД данного типа: CouchDB, Couchbase, MarkLogic, MongoDB, eXist.

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

Графовая модель базы данных представляет собой обобщение сетевой модели данных и отличается сильными связями между узлами.

Графовые базы данных лучше всего подходят для реализации проектов, предполагающих естественную графовую структуру данных — в первую очередь социальных сетей, а так же для создания семантических паутин. В подобных задачах они сильно опережают реляционные БД по производительности, простоте внесения изменений и наглядности представления информации. У некоторых баз данных существуют механизмы специальной оптимизации для работы с SSD-накопителями. Для работы с достаточно большими графами используются алгоритмы, предполагающие частичное помещение графа в оперативную память.

Наиболее известные графовые СУБД это ArangoDB, FlockDB, Giraph, HyperGraphDB, Neo4j, OrientDB.

Bigtable-подобные базы данных

Bigtable-подобные базы данных или иначе хранилища семейств колонок содержат данные, упорядоченные в виде разреженной матрицы, строки и столбцы которой используются в качестве ключей. Эти хранилища имеют много общего с документоориентированными БД — системы управления содержимым, регистрацию событий, блоги. Не стоит путать bigtable-подобные базы данных с колоночными хранилищами, которые являются, по сути, реляционными БД с раздельным хранением колонок.

Как правило, эти хранилища применяются для веб-индексирования и решения прочих задач, предполагающих огромные объемы данных.

Примерами СУБД данного типа являются: HBase, Cassandra, Hypertable, SimpleDB.

Сильные и слабые стороны NoSQL

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

Отсутствие SQL

Первая особенность весьма очевидна — это отсутствие SQL (Structured Query Language) — универсального языка запросов, который используется всеми реляционными системами. Все NoSQL системы имеют собственный API для взаимодействия или встроенный язык запросов, зачастую являющийся просто урезанной версией SQL. Это решение имеет свои позитивные стороны:

  • Простота работы. Многие NoSQL решения, в основном хранилища вида “ключ-значение” имеют по сравнению с реляционными базами данных очень сильно урезанную функциональность, которая им просто не требуется для выполнения поставленных задач. В таком случае оператору базы данных не требуется глубоких знаний достаточно мощного и гибкого механизма работы с SQL-запросами. Это очень сильно снижает входной порог для начала работы с NoSQL хранилищами.
  • Более простой синтаксис запросов — меньше ошибок. Для упрощения работы с базой данных некоторыми разработчиками используется ORM (Object-Relational Mapping) — технология, позволяющая автоматически транслировать операции с объектами в запросы к базе данных. Зачастую подобные решения работают неэффективно и плодят множество ненужных или откровенно ошибочных запросов. Нельзя сказать, что разработчики ORM плохо выполняют свою работу — просто задача слишком сложна. Язык SQL универсален и очень емок, для полноценной работы с ним необходим определенный багаж знаний. При этом собственные языки запросов современных NoSQL хранилищ гораздо больше подходят для выполнения простых манипуляций с базой данных.

Недостатки у данного решения так же присутствуют, притом в долгосрочной перспективе они могут серьёзно перевесить все позитивные моменты:

  • Приложение сильно привязывается к конкретной СУБД. Язык SQL универсален для всех реляционных хранилищ и пользователю не придётся кардинально переписывать весь код в случае смены СУБД. Даже если две NoSQL системы концептуально практически не отличаются, они будут иметь очень мало общих стандартов в API и в специфике запросов.
  • Ограниченная емкость встроенного языка запросов. SQL имеет очень богатую историю и множество стандартов. Это очень мощный и сложный инструмент для операций с данными и составления отчетов. Практически все языки запросов и методы API хранилищ NoSQL были созданы на основе тех или иных функций SQL — как следствие, они имеют куда меньшую функциональность.
  • Низкая ценность и узкопрофильность знаний — специалистов с хорошим знанием SQL гораздо проще найти, в то время когда спецификой работы API некоторых NoSQL решений на серьёзном уровне мало кто увлекается — это значит, что многие специфические моменты оператору базы данных придется осваивать “на ходу”.

Простота и молодость NoSQL

Если преимущества простоты NoSQL хранилищ достаточно очевидны, то недостатки зачастую выясняются только с горьким опытом. Во-первых, ограничения структуры реляционных БД в определенной степени гарантируют целостность данных — информация, которая не удовлетворяет ограничениям по типу, просто не сможет попасть в базу. В случае использования, например, хранилищ типа “ключ-значение” задача контроля целостности данных полностью ложится на приложение. Во-вторых, процесс создания реляционного хранилища включает в себя этап проектирования модели данных. На этой стадии можно оценить узкие места выбранной стратегии и спроектировать действительно надёжную и удобную систему. NoSQL решения не требуют определять схему базы данных перед началом работы. Но без этапа первоначального тестирования и планирования можно в процессе разработки наткнуться на непредвиденные трудности, которые могут даже полностью отсечь вариант работы с конкретным NoSQL решением. А учитывая описанные в предыдущем пункты трудности быстрого перехода с одной нереляционной базы данных на другую — цена ошибки становится очень высокой.

Теперь есть смысл обсудить другую важную особенность NoSQL решений — они все по большей части весьма молоды. Многие из них распространяются по BSD-подобной лицензии и поддерживаются усилиями сообщества. У каждой компании свои требования к надежности базы данных, и большая часть NoSQL решений остаются незамеченными зачастую, потому что они являются ещё слишком молодыми решениями. Многие нереляционные хранилища существуют лишь в виде бета-версий, и даже самые зрелые имеют достаточно малый багаж историй успешного внедрения по сравнению с реляционными СУБД. Помимо вероятности наличия багов и уязвимостей в самом коде нереляционных СУБД, это приводит к другим ошибкам — некоторые компании выбирают решения, которые просто не соответствуют их нуждам.

Самые сильные стороны NoSQL

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

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

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

Репликация — это копирование данных при их обновлении на другие сервера. Этот механизм позволяет добиться большей отказоустойчивости и масштабируемости системы. Принято выделять два вида репликации: master-slave и peer-to-peer.

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

Второй тип — peer-to-peer — предполагает, что все узлы равны в возможности обслуживать запросы на чтение и запись. Информация о обновлении данных передаётся от сервера к серверу по кругу.

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

Социальные данные

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

Пик популярности NoSQL решений был во многом связан с амбициозным заявлением, поступившим от социальной сети Twitter. Они видели определенные недостатки работы с реляционным хранилищем MySQL для своих твитов и изъявили желание перейти на новую NoSQL СУБД Cassandra. Но эта идея так и не была воплощена в жизни — как комментируют этот момент сами сотрудники Twitter — компания оценила свои приоритеты, после чего решение было признано слишком рискованным. С другой стороны, то же самое NoSQL хранилище отлично прижилось в качестве основной базы данных для социальных сетей Instagram и Facebook — а это уже очень весомые истории успеха для всего семейства NoSQL.

Аналитика данных

В облачных хранилищах и разработанных для них NoSQL решениях часто используется принцип множественной аренды. Он заключается в том, что большое количество пользователей одновременно использует одну и ту же систему. Чтобы предотвратить её перегруз в решениях, рассчитанных на большую масштабируемость, применяют политику ограничения запросов. Например, в SimpleDB время выполнение запроса не может превышать 5 секунд, а в Google AppEngine Datastore один запрос к базе не позволяет получить более 1000 записей.

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

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

Выводы

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

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

NoSQL базы данных: хранилища и доступность данных

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

Содержание

  1. СУБД
  2. NoSQL СУБД
    1. Хранилище ключ-значение
    2. Распределённое хранилище
    3. Документо-ориентированная СУБД
    4. БД на основе графов
  3. NoSQL базы данных типа ключ-значение
    1. Популярные БД
    2. Примеры использования


  4. NoSQL базы данных типа столбец
    1. Популярные БД
    2. Примеры использования
  5. NoSQL базы данных типа документ
    1. Популярные БД
    2. Примеры использования
  6. NoSQL базы данных типа граф
    1. Популярные БД
    2. Примеры использования
  7. Сравнение NoSQL и реляционных СУБД

Системы управления базами данных

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

NoSQL системы управления базами данных

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

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

По задумке NoSQL базы данных и СУБД не подразумевают внутренних связей. Они не основываются на одной модели, а каждая база данных в зависимости от целей использует различные модели.

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

  • Хранилище ключ-значение — Redis, MemcacheDB и т.д. (обычно хранят данные в памяти)
  • Распределённое хранилище (Column-oriented) — Cassandra, HBase и т.д (предназначены для очень больших объёмов данных).
  • Документо-ориентированные СУБД — MongoDB, Couchbase и т.д. (предназначены для хранения иерархических структур данных — документов)
  • БД на основе графов — OrientDB, Neo4J и т.д.

Чтобы лучше понять чем отличаются все эти типы СУБД, рассмотрим их.

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

Начнем наше рассмотрение с типа хранилища ключ-значение, так как это самое основное решение из семейства NoSQL. Этот тип БД работает с данными типа ключ-значение, например как словарь. Здесь нет места ни структуре, ни связям. После подключения к серверу (например Redis) приложение может задать ключ и его значение, а в последствии получать эти данныe по запросу.

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

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

Распределённое хранилище

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

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

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

Документо-ориентированные хранилища

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

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

Базы данных на основе графов

На последок мы оставили самое интересное. БД на основе графов хранят данные в совсем другом виде. Они используют древовидные структуры с узлами и связями соединяющими их. Так же как и в математике, некоторые операции гораздо удобнее выполнять с такими данными благодаря связям между ними и их группировке (например, связи между людьми).

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

СУБД Ключ-Значение (Key-Value)

Такие БД очень производительны, просты в обращении и легко масштабируются

Популярные СУБД

Некоторые популярные хранилища:

  • Redis — БД в оперативной памяти с дополнительной отказоустойчивостью
  • Riak — Распределенное, репликационное хранилище
  • Memcached / MemcacheDB — распределённая БД в оперативной памяти

Примеры использования

Часто встречающиеся случаи применения БД хранилищ ключ-значение:

  • Кеширование — быстрое и частое сохранение данных для будущего использования
  • Очередь — некоторые БД типа ключ-значение поддерживают списки, наборы и очереди
  • Распределение информации/задач — используется для реализации паттерна Pub/Sub
  • Живое обновление информации — приложения использующие состояния

NoSQL распределённые СУБД

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

Популярные СУБД

Вот основные представители этого типа БД:

  • Cassandra — структура данных основана на BigTable и DynamoDB
  • HBase — хранилище для Apache Hadoop основанное на принципах BigTable

Примеры использования

Основные области применения:

  • Хранение неструктурированных, не разрушаемых данных — если вам необходимо хранить большие объемы данных в течение долгого времени, то такие БД очень хорошо справятся с задачей
  • Масштабирование — по задумке такие базы данных легко масштабируются. Они легко справляются с любым объемом данных

Документо-ориентированные СУБД

Документ-ориентированные хранилища отлично хранят несвязанную информацию больших объемов, даже если она очень разнится от сущности к сущности.

Популярные СУБД

Часто встречающиеся СУБД:


  • Couchbase — основанное на JSON, совместимое c Memcached хранилище
  • CouchDB — передовое документо-ориентированное хранилище
  • MongoDB — очень популярное и функциональное хранилище

Примеры использования

Часто встречающиеся сферы применения:

  • Вложенная информация — документо-ориентированные хранилища отлично работают с глубоко вложенной, сложной информацией
  • Поддержка JavaScript — одна из отличительных особенностей документо-ориентированных хранилищ это то, как они работают с другими приложениями: поддержка JSON
NoSQL базы данных типа граф

Такие типы БД хранят информацию совершенно особенно, совсем не как все остальные СУБД.

Популярные СУБД

Часто встречаемые СУБД:

  • OrientDB — очень быстрое документо-ориентированное хранилище гибрид типа граф написанное на Java. Включает в себя разные режимы работы
  • Neo4J — безсхемное, очень мощное и популярное хранилище написанное на Java

Примеры использования

Часто встречаемые примеры использования:

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

Сравнение NoSQL СУБД и реляционных СУБД

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

Примеры использования NoSQL

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

Что такое NoSQL?

Высокопроизводительные нереляционные базы данных с гибкими моделями данных

Что такое базы данных NoSQL?

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

Как работает база данных NoSQL (нереляционная БД)?

В базах данных NoSQL для доступа к данным и управления ими применяются различные модели данных, в том числе документная, графовая, поисковая, с использованием пар «ключ‑значение» и хранением данных в памяти. Базы данных таких типов оптимизированы для приложений, которые работают с большим объемом данных, нуждаются в низкой задержке и гибких моделях данных. Все это достигается путем смягчения жестких требований к непротиворечивости данных, характерных для других типов БД.

Рассмотрим пример моделирования схемы для простой базы данных книг.

  • В реляционной базе данных запись о книге часто разделяется на несколько частей (или «нормализуется») и хранится в отдельных таблицах, отношения между которыми определяются ограничениями первичных и внешних ключей. В этом примере в таблице «Книги» имеются столбцы «ISBN», «Название книги» и «Номер издания», в таблице «Авторы» – столбцы «ИД автора» и «Имя автора», а в таблице «Автор–ISBN» – столбцы «Автор» и «ISBN». Реляционная модель создана таким образом, чтобы обеспечить целостность ссылочных данных между таблицами в базе данных. Данные нормализованы для снижения избыточности и в целом оптимизированы для хранения.
  • В базе данных NoSQL запись о книге обычно хранится как документ JSON. Для каждой книги, или элемента, значения «ISBN», «Название книги», «Номер издания», «Имя автора и «ИД автора» хранятся в качестве атрибутов в едином документе. В такой модели данные оптимизированы для интуитивно понятной разработки и горизонтальной масштабируемости.

Для чего можно использовать базы данных NoSQL?

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

  • Гибкость. Как правило, базы данных NoSQL предлагают гибкие схемы, что позволяет осуществлять разработку быстрее и обеспечивает возможность поэтапной реализации. Благодаря использованию гибких моделей данных БД NoSQL хорошо подходят для частично структурированных и неструктурированных данных.
  • Масштабируемость. Базы данных NoSQL рассчитаны на масштабирование с использованием распределенных кластеров аппаратного обеспечения, а не путем добавления дорогих надежных серверов. Некоторые поставщики облачных услуг проводят эти операции в фоновом режиме, обеспечивая полностью управляемый сервис.
  • Высокая производительность. Базы данных NoSQL оптимизированы для конкретных моделей данных (например, документной, графовой или с использованием пар «ключ‑значение») и шаблонов доступа, что позволяет достичь более высокой производительности по сравнению с реляционными базами данных.
  • Широкие функциональные возможности. Базы данных NoSQL предоставляют API и типы данных с широкой функциональностью, которые специально разработаны для соответствующих моделей данных.

Типы баз данных NoSQL

БД на основе пар «ключ‑значение». Базы данных с использованием пар «ключ‑значение» поддерживают высокую разделяемость и обеспечивают беспрецедентное горизонтальное масштабирование, недостижимое при использовании других типов БД. Хорошими примерами использования для баз данных типа «ключ‑значение» являются игровые, рекламные приложения и приложения IoT. Amazon DynamoDB обеспечивает стабильную работу БД с задержкой не более нескольких миллисекунд при любом масштабе. Такая устойчивая производительность послужила основной причиной переноса Snapchat Stories в сервис DynamoDB, поскольку эта возможность Snapchat связана с самой большой нагрузкой на запись в хранилище.

Документ В коде приложения данные часто представлены как объект или документ в формате, подобном JSON, поскольку для разработчиков это эффективная и интуитивная модель данных. Документные базы данных позволяют разработчикам хранить и запрашивать данные в БД с помощью той же документной модели, которую они используют в коде приложения. Гибкий, полуструктурированный, иерархический характер документов и документных баз данных позволяет им развиваться в соответствии с потребностями приложений. Документная модель хорошо работает в каталогах, пользовательских профилях и системах управления контентом, где каждый документ уникален и изменяется со временем. Amazon DocumentDB (совместимая с MongoDB) и MongoDB — распространенные документные базы данных, которые предоставляют функциональные и интуитивно понятные API для гибкой разработки.

Графовые БД. Графовые базы данных упрощают разработку и запуск приложений, работающих с наборами сложносвязанных данных. Типичные примеры использования графовых баз данных – социальные сети, сервисы рекомендаций, системы выявления мошенничества и графы знаний. Amazon Neptune – это полностью управляемый сервис графовых баз данных. Neptune поддерживает модель Property Graph и Resource Description Framework (RDF), предоставляя на выбор два графовых API: TinkerPop и RDF / SPARQL. К числу распространенных графовых БД относятся Neo4j и Giraph.

БД в памяти. Часто в игровых и рекламных приложениях используются таблицы лидеров, хранение сессий и аналитика в реальном времени. Такие возможности требуют отклика в пределах нескольких микросекунд, при этом резкое возрастание трафика возможно в любой момент. Amazon ElastiCache предлагает Memcached и Redis для обработки высокопроизводительных рабочих нагрузок с низкой задержкой, которые нельзя обработать с помощью дисковых хранилищ данных. Такие рабочие нагрузки характерны, например, для сети McDonald’s. Еще одним примером специально разработанного хранилища данных является Amazon DynamoDB Accelerator (DAX). DAX позволяет DynamoDB считывать данные в несколько раз быстрее.

Поисковые БД. Многие приложения формируют журналы, чтобы разработчикам было проще выявлять и устранять неполадки. Amazon Elasticsearch Service (Amazon ES) – специально разработанный сервис для визуализации и аналитики автоматически генерируемых потоков данных в режиме, близком к реальному времени, путем индексирования, агрегации частично структурированных журналов и метрик и поиска по ним. Amazon ES – это также мощная высокопроизводительная поисковая система для полнотекстового поиска. Компания Expedia задействует более 150 доменов Amazon ES, 30 ТБ данных и 30 миллиардов документов для разнообразных особо важных примеров использования – от операционного мониторинга и устранения неисправностей до отслеживания стека распределенных приложений и оптимизации затрат.

Сравнение баз данных SQL (реляционных) и NoSQL (нереляционных)

В течение десятилетий центральное место в разработке приложений занимала реляционная модель данных, которая использовалась в реляционных базах данных, таких как Oracle, DB2, SQL Server, MySQL и PostgreSQL. Но в середине – конце 2000‑х годов заметное распространение стали получать и другие модели данных. Для обозначения появившихся классов БД и моделей данных был введен термин «NoSQL». Часто «NoSQL» используется в качестве синонима к термину «нереляционный».

Существует множество типов БД NoSQL с различными особенностями, но в таблице ниже приведены основные отличия баз данных NoSQL от SQL.

Подходящие рабочие нагрузки

Реляционная модель нормализует данные и преобразует их в таблицы, состоящие из строк и столбцов. Схема жестко задает таблицы, строки, столбцы, индексы, отношения между таблицами и прочие элементы базы данных. Такая БД обеспечивает целостность ссылочных данных в отношениях между таблицами.

Реляционные базы данных обеспечивают набор свойств ACID: атомарность, непротиворечивость, изолированность, надежность.

  • Атомарность требует, чтобы транзакция выполнялась полностью или не выполнялась вообще.
  • Непротиворечивость означает, что сразу по завершении транзакции данные должны соответствовать схеме базы данных.
  • Изолированность требует, чтобы параллельные транзакции выполнялись отдельно друг от друга.
  • Надежность подразумевает способность восстанавливаться до последнего сохраненного состояния после непредвиденного сбоя в системе или перебоя в подаче питания.
Реляционные базы данных Базы данных NoSQL
Реляционные БД предназначены для транзакционных и строго непротиворечивых приложений обработки транзакций в режиме реального времени (OLTP) и хорошо подходят для аналитической обработки в режиме реального времени (OLAP). Базы данных NoSQL (на основе пар «ключ‑значение», документные, графовые и работающие в памяти) ориентированы на OLTP для целого ряда шаблонов доступа к данным, в том числе для приложений с низкой задержкой. Поисковые БД NoSQL предназначены для аналитики частично структурированных данных.
Модель данных В базах данных NoSQL применяются различные модели данных, в том числе документные, графовые, поисковые, с использованием пар «ключ‑значение» и хранением данных в памяти.
Свойства ACID Базы данных NoSQL зачастую предлагают компромисс, смягчая жесткие требования свойств ACID ради более гибкой модели данных, которая допускает горизонтальное масштабирование. Благодаря этому БД NoSQL – отличный выбор для примеров использования с высокой пропускной способностью и низкой задержкой, в которых требуется горизонтальное масштабирование, не ограниченное рамками одного инстанса.
Производительность Производительность главным образом зависит от дисковой подсистемы. Для обеспечения максимальной производительности часто требуется оптимизация запросов, индексов и структуры таблицы. Производительность обычно зависит от размера кластера базового аппаратного обеспечения, задержки сети и вызывающего приложения.
Масштабирование Реляционные базы данных обычно масштабируются путем увеличения вычислительных возможностей аппаратного обеспечения или добавления отдельных копий для рабочих нагрузок чтения. Базы данных NoSQL обычно поддерживают высокую разделяемость благодаря шаблонам доступа на основе пар «ключ‑значение» с возможностью масштабирования на основе распределенной архитектуры. Это повышает пропускную способность и обеспечивает устойчивую производительность почти в неограниченных масштабах.
API Запросы на запись и извлечение данных составляются на языке SQL. Эти запросы анализирует и выполняет реляционная база данных. Объектно‑ориентированные API позволяют разработчикам приложений без труда осуществлять запись и извлечение структур данных, размещенных в памяти. Благодаря использованию ключей секций приложения могут вести поиск по парам «ключ‑значение», наборам столбцов или частично структурированным документам, содержащим серийные объекты и атрибуты приложений.

Сравнение терминологии SQL и NoSQL

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

NoSQL базы данных.

Чтобы просмотреть это видео, включите JavaScript и используйте веб-браузер, который поддерживает видео в формате HTML5

Базы данных (Databases)

Half Faded Star

Курс знакомит слушателей с основными принципами работы со структурированными данными в реляционной модели, учит проектировать данные, описывать объекты базы данных в терминах реальной СУБД, составлять запросы на языке SQL, использовать представления, процедуры, функции и триггеры, создавать индексы, управлять конкурентным доступом к данным и манипулировать механизмом транзакций. Основу курса составляют изучение и применение языка SQL для создания, модификации объектов баз данных и управления данными в произвольной реляционной базе данных. Выполнение практических задач в рамках курса предполагает использование СУБД My SQL. В курсе рассматриваются этапы проектирования реляционных баз данных, правила составления запросов, основные методы индексирования данных. В курсе будут изучены вопросы использования транзакций и прав доступа к данным. Также курс дает обзор современных тенденций в области науки о данных в связи с появлением BigData. В заключении курса будут показаны сферы применения NoSQL баз данных и указаны современные подходы к обработке big data.

Получаемые навыки

Big Data, Database (DBMS), MySQL, SQL

Рецензии

Half Faded Star

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

Преподаватели

Михайлова Елена

Текст видео

[МУЗЫКА] [МУЗЫКА] На волне появления больших данных стали разрабатываться специализированные системы, которые получили название NoSQL, что расшифровывается как Not Only SQL. Автором этого термина является Йохан Оскарсон, который использовал его на конференции по нереляционным базам данных в 2009 году. Этот термин используется в качестве главной классификации, подразумевающей большое количество разнообразных хранилищ данных, многие из которых основаны на нереляционной модели, а имеют узко ориентированную, специфическую модель, заточенную на хранение определённого вида данных. Какими основными характеристиками обладают эти системы, хотя они, конечно, очень разнообразны? В первую очередь, это простые и гибкие нереляционные модели, предназначенные для решения специфических задач. Эти модели поддерживают масштабирование по горизонтали — что это такое? Обычно реляционные СУБД часто используют вертикальное масштабирование. Представим, что у нас есть очень большая таблица. Она может быть разделена на некоторые партиции, или части, и каждая из этих частей может храниться на отдельном устройстве хранения. NoSQL-ные системы часто используют другой вид масштабирования — по горизонтали, когда они отдельно хранят не строки таблицы, а целые столбцы. Также NoSQL-ные системы позиционируют себя как обеспечивающие высокую степень доступности данных. Продекларированные ими принципы формулируются так: BASE-принципы: Basically Available, Soft state, Eventually consistent. Что это за принципы? Basically Available означает, что данные доступны всегда, когда к ним происходит обращение. И даже если часть данных, которая должна быть подвергнута обработке, недоступна, то ответ будет сгенерирован путём обработки доступной части информации. Приведём пример. Например, вам захочется увидеть, как выглядит собака породы шпиц; для этого вам не нужно получить всё множество фотографий с этой породой собаки, вам достаточно лишь какого-то небольшого набора. Soft state: данные могут в процессе обработки находиться в рассогласованном состоянии, и в этот момент их могут увидеть пользователи, но следующий принцип, Eventually consistent, гарантирует нам, что в конечном счёте, после некоторого периода времени, данные будут приведены в согласованное состояние. Для большого количества NoSQL-ных систем используется технология распараллеливания, про которую мы уже говорили, под названием MapReduce. Основное преимущество этой технологии — продолжить обработку данных даже в случае отказа оборудования на некоторых узлах. Особенно эффективно эта система работает, когда абсолютная точность ответа нам не нужна. Принято подразделять NoSQL-ные СУБД на четыре вида. Это хранилища типа «ключ-значение», документные хранилища, колоночные хранилища и граф-ориентированные модели. Для того чтобы найти наиболее популярных представителей каждого класса моделей, можно воспользоваться рейтингом. Один из рейтингов вы видите на экране. На этом рейтинге приведены оценки по некоторым формальным критериям реально существующих СУБД для каждого вида NoSQL-ных моделей. Первое, что мы рассмотрим, это хранилище типа «ключ-значение». Наиболее популярных представителей вы видите на экране. Назовём основные характеристики системы типа «ключ-значение». Во-первых, они могут легко масштабироваться, они обеспечивают нам эффективный поиск по значению ключа, ключом обладает каждый элемент хранимых данных. При этом объекты, которые мы храним в такой модели, могут иметь достаточно сложную структуру. Разработчики таких систем декларируют их высокую производительность. Надо отметить в качестве недостатка таких систем, что в них полностью отсутствует возможность связи между объектами, которую мы привыкли использовать в реляционной модели. И, соответственно, проверка целостности в базе данных переносится на плечи отдельного пользователя или приложения, работающего с данными. Этот класс приложений может быть эффективно использован для определённого круга задач, например, для хранения изображений, видеороликов, файлов программы и так далее. Следующий вид систем — это документные хранилища. Наиболее популярными из них являются MongoDB и Amazon. Как они устроены? Они хранят объекты в специализированном формате, который называется JSON, — это Java Script Object Notation, или BSON — Binary JSON. Рассмотрим, как устроено хранение таких объектов. Строка JSON содержит либо массив значений, либо объект, содержащий неупорядоченное множество пар «ключ-значение». Массив заключается в квадратные скобки, объект — в фигурные скобки, сами элементы разделяются запятыми. Пара имя/значение состоит из имени поля, заключённого в кавычки, после него ставится двоеточие, и приводится само значение. Значение в массиве или объекта может быть числом, строкой, а может иметь уровни вложенности, то есть содержать вложенные массивы или объекты. Приведём пример, как можно было бы хранить информацию о студенте из нашей демонстрационной базы на примере JSON. Мы видим, что у каждого студента хранится его идентификатор в виде номера зачётки, фамилия, имя, отчество, номер группы. Также он содержит вложенный массив, состоящий из телефонов. Для каждого телефона мы храним тип телефона и его номер. Основные характеристики документных хранилищ заключаются в том, что они позволяют атрибуты простых типов, а также вложенные объекты; можно строить индексы по отдельным полям таких документов, что позволяет нам строить достаточно сложные запросы. Надо отметить, что такие структуры не поддерживают основные принципы транзакций, характерных для реляционных СУБД, однако обработка каждого отдельного документа обычно является атомарной. И такие системы могут эффективно применяться в системах управления контентом, в издательском деле, в документном поиске и так далее. Колоночные хранилища. Колоночные хранилища основаны на представлении данных в виде таблиц, и дробление таблицы происходит не за счёт деления по строкам, как принято в обычных реляционных СУБД, а по столбцам. Для многих систем этого класса характерно наличие SQL-подобных языков достаточно высокого уровня. Последние представители класса NoSQL-ных систем — это граф-ориентированные хранилища. Их имена вы сейчас видите на экране. Надо отметить, что они предназначены для хранения узлов связи и могут удобно представлять связи между ними. Большинство таких систем позволяет задавать узлы и связывать между произвольным набором атрибутов, и мы можем выбирать узлы и связи, задавая значения этих атрибутов. Они поддерживают всевозможные алгоритмы обхода графов и построения маршрутов и эффективно используются для задач, связанных с анализом, например, социальных сетей, выбором транспортного маршрута и так далее. На этом мы закончили рассмотрение NoSQL-ных систем.

Мастер Йода рекомендует:  10 советов как подтянуть разговорный английский язык
Добавить комментарий