1. Главная страница » Компьютеры » Nosql базы данных примеры

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

Автор: | 16.12.2019

Содержание

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.

Читайте также:  Jbl charge 2 характеристики китайская

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

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

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

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

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

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

Содержание

Происхождение [ править | править код ]

История названия [ править | править код ]

Изначально слово NoSQL являлось акронимом из двух слов английского языка: No («Не») и SQL (сокращение от англ. Structured Query Language — «структурированный язык запросов»), что даёт термину смысл «отрицающий SQL». Возможно, что первые, кто стал употреблять этот термин, хотели сказать «No RDBMS» («не реляционная СУБД») или «no relational» («не реляционный»), но NoSQL звучало лучше и в итоге прижилось (в качестве альтернативы предлагалось также NonRel). Позднее для NoSQL было придумано объяснение «Not Only SQL» («не только SQL»). NoSQL стал общим термином для различных баз данных и хранилищ, но он не обозначает какую-либо одну конкретную технологию или продукт [2] .

Развитие идеи [ править | править код ]

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

В начале 2000-х годов Google построил свою высокомасштабируемую поисковую систему и приложения: GMail, Google Maps, Google Earth и т. п., решая проблемы масштабируемости и параллельной обработки больших объёмов данных. В результате была создана распределённая файловая система и распределённая система координации, хранилище семейств колонок (англ. column family store ), среда выполнения, основанная на алгоритме MapReduce. Публикация компанией Google описаний этих технологий привела к всплеску интереса среди разработчиков открытого программного обеспечения, в результате чего был создан Hadoop и запущены связанные с ним проекты, призванные создать подобные Google технологии. Через год, в 2007 году, примеру Google последовал Amazon.com, опубликовав статьи о высокодоступной базе данных Amazon DynamoDB [3] .

Поддержка гигантов индустрии менее чем за пять лет привела к широкому распространению технологий NoSQL (и подобных) для управления «большими данными», а к делу присоединились другие большие и маленькие компании, такие как: IBM, Facebook, Netflix, eBay, Hulu, Yahoo!, со своими проприетарными и открытыми решениями [3] .

Основные черты [ править | править код ]

Традиционные СУБД ориентируются на требования AC >atomicity ), согласованность (англ. consistency ), изолированность (англ. isolation ), надёжность (англ. durability ), тогда как в NoSQL вместо AC >[1] :

  • базовая доступность (англ. basic availability ) — каждый запрос гарантированно завершается (успешно или безуспешно).
  • гибкое состояние (англ. soft state ) — состояние системы может изменяться со временем, даже без ввода новых данных, для достижения согласования данных.
  • согласованность в конечном счёте (англ. eventual consistency ) — данные могут быть некоторое время рассогласованы, но приходят к согласованию через некоторое время.

Термин «BASE» был предложен Эриком Брюером, автором теоремы CAP, согласно которой в распределённых вычислениях можно обеспечить только два из трёх свойств: согласованность данных, доступность или устойчивость к разделению [1] .

Разумеется, системы на основе BASE не могут использоваться в любых приложениях: для функционирования биржевых и банковских систем использование транзакций является необходимостью. В то же время, свойства AC >[1] . Таким образом, проектировщики NoSQL-систем жертвуют согласованностью данных ради достижения двух других свойств из теоремы CAP [4] . Некоторые СУБД, например, Riak, позволяют настраивать требуемые характеристики доступности-согласованности даже для отдельных запросов путём задания количества узлов, необходимых для подтверждения успеха транзакции. [5]

Решения NoSQL отличаются не только проектированием с учётом масштабирования. Другими характерными чертами NoSQL-решений являются [6] [7] :

  • Применение различных типов хранилищ [6] .
  • Возможность разработки базы данных без задания схемы[6][7] .
  • Линейная масштабируемость (добавление процессоров увеличивает производительность) [6] .
  • Инновационность: «не только SQL» открывает много возможностей для хранения и обработки данных [6] .

Типы систем [ править | править код ]

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

В зависимости от модели данных и подходов к распределённости и репликации в NoSQL-движении выделяются четыре основных типа систем: «ключ — значение» (англ. key-value store ), документоориентированные ( document store ), «семейство столбцов» ( column-family store ), графовые.

Ключ — значение [ править | править код ]

Модель «ключ — значение» является простейшим вариантом, использующим ключ для доступа к значению. Такие системы используются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в системах, спроектированных с прицелом на масштабируемость. Примеры таких хранилищ — Berkeley DB, MemcacheDB [en] , Redis, Riak, Amazon DynamoDB [6] .

Читайте также:  Hard disk windows boot manager

Семейство столбцов [ править | править код ]

Другой тип систем — «семейство столбцов», прародитель этого типа — система Google BigTable. В таких системах данные хранятся в виде разреженной матрицы, строки и столбцы которой используются как ключи. Типичным применением этого типа СУБД является веб-индексирование, а также задачи, связанные с большими данными, с пониженными требованиями к согласованности. Примерами СУБД данного типа являются: Apache HBase, Apache Cassandra, ScyllaDB [en] , Apache Accumulo [en] , Hypertable [en] [6] [8] .

Системы типа «семейство столбцов» и документно-ориентированные системы имеют близкие сценарии использования: системы управления содержимым, блоги, регистрация событий. Использование временных меток позволяет использовать этот вид систем для организации счётчиков, а также регистрации и обработки различных данных, связанных со временем [8] .

В отличие от столбцового хранения (англ. column-oriented DBMS ), применяемого в некоторых реляционных СУБД, хранящих данные по столбцам в сжатом виде, в связи с чем эффективные для OLAP-сценариев, модель «семейство столбцов» хранит данные построчно, и обеспечивает высокую производительность, прежде всего, в оперативных сценариях, тогда как для запросов, требующих обхода большого объёма данных с агрегацией результатов, как правило, неэффективна [8] [9] .

Документоориентированная СУБД [ править | править код ]

Документоориентированные СУБД служат для хранения иерархических структур данных. Находят своё применение в системах управления содержимым, издательском деле, документальном поиске. Примеры СУБД данного типа — CouchDB, Couchbase, MongoDB, eXist, Berkeley DB XML [6] .

Графовая СУБД [ править | править код ]

Графовые СУБД применяются для задач, в которых данные имеют большое количество связей, например, социальные сети, выявление мошенничества. Примеры: Neo4j, OrientDB, AllegroGraph [en] , Blazegraph [10] , InfiniteGraph, FlockDB, Titan [6] [8] .

Так как рёбра графа материализованы (англ. materialized ), то есть, являются хранимыми, обход графа не требует дополнительных вычислений (как соединение в SQL), но для нахождения начальной вершины обхода требуется наличие индексов. Графовые СУБД как правило поддерживают AC >GraphQL [en] .

UnQL [ править | править код ]

В июле 2011 компания Couchbase, разработчик CouchDB, Memcached и Membase, анонсировала создание нового SQL-подобного языка запросов — UnQL (Unstructured Data Query Language). Работы по созданию нового языка выполнили создатель SQLite Ричард Гипп (англ. Richard Hipp ) и основатель проекта CouchDB Дэмиен Кац (англ. Damien Katz ). Разработка передана сообществу на правах общественного достояния [11] [12] [13] .

В этой статье мы познакомимся с разными типами NoSQL СУБД.

Всего есть 4 основных типа:

  1. Хранилище «ключ-значение» — в нём есть большая хеш-таблица, содержащая ключи и значения. Примеры: Riak, Amazon DynamoDB;
  2. Документоориентированное хранилище — хранит документы, состоящие из тегированных элементов. Пример: CouchDB;
  3. Колоночное хранилище — в каждом блоке хранятся данные только из одной колонки. Примеры: HBase, Cassandra;
  4. Хранилище на основе графов — сетевая база данных, которая использует узлы и рёбра для отображения и хранения данных. Пример: Neo4J.

База данных типа «ключ-значение»

Отсутствие схемы в базах данных «ключ-значение», например, Riak, — это как раз то, что вам нужно для хранения данных. Ключ может быть синтетическим или автосгенерированным, а значение может быть представлено строкой, JSON, блобом (BLOB, Binary Large Object, большой двоичный объект) и т.д.

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

«КРОК», Москва, Санкт-Петербург, Троицк, Челябинск, Воронеж, Иркутск, Краснодар, Нижний Новгород, Самара, Пермь, от 120 000 до 240 000 ₽

Производительность сильно вырастает за счёт кеширующих механизмов, которые работают на основе маппингов. Чтобы прочитать значение, вам нужно знать как ключ, так и блок, поскольку на самом деле ключ является хешем (блок + ключ).

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

Если поразмыслить о теореме CAP, то становится довольно очевидно, что такие хранилища хороши в плане доступности (Availability) и устойчивости к разделению (Partition tolerance), но явно проигрывают в согласованности данных (Consistency).

Пример: посмотрим на набор данных, представленных таблицей ниже. Здесь ключ — это название страны, а значение — список адресов в этой стране:

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

  • Get(key) возвращает значение, связанное с переданным ключом;
  • Put(key, value) связывает значение с ключом;
  • Multi-get(key1, key2, . keyN) возвращает список значений, связанных с переданным ключами;
  • Delete(key) удаляет запись для ключа из хранилища.

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

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

Riak и Dynamo от Amazon — самые популярные СУБД данных такого типа.

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

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

Читайте также:  Finereader внутренняя программная ошибка 142

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

Одним из ключевых различий между хранилищем «ключ-значение» и документоориентированным является то, что последний включает метаданные, связанные с хранимым содержимым, что даёт возможность делать запросы на основе содержимого. Например, в указанном примере можно попробовать найти все документы, в которых «City» равно «Noida», что вернёт все документы, связанные с магазинами в этом городе.

Apache CouchDB — пример документоориентированной СУБД. CouchDB использует JSON для хранения данных, JavaScript в качестве языка запросов с использованием MapReduce и HTTP для API. Данные и отношения не хранятся в таблицах так, как в традиционных реляционных базах данных, а по сути являются набором независимых документов.

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

Couchbase и MongoDB — самые популярные документоориентированные СУБД.

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

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

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

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

  • Колоночное семейство — структура, которая может легко группировать колонки и суперколонки;
  • Ключ — постоянное имя записи. У ключей может быть разное количество колонок, поэтому база данных может расширяться неравномерно;
  • Пространство ключей — определяет самый внешний уровень организации, как правило, имя приложения/базы данных.
  • Колонка — имеет упорядоченный список элементов — кортежей с именами и значениями.

Самыми известными примерами являются Google BigTable и HBase с Cassandra, вдохновлённые BigTable.

BigTable представляет собой высокопроизводительное, сжатое и проприетарное хранилище данных от Google. У него есть следующие атрибуты:

  • Разреженность — некоторые ячейки могут быть пустыми;
  • Распределённость — данные разделены между многими узлами;
  • Постоянство — хранится на диске;
  • Многомерность — более 1 измерения;
  • Сопоставление — ключ и значение;
  • Отсортированность — сопоставления обычно не сортируются, но этот случай — исключение.

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

Эту таблицу можно представить в виде BigTable-сопоставления следующим образом:

  • Внешние ключи «3PillarNoida», «3PillarCluj», «3PillarTimisoara» и «3PillarFairfax» являются аналогами строк.
  • «address» и «details» — колоночные семейства.
  • В колоночном семействе «address» есть колонки «city» и «pincode».
  • В колоночном семействе «details» есть колонки «strength» и «projects».

На колонки можно ссылаться с помощью колоночного семейства.

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

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

  • Такие базы данных используют рёбра и узлы для представления данных.
  • Узлы связаны между собой определённым отношениями, представленными рёбрами между ними.
  • У узлов и отношений есть некоторые свойства.

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

Далее описаны некоторые особенности графовой базы данных на основе примера ниже:

Помеченный, направленный, атрибутированный мультиграф: граф содержит узлы, которые помечены определёнными свойствами и которые имеют связи друг с другом, что представлено направленными рёбрами. Например, связь «Элис знает Боба» выражена ребром с некоторыми свойствами.

Хотя реляционные базы данных могут скопировать поведение графовых, рёбрам потребуется соединение (JOIN), что дорого обойдётся.

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

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

InfoGrid и Infinite Graph — самые популярные графовые базы данных. InfoGrid позволяет соединять множество рёбер (Relationships) и узлов (MeshObjects), что упрощает представление набора информации со сложными взаимными ссылками.

InfoGrid предлагает два типа баз данных:

  • MeshBase — подходящий вариант для автономного развёртывания;
  • NetMeshBase — подойдёт для больших распределённых графов и имеет дополнительные возможности для взаимодействия с другими похожими NetMeshBase.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *