Сравнение баз данных OrientDB и MongoDB

OrientDB и MongoDB имеют много общего, однако механизмы их работы все же отличаются. MongoDB — документо-ориентированная база данных, тогда как OrientDB oбъeдиняeт в сeбe вoзмoжнoсти дoкумeнтo-oриeнтирoвaннoй и грaфo-oриeнтирoвaннoй БД. Здесь мы рассмотрим ключевые различия между MongoDB и OrientDB.

Взаимосвязи

Это пример JSON-документа. Обратите внимание на свойство customer внутри родительского объекта Order. Включение в документ всех необходимых атрибутов часто применяют в документо-ориентированных базах данных для преодоления узких мест в производительности реляционных СУБД при выполнении операции JOIN (объединение данных из разных таблиц по ключу).

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

Иллюстрация справа показывает, как оригинал документа был разделен на два документа, связанных с использованием клиентского ID #8:124, чтобы соединить документ Customer c Order.

Почему документы связывают вместо того, чтобы встроить их?

  • Нет повторов: как следствие, база данных меньше и легче
  • Быстрее: меньший размер базы данных означает лучшее использование ОЗУ, таким образом позволяя кэширование.

После загрузки документа Order, OrientDB соберет весь документ, прозрачно выбирая соединения.

План выборки

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

Транзакции

MongoDB поддерживает только атомарные операции. OrientDB поддерживает как атомарные операции, так и транзакции ACID.

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

Язык запросов

MongoDB использует свой собственный язык запросов на основе JSON.

Язык запросов OrientDB основан на всем знакомом SQL и дополнен средствами управления деревьями и графами.

 

 

 

Индексы

MongoDB использует алгоритм B-дерева для всех индексов.

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

  • Древовидный индекс SB, новое поколение алгоритма, разработанного, чтобы управлять высоким числом параллельных клиентов.
  • Индекс хеша, основанный на хешировании, очень быстро производит операции чтения и записи, однако не поддерживает запросы по диапазону.
  • MVRB-древовидный индекс  — смесь красно-черных деревьев (самобалансирующиеся двоичные деревья) и деревьев B+ (сбалансированные деревья поиска со значениями в листьях).

Механизм хранения

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

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

Начиная с версии 1.4 OrientDB использует новый движок «PLOCAL», который не использует отображение файлов в память, и самостоятельно управляет вводом-выводом на диск. Такой подход увеливает производительность на больших базах данных.

По материалам: OrientDB

1 комментарий

  1. Аноним:

    Чего такого сверхбыстрого в ссылке #8:124? Обычный идентификатор как в классических СУБД. Афтар хоть ты и ссылаешься на материалы разработчика очевидно ты не особо старался разобраться что там написано. А написано там что сверхбыстрыми являются ссылки которые оформляются в отдельный документ называемый ребром. Что же нарисовано у тебя называется у них встроенной ссылкой. Ребром был бы третий документ. Итак у ребра 2 идентификатора связываемых документов и у документов по идентификатору ребра. Выходит что ребро это 2 встроенные ссылки. Вопрос. Как у них 2 ссылки оказываются быстрее одной? С этим вопросом я пришел на этот сайт с многообещающим текстом но текст оказался фуфлом. Добавлю что по умолчанию они создают именно ребра и подчеркивают что ребра обновляются автоматически например при экспорте/импорте а встроенные ссылки не обновляются и тут тоже вопрос. Что мешает им обновлять так называемые встроенные ссылки а по сути идентификаторы в ссылающихся документах если они с успехом делают это с ребрами? Короче фуфел что у афтаров OrientDB что у афтара этого сайта.

    Ответить

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

Ваш адрес email не будет опубликован.

закрыть

Поделиться

Отправить на почту
закрыть

Вход

закрыть

Регистрация

+ =