The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск СУБД OrientDB 2.2

18.05.2016 20:20

Состоялся релиз СУБД OrientDB 2.2, которая объединяет в себе возможности документо-ориентированной и графо-ориентированной БД. Взаимодействие между документами в OrientDB обрабатывается как в графо-ориентированной БД с определением прямых связей между записями, что позволяет в считанные миллисекунды пройти по цепочке содержимого деревьев и графов, как целиком так и частями. Дополнительно поддерживается интерфейс объектно-ориентированной БД, который работает поверх документо-ориентированного слоя. Код OrientDB написан на языке Java и распространяется под лицензией Apache.

Ключевые новшества:

  • Обеспечена возможность хранения данных на диске в зашифрованном виде. Для шифрования предлагаются алгоритмы AES и DES. Ключ шифрования не хранится в БД, а передаётся при подключении к СУБД;
  • Добавлена новая настраиваемая модель обеспечения согласованности данных в графе (Graph Consistency), выступающая в роли альтернативы транзакциям и по сравнению с ними ускоряющая выполнение операций по изменению элементов графа;
  • На смену Workbench пришел новый web-интерфейс OrientDB Studio, основанный на новой архитектуре и других модулях;
  • Улучшены системы аудита операции с БД, расширены возможности аутентификации, добавлена поддержка Kerberos;
  • В движок внесена порция оптимизаций, позволившая ускорить работу при различных видах нагрузки;
  • Для распределённых конфигураций представлена поддержка режима быстрой ресинхронизации узлов (fast-resync);
  • Реализовано решение для создания инкрементальных бэкапов;
  • Добавлен инструмент Teleporter, позволяющий синхронизировать содержимое БД с реляционными СУБД и упрощающий проведение миграции данных в OrientDB;
  • Добавлены дополнительные элементы в реализацию SQL: поиск по шаблону (оператор MATCH), кэш команд, параллельные запросы и Live-запросы (получение изменений в реальном времени);
  • В OrientJS, драйвер для Node.js, добавлена поддержка демаршалинга.



Основные особенности OrientDB:

  • Полная поддержка ACID-транзакций;
  • Поддержка подмножества языка SQL для выполнения запросов c использованием конструкции SELECT (OrientDB не является реляционной БД, поэтому в полной мере все возможности SQL не поддерживает);
  • Поддержка хранения данных без описания предварительной схемы, с описанием полной структуры или в смешанном режиме;
  • Полностью совместима со стандартом TinkerPop Blueprints для графо-ориентированных БД;
  • Поддержка языка запросов Gremlin;
  • Нативно поддерживает HTTP, RESTful и JSON протоколы без использования сторонних компонентов;
  • Возможность работы как в режиме встраивания в другие приложения, так и в качестве выделенного сервера;
  • Возможность отката внесённых в документ локальных изменений (ODocument.undo);
  • Имеет очень малый размер и не имеет сторонних зависимостей;
  • Поддерживается строгая политика разграничения доступа на основе ролей и полномочий пользователей;
  • Дистрибутив полностью самодостаточен;
  • Поддерживает отказоустойчивые конфигурации и репликацию (архитектура OrientDB изначально рассчитана на мультимастер репликацию);
  • Кластер OrientDB может состоять из тысяч узлов и использовать для организации единого хранилища алгоритм распределённой хэш-таблицы (DHT);
  • Поддержка запуска скриптов на стороне сервера (Server Side Scripting);
  • Использование собственного алгоритма RB+Tree для хранения данных, сочетающего в себе особенности Red-Black Tree и B+Tree, что позволяет добиться вдвое меньшего потребления памяти при сохранении скорости Red-Black Tree за счёт балансировки операций добавления и обновления данных.
  • Поддержка live-запросов, позволяющих получать информацию об изменениях в БД в режиме реального времени;
  • Наличие средств аудита для отслеживания всех операции изменения, чтения, обновления и удаления для каждого объекта в СУБД.


  1. Главная ссылка к новости (http://orientdb.com/released-o...)
  2. OpenNews: Выпуск СУБД OrientDB 2.1
  3. OpenNews: Выпуск СУБД OrientDB 2.0
  4. OpenNews: Новая версия NoSQL базы данных OrientDB 1.3
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/44457-orientdb
Ключевые слова: orientdb
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:55, 18/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кто использует, были-ли у вас с ней какие проблемы?
     
     
  • 2.2, nc (ok), 23:02, 18/05/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    У меня другая проблема - хочется попользовать, но не могу придумать куда))
     
     
  • 3.3, A.Stahl (ok), 23:10, 18/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, ты можешь хранить там имя соседской кошки. И свой возраст. И текст любимой песни. Вот.
     
  • 3.4, Аноним (-), 00:16, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Основное отличие - динамическая возможность создать структуру таблиц И связи между ними.
     
     
  • 4.5, Аноним (-), 01:10, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А типа на том же посгре я не могу динамически создать таблицу/отношение, угу, tell me moar. Или что имелось в виду?
     
     
  • 5.32, Аноним (-), 18:03, 21/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А типа на том же посгре я не могу динамически создать таблицу/отношение,
    > угу, tell me moar. Или что имелось в виду?

    на посгре нет, не можешь.

     
  • 3.11, Лютый жабист (ok), 06:53, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хорошо вписывается задача - работать с дампом какой-нибудь соцсети.
    Например скачал весь вконтактик: друзья, группы. json, среднеструктурированный.

    В SQL-ях такое хранить вообще боль.
    В Mongo самих пользователей - очень удобно, но со связями работает медленно. А тут самое оно.

     
     
  • 4.17, АнонимУася (?), 21:55, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >В SQL-ях такое хранить вообще боль.

    Ты наверное хотел сказать: "в реляционных субд"?
    Так и тут ты не прав. Просто связи приходится проектировать заранее. Это плата за функциональность, недоступную в сетевых БД.

     
     
  • 5.22, Лютый жабист (ok), 05:27, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "связи приходится проектировать заранее"

    Сложно проектировать заранее то, что не ты проектируешь. Я же написал про дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя будет страшенная куча таблиц, а в document based nosql - всё в одну коллекцию красиво залезет.

    Это и есть "В SQL-ях такое хранить вообще боль"

     
     
  • 6.35, АнонимУася (?), 11:48, 24/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > "связи приходится проектировать заранее"
    > Сложно проектировать заранее то, что не ты проектируешь. Я же написал про
    > дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя
    > будет страшенная куча таблиц, а в document based nosql - всё
    > в одну коллекцию красиво залезет.
    > Это и есть "В SQL-ях такое хранить вообще боль"

    Спроектирую структуру для твоего дампа. За деньги. Заранее определи отчеты, которые хочешь получать, сделаю так, что связи будут вычисляться со вполне сравнимым временем. За деньги хрен с ним, пусть сообщество решит, стоит мне в итоге платить, или нет. Ждать от тебя дамп?

     
  • 6.36, dlazerka (ok), 19:23, 25/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Сложно проектировать заранее то, что не ты проектируешь. Я же написал про
    > дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя
    > будет страшенная куча таблиц, а в document based nosql - всё
    > в одну коллекцию красиво залезет.
    > Это и есть "В SQL-ях такое хранить вообще боль"

    У информации должна быть структура, иначе это энтропический шум. Хранить входные данные "как есть" имеет смысл только если их не надо обрабатывать, а так же выдавать "как есть". И "в SQLях" такое прекрасно хранится в столбце типа TEXT или BLOB.

    Хотя в PostgreSQL можно юзать тип JSONB, который и процессить можно быстро (быстрее чем Монга, замерял), и индексы строить по JSON-овским полям, и JOINы делать.

    А если же данные нужно каким-то образом обрабатывать, то в любом случае нужно знать структуру, хотя бы интересующую часть. То есть в schema-less базах схему тоже нужно менеджить, но уже в нашем собственном коде, а не в СУБД: писать руками db-upgrader скрипты. И если наш data source поменял формат, то и наш код тоже нужно менять.

    Schema-less -- это отсутствие фичи. Храните всё в одном столбце TEXT, BLOB или JSONB и будет вам schema-less, вполне подходящее решение для определённых случаев, никто не заставляет нормализовать.

     
  • 2.9, Игорт (?), 06:17, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Были и еще какие. Гугли на английском orientdb shit или orient kill startup, таких историй начитаешься - волосы дыбом. Вот например мы столкнулись с таки багом - делаешь select с order by - все хорошо, добавляешь limit x - выбирает любые x записей и сортирует только их. И еще, если разрабы говорят, что баг починен - не верь, проверяй - врут безмерно.
     
     
  • 3.10, Это я (?), 06:37, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    [quote]делаешь select с order by - все хорошо, добавляешь limit x - выбирает любые x записей и сортирует только их.[/quote]
    Наверное, это для повышения производительности...
     
  • 3.26, OramahMaalhur (ok), 11:11, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Про разрабов — это правда. Они, возможно, что-то и починили, а может и нет. А может ещё и поломали по соседству. Но всегда заявляют, что починили.
    В своё время полтора года назад замахались тестировать их фиксы кластера.
     
  • 2.25, OramahMaalhur (ok), 11:08, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Было полно проблем с 2.0. Оно сначала тупо не работало в кластере (ни документ, ни граф), потом работало только в 2-хнодовом режиме, но не работало в 3+.
    Но вполне возможно, что уже починили.
     

  • 1.7, Анон вроде (?), 02:55, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    А когда успели придумать новое слово "Графовые СУБД"? Раньше их всегда сетевыми звали.
     
     
  • 2.8, Анонус (?), 05:48, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    это замена понятия - иерархических СУБД
     
     
  • 3.18, Аноним (-), 23:02, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ага. графовые - частный случай иерархических(или наоборот, как смотреть ;)
     

  • 1.13, dlazerka (ok), 09:49, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Она distributed? Нигде не могу найти про это, только упоминают про Big Data. Хотя я работал с big data, и там подразумевается, что данные никак не помещаются на одну машину. Или они просто ради маркетинга используют термин big data?
     
     
  • 2.14, ttt (??), 10:28, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    orientdb - распределенная
    neo4j - не распределенная
     
     
  • 3.19, Аноним (-), 23:04, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > orientdb - распределенная
    > neo4j - не распределенная

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


     
     
  • 4.20, dlazerka (ok), 00:52, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > я бы не относил сабж к распределенным всерьез. поддержка мультимастре репликации -
    > еще не делает что-то "распределенным" само по себе ;)
    > а вот наличие ACID - уже ощутимый плюс на фоне сонма безликих,
    > бесполезных аналогов, лишенного оного.

    Хм, а в чём тогда настоящая "распределённость", если не в мультимастере?

     
     
  • 5.27, Аноним (-), 11:14, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    в "распределенности" обработки, сюрприз. безо всяких "мастеров" с полностью асинхронной обработкой без точек отказов или узких мест в других смыслах(не исключая производительность).
    ваш КО.
     

  • 1.15, gaga (ok), 11:50, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Код OrientDB написан на языке Java

    За что...

     
     
  • 2.16, default (??), 17:07, 19/05/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
     
     
  • 3.21, dlazerka (ok), 00:57, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)

    Чу! Мне послышался треск, как будто что-то рвётся.

     
  • 3.23, Лютый жабист (ok), 05:29, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)

    Всё bigdata написано на жабе, не нравится, можешь остановить планету и сойти.

     
     
  • 4.24, Аноним (-), 10:08, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В результате вся бигдата упихивается в постгрес и все счастливы
     
     
  • 5.29, Вареник (?), 02:11, 21/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Постгрес лучшая DB, пока данные еще влезают на одну машину и IO еще успевает их пропускать.
     
     
  • 6.31, dlazerka (ok), 05:28, 21/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Постгрес лучшая DB, пока данные еще влезают на одну машину и IO
    > еще успевает их пропускать.

    +1
    А если не влазят, то лучше не заниматься БД самим, а использовать сервисы от GCP или AWS.

     
  • 4.28, Аноним (-), 11:16, 20/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
    > Всё bigdata написано на жабе, не нравится, можешь остановить планету и сойти.

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


     
  • 3.30, Вареник (?), 02:14, 21/05/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)

    Значит ты не попадаешь в мир кластеров и BigData. Вырастешь - может быть сможешь вернуться.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру