Многомодельная база данных - Multi-model database

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

Фон

В реляционный модель данных стала популярной после ее публикации Эдгар Ф. Кодд в 1970 году. В связи с повышением требований к горизонтальная масштабируемость и Отказоустойчивость, NoSQL базы данных стали заметными после 2009 года. Базы данных NoSQL используют различные модели данных, с документ, график, а также популярны модели "ключ-значение".[2]

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

В течение некоторого времени было почти забыто (или считалось несущественным), что существуют другие модели баз данных, кроме реляционных. Реляционная модель и понятие третья нормальная форма де-факто были стандартом для хранения всех данных. Однако до преобладания реляционного моделирования данных примерно с 1980 по 2005 гг. иерархическая модель базы данных широко использовался, и с 2000 или 2010 года многие NoSQL Нереляционные модели, включая Документы, тройки, хранилища ключей и значений, популярны. Возможно, геопространственные данные, временные данные и текстовые данные также являются отдельными моделями, хотя индексированные, запрашиваемые текстовые данные обычно называются "поисковый движок "а не базу данных.

Впервые слово «многомодель» было связано с базами данных 30 мая 2012 года в Кельне, Германия, во время ключевого выступления Луки Гарулли »Принятие NoSQL - что делать дальше?".[3][4] Лука Гарулли предвидел эволюцию продуктов NoSQL 1-го поколения в новые продукты с большим количеством функций, которые можно использовать в различных сценариях использования.

Идея многомодельных баз данных восходит к Объектно-реляционные системы управления данными (ORDBMS) в начале 1990-х и в более широком масштабе даже до федеративных и интегрированных СУБД в начале 1980-х. Система ORDBMS управляет различными типами данных, такими как реляционные, объектные, текстовые и пространственные, путем добавления в ядра СУБД типов данных, функций и реализаций индексов, специфичных для предметной области. Многомодельная база данных является прямым ответом на "настойчивость полиглота «подход к объединению нескольких продуктов баз данных, каждый из которых использует свою модель, для достижения возможности создания нескольких моделей, как описано Мартином Фаулером.[5] Эта стратегия имеет два основных недостатка: она приводит к значительному увеличению операционной сложности, и отсутствует поддержка для поддержания согласованности данных в отдельных хранилищах данных, поэтому многомодельные базы данных начали заполнять этот пробел.

Многомодельные базы данных предназначены для того, чтобы предложить преимущества моделирования данных, связанные с постоянством полиглотов,[5] без его недостатков. Сложность эксплуатации, в частности, снижается за счет использования единого хранилища данных.[2]

Базы данных

Основная статья: Сравнение многомодельных баз данных

Многомодельные базы данных включают (в алфавитном порядке):

  • АллегроГраф - документ (JSON, JSON-LD), график
  • ArangoDB - документ (JSON), график, пара "ключ-значение"
  • Cosmos DB - документ (JSON), график,[6] ключ-значение, SQL
  • Диван - документ (JSON), ключ-значение, N1QL
  • Datastax - пары "ключ-значение", таблица, график
  • EnterpriseDB - документ (XML и JSON), ключ-значение
  • MarkLogic - документ (XML и JSON), хранилище троек, двоичный, SQL
  • MongoDB - документ (XML и JSON), график, ключ-значение, временной ряд
  • База данных Oracle - реляционный, документ (JSON и XML), хранилище троек графа, граф свойств, ключ-значение, объекты
  • OrientDB - документ (JSON), график, ключ-значение, реактивный, SQL
  • Redis - ключ-значение, документ (JSON), граф свойств, потоковая передача, временной ряд
  • SAP HANA - реляционный, документ (JSON), граф, потоковая передача
  • Виртуозный универсальный сервер -- реляционный, документ (XML ), Графики RDF

Бенчмаркинг многомодельных баз данных

Поскольку для работы с многомодельными данными предлагается все больше и больше платформ, есть несколько работ по сравнительному анализу многомодельных баз данных. Например, Плюценник,[7] Оливейра,[8] и UniBench[9] проанализировал существующие многомодельные базы данных и предпринял попытку оценить многомодельные базы данных и другие базы данных SQL и NoSQL соответственно. Они отметили, что преимущества многомодельных баз данных по сравнению с одномодельными базами данных заключаются в следующем: (i) они могут принимать в хранилище различные форматы данных, такие как CSV (включая Graph, Relational), JSON, без каких-либо дополнительных усилий. , (ii) они могут использовать унифицированный язык запросов, такой как AQL, Orient SQL, SQL / XML, SQL / JSON, для извлечения коррелированных многомодельных данных, таких как граф-ключ / значение JSON, реляционный XML и JSON- реляционные на единой платформе. (iii) они могут поддерживать многомодельные транзакции ACID в автономном режиме.

Архитектура

Основное различие между доступными многомодельными базами данных связано с их архитектурами. Многомодельные базы данных могут поддерживать разные модели либо внутри движка, либо через разные уровни поверх движка. Некоторые продукты могут предоставлять механизм, который поддерживает документы и графики, в то время как другие предоставляют слои поверх хранилища ключей.[10] В многоуровневой архитектуре каждая модель данных предоставляется через свою собственную компонент.

Пользовательские модели данных

Помимо предложения нескольких моделей данных в одном хранилище данных, некоторые базы данных позволяют разработчикам легко определять пользовательские модели данных. Эта возможность обеспечивается транзакциями ACID с высокой производительностью и масштабируемостью. Чтобы настраиваемая модель данных поддерживала одновременные обновления, база данных должна иметь возможность синхронизировать обновления по нескольким ключам. Транзакции ACID, если они достаточно эффективны, допускают такую ​​синхронизацию.[11] Документы JSON, графики и реляционные таблицы могут быть реализованы способом, который наследует горизонтальную масштабируемость и отказоустойчивость базового хранилища данных.

Смотрите также

Рекомендации

  1. ^ Группа 451, «Ни рыба, ни птица: рост многомодельных баз данных»
  2. ^ а б Infoworld, "Развитие многомодельной базы данных"
  3. ^ «Мультимодельное хранилище 1/2 одного продукта». 2012-06-01.
  4. ^ "Конференция по Nosql Matters 2012 | NoSQL Matters CGN 2012" (PDF). 2012.nosql-matters.org. Получено 2017-01-12.
  5. ^ а б Устойчивость полиглота
  6. ^ https://docs.microsoft.com/en-us/azure/cosmos-db/create-graph-dotnet
  7. ^ Ева Плуценник и Камиль Згоржалек. «Многомодельные базы данных - обзор». Bdas 2017: 141–152.
  8. ^ Фабио Роберто Оливейра, Луис дель Валь Кура. «Оценка производительности хранилищ многомодельных данных NoSQL в приложениях с сохраняемостью Polyglot». Идеи '16: 230–235.
  9. ^ Чао Чжан, Цзяхэн Лу, Пэнфэй Сюй, Юсин Чен. «UniBench: эталон для многомодельных систем управления базами данных» (PDF). TPCTC 2018.CS1 maint: несколько имен: список авторов (связь)
  10. ^ "слой"
  11. ^ ODBMS, "Постоянство полиглотов или множественные модели данных?"

внешняя ссылка