Мультимодельные базы данных

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 15:54, 19 ноября 2017.

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

Развитие

Эволюция данных от централизованного до радикально распределенного развертывания данных.

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

Первоначально идея сохранения многогранности возникла из-за необходимости разделить разные рабочие нагрузки на управление данными, чтобы не было конкуренции за данные или вычислительные ресурсы между системами, предназначенными для транзакций, аналитики, поиска и других рабочих нагрузок. Это началось с того, что различные приложения предназначались для отдельных хранилищ данных, что было хорошо для старых приложений. Однако облачные приложения требовали, чтобы база данных развивалась для консолидации рабочих нагрузок на единой платформе для поддержки идей аналитической обработки гибридных транзакций (HTAP), также упоминаемых другими именами, такими как «translytics».

Третье изменение напоминает второе, но включает в себя разные модели данных и рабочие нагрузки. Прогресс начался преимущественно с модели данных RDBMS (Relational DataBase Management System), перемещающейся в смесь разных технологий и моделей данных, чтобы теперь создать единую платформу, способную поддерживать несколько моделей данных против одного интегрированного бэкэнда.

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

Бэкграунд

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

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

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

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

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

Некоторые истории сложнейших систем от ненужной интеграции «frankenbeans» находятся в Интернете.

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

Базы данных

Примеры мультимодельных баз данных:

  • ArangoDB – документ (JSON), граф, хранилище ключей
  • Cosmos DB - документ, таблица, хранилище ключей, JSON, SQL
  • CouchBase – документ(JSON), хранилище ключей
  • CrateDB – реляционные (SQL), документ (Lucene)
  • Datastax – хранилище ключей, табличные, граф
  • EnterpriseDB – документ (XML and JSON), хранилище ключей
  • MarkLogic – документ (XML and JSON), граф (RDF with OWL/RDFS), текст, геопространственные, двоичные, SQL
  • Oracle Database – реляционныеl (SQL), документ (JSON), граф (RDF with OWL, RDFS, SPARQL), граф (Blueprints APIs, Gremlin, PGQL, traversal and analytics), хранилище ключей, XML , текст, геопространственные, двоичные
  • OrientDB – документ (JSON), граф, хранилище ключей, текст, геопространственные, двоичные, SQL.

Архитектура

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

От РСУБД до NoSQL до мультимодели

В экосистеме РСУБД представлены несколько ключевых характеристик, таких как: агностический стандартный язык поставщика для разработчиков (SQL); четкое разделение между логическими (разработчиками) и физическими (DBA) аспектами СУБД; и сплоченный набор механизмов на разных языках (драйверах), с помощью которых приложения могут взаимодействовать с базами данных. Это позволяет предприятиям внедрять технологии инфраструктуры данных, не беспокоясь о блокировке поставщика.

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

  • Архитектура master-slave, требует уступки в отношении времени безотказной работы и отказоустойчивости
  • Масштабирование и запись и распределение ограничений для рабочих облачных приложений
  • Строгое соблюдение конструкций логического уровня данных, таких как третья нормальная форма (3NF), которые оценивают эффективность хранения больше, чем гибкость приложения
  • Жесткая модель данных, которая делает использование полу- и неструктурированных данных чрезвычайно дорогостоящей в масштабировании
  • Облицовочная архитектурная «Band-Aid», которая увеличивает операционные расходы экспоненциально

Хотя некоторые технологии NoSQL, такие как Apache Cassandra ™, затрагивают ранее упомянутые проблемы экосистемы РСУБД, движение NoSQL создало фрагментированное технологическое предложение для корпоративных клиентов из-за двух проблем, рассмотренных ниже.

Во-первых, постоянство мультимодели подразумевало, что клиенты либо используют ограниченный набор одной из моделей (Key Value, Tabular, JSON, Graph), либо выполняют операции экстракции-преобразования-нагрузки в хранилищах данных.

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

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

  • Поддержка более чем одной постреляционной модели данных (например, табличного, JSON, графа) на логическом уровне для упрощения разработки для разработчиков приложений
  • Обеспечьте, чтобы все модели были открыты через когезионные механизмы, тем самым избегая когнитивного контекстного переключения для разработчиков
  • Единый слой сохранения, который обеспечивает гео-избыточные, постоянно доступные характеристики и общую структуру для операционных аспектов, таких как безопасность, предоставление ресурсов, аварийное восстановление и т. д.
  • Расширение возможностей использования различных случаев использования OLTP и OLAP-рабочих нагрузок для предприятий бизнеса в рамках предприятия для инноваций с маневренностью
  • Лучше всего обеспечить эффективность ТШО в долгосрочной перспективе, чтобы обеспечить более широкое внедрение в централизованных ИТ-подразделениях организации

Ключевые и табличные значения

Это простейшая модель. Все в базе данных может быть достигнуто ключом, где значения могут быть простыми и сложными типами. Поддерживаются документы и элементы графа как значения, позволяющие использовать более богатую модель, чем то, что обычно включается в классическую модель ключ/значение. Классическая модель ключ/значение предоставляет «ведра» для группировки пар ключ/значение в разных контейнерах.

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

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

JSON/Документ

Данные в этой модели хранятся внутри документов. Документ представляет собой набор пар ключ / значение (также называемых полями или свойствами), где ключ позволяет получить доступ к его значению. Значения могут содержать примитивные типы данных, встроенные документы или массивы других значений. Документы обычно не заставляют иметь схему, которая может быть выгодной, поскольку они остаются гибкими и легко изменяются. Документы хранятся в коллекциях, что позволяет разработчикам группировать данные по мере их принятия. Поддержка модели JSON/Document позволяет гибко хранить данные со сложными вложенными схемами и может легко перемещать данные в уровни приложений и из них - оба из них являются основными примерами использования популярных баз данных, ориентированных на документы.

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

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

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

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

Граф

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

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

Объектная модель

Эта модель была унаследована объектно-ориентированным программированием и поддерживает наследование между типами (подтипы расширяет супертипы), полиморфизм, когда вы ссылаетесь на базовый класс и прямое связывание с/на объекты, используемые в языках программирования.

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

Поскольку данные из всех моделей хранятся в одном бэкэнд, каждая модель данных несет свои преимущества преимущества:

  • Непрерывная доступность
  • Простое географическое распределение данных
  • Оперативная низкая латентность
  • Линейная масштабируемость
  • Операционная завершенность
  • Упрощенная разработка

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

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

См. также

Ссылки