Состоялся (http://orientdb.com/released-orientdb-v2-2/) релиз СУБД OrientDB 2.2 (http://www.orientdb.org/), которая объединяет в себе возможности документо-ориентированной и графо-ориентированной БД (http://ru.wikipedia.org/wiki/%D0%91%D0%B.... Взаимодействие между документами в OrientDB обрабатывается как в графо-ориентированной БД с определением прямых связей между записями, что позволяет в считанные миллисекунды пройти по цепочке содержимого деревьев и графов, как целиком так и частями. Дополнительно поддерживается интерфейс объектно-ориентированной БД, который работает поверх документо-ориентированного слоя. Код OrientDB написан на языке Java и распространяется (https://github.com/nuvolabase/orientdb/) под лицензией Apache.
Ключевые новшества:- Обеспечена (http://orientdb.com/docs/last/Database-Encryption.html) возможность хранения данных на диске в зашифрованном виде. Для шифрования предлагаются алгоритмы AES и DES. Ключ шифрования не хранится в БД, а передаётся при подключении к СУБД;
- Добавлена новая настраиваемая модель обеспечения согласованности данных в графе (Graph Consistency (http://orientdb.com/docs/last/Graph-Consistency.html)), выступающая в роли альтернативы транзакциям и по сравнению с ними ускоряющая выполнение операций по изменению элементов графа;
- На смену Workbench пришел новый web-интерфейс OrientDB Studio (http://orientdb.com/docs/last/Studio-Home-page.html), основанный на новой архитектуре и других модулях;
<center><a href="http://orientdb.com/docs/last/images/studio-newDb.png"&... src="https://www.opennet.ru/opennews/pics_base/0_1463594764.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
- Улучшены системы аудита операции с БД, расширены возможности аутентификации, добавлена поддержка Kerberos;
- В движок внесена порция оптимизаций, позволившая ускорить работу при различных видах нагрузки;
- Для распределённых конфигураций представлена поддержка режима быстрой ресинхронизации узлов (fast-resync);
- Реализовано решение для создания инкрементальных бэкапов;- Добавлен инструмент Teleporter (http://orientdb.com/docs/last/Teleporter-Home.html), позволяющий синхронизировать содержимое БД с реляционными СУБД и упрощающий проведение миграции данных в OrientDB;
- Добавлены дополнительные элементы в реализацию SQL: поиск по шаблону (http://orientdb.com/docs/last/SQL-Match.html) (оператор MATCH), кэш команд, параллельные запросы и Live-запросы (http://orientdb.com/docs/last/Live-Query.html) (получение изменений в реальном времени);
- В OrientJS (https://github.com/orientechnologies/orientjs), драйвер для Node.js, добавлена поддержка демаршалинга (https://ru.wikipedia.org/wiki/%D0%9C%D0%....
Основные особенности OrientDB:
- Полная поддержка ACID-транзакций;
- Поддержка подмножества (http://code.google.com/p/orient/wiki/SQLQuery) языка SQL для выполнения запросов c использованием конструкции SELECT (OrientDB не является реляционной БД, поэтому в полной мере все возможности SQL не поддерживает);
- Поддержка хранения данных без описания предварительной схемы, с описанием полной структуры или в смешанном режиме;
- Полностью совместима со стандартом TinkerPop Blueprints для графо-ориентированных БД;
- Поддержка языка запросов Gremlin (https://github.com/tinkerpop/gremlin/wiki);
- Нативно поддерживает HTTP, RESTful и JSON протоколы без использования сторонних компонентов;
- Возможность работы как в режиме встраивания в другие приложения, так и в качестве выделенного сервера;
- Возможность отката внесённых в документ локальных изменений (ODocument.undo);
- Имеет очень малый размер и не имеет сторонних зависимостей;
- Поддерживается строгая политика разграничения доступа на основе ролей и полномочий пользователей;
- Дистрибутив полностью самодостаточен;
- Поддерживает отказоустойчивые конфигурации и репликацию (архитектура OrientDB изначально рассчитана на мультимастер репликацию);
- Кластер OrientDB может состоять из тысяч узлов и использовать для организации единого хранилища алгоритм распределённой хэш-таблицы (DHT);
- Поддержка запуска скриптов на стороне сервера (Server Side Scripting);
- Использование собственного алгоритма RB+Tree для хранения данных, сочетающего в себе особенности Red-Black Tree и B+Tree, что позволяет добиться вдвое меньшего потребления памяти при сохранении скорости Red-Black Tree за счёт балансировки операций добавления и обновления данных.
- Поддержка live-запросов, позволяющих получать информацию об изменениях в БД в режиме реального времени;
- Наличие средств аудита для отслеживания всех операции изменения, чтения, обновления и удаления для каждого объекта в СУБД.URL: http://orientdb.com/released-orientdb-v2-2/
Новость: http://www.opennet.ru/opennews/art.shtml?num=44457
кто использует, были-ли у вас с ней какие проблемы?
У меня другая проблема - хочется попользовать, но не могу придумать куда))
Ну, ты можешь хранить там имя соседской кошки. И свой возраст. И текст любимой песни. Вот.
Основное отличие - динамическая возможность создать структуру таблиц И связи между ними.
А типа на том же посгре я не могу динамически создать таблицу/отношение, угу, tell me moar. Или что имелось в виду?
> А типа на том же посгре я не могу динамически создать таблицу/отношение,
> угу, tell me moar. Или что имелось в виду?на посгре нет, не можешь.
Хорошо вписывается задача - работать с дампом какой-нибудь соцсети.
Например скачал весь вконтактик: друзья, группы. json, среднеструктурированный.В SQL-ях такое хранить вообще боль.
В Mongo самих пользователей - очень удобно, но со связями работает медленно. А тут самое оно.
>В SQL-ях такое хранить вообще боль.Ты наверное хотел сказать: "в реляционных субд"?
Так и тут ты не прав. Просто связи приходится проектировать заранее. Это плата за функциональность, недоступную в сетевых БД.
"связи приходится проектировать заранее"Сложно проектировать заранее то, что не ты проектируешь. Я же написал про дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя будет страшенная куча таблиц, а в document based nosql - всё в одну коллекцию красиво залезет.
Это и есть "В SQL-ях такое хранить вообще боль"
> "связи приходится проектировать заранее"
> Сложно проектировать заранее то, что не ты проектируешь. Я же написал про
> дамп соцсети. Ну и проектируй, не проектируй, в SQLщине у тебя
> будет страшенная куча таблиц, а в document based nosql - всё
> в одну коллекцию красиво залезет.
> Это и есть "В SQL-ях такое хранить вообще боль"Спроектирую структуру для твоего дампа. За деньги. Заранее определи отчеты, которые хочешь получать, сделаю так, что связи будут вычисляться со вполне сравнимым временем. За деньги хрен с ним, пусть сообщество решит, стоит мне в итоге платить, или нет. Ждать от тебя дамп?
> Сложно проектировать заранее то, что не ты проектируешь. Я же написал про
> дамп соцсети. Ну и проектируй, не проектируй, в 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, вполне подходящее решение для определённых случаев, никто не заставляет нормализовать.
Были и еще какие. Гугли на английском orientdb shit или orient kill startup, таких историй начитаешься - волосы дыбом. Вот например мы столкнулись с таки багом - делаешь select с order by - все хорошо, добавляешь limit x - выбирает любые x записей и сортирует только их. И еще, если разрабы говорят, что баг починен - не верь, проверяй - врут безмерно.
[quote]делаешь select с order by - все хорошо, добавляешь limit x - выбирает любые x записей и сортирует только их.[/quote]
Наверное, это для повышения производительности...
Про разрабов — это правда. Они, возможно, что-то и починили, а может и нет. А может ещё и поломали по соседству. Но всегда заявляют, что починили.
В своё время полтора года назад замахались тестировать их фиксы кластера.
Было полно проблем с 2.0. Оно сначала тупо не работало в кластере (ни документ, ни граф), потом работало только в 2-хнодовом режиме, но не работало в 3+.
Но вполне возможно, что уже починили.
А когда успели придумать новое слово "Графовые СУБД"? Раньше их всегда сетевыми звали.
это замена понятия - иерархических СУБД
ага. графовые - частный случай иерархических(или наоборот, как смотреть ;)
Она distributed? Нигде не могу найти про это, только упоминают про Big Data. Хотя я работал с big data, и там подразумевается, что данные никак не помещаются на одну машину. Или они просто ради маркетинга используют термин big data?
orientdb - распределенная
neo4j - не распределенная
> orientdb - распределенная
> neo4j - не распределеннаяя бы не относил сабж к распределенным всерьез. поддержка мультимастре репликации - еще не делает что-то "распределенным" само по себе ;)
а вот наличие ACID - уже ощутимый плюс на фоне сонма безликих, бесполезных аналогов, лишенного оного.
> я бы не относил сабж к распределенным всерьез. поддержка мультимастре репликации -
> еще не делает что-то "распределенным" само по себе ;)
> а вот наличие ACID - уже ощутимый плюс на фоне сонма безликих,
> бесполезных аналогов, лишенного оного.Хм, а в чём тогда настоящая "распределённость", если не в мультимастере?
в "распределенности" обработки, сюрприз. безо всяких "мастеров" с полностью асинхронной обработкой без точек отказов или узких мест в других смыслах(не исключая производительность).
ваш КО.
>Код OrientDB написан на языке JavaЗа что...
Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)Чу! Мне послышался треск, как будто что-то рвётся.
> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)Всё bigdata написано на жабе, не нравится, можешь остановить планету и сойти.
В результате вся бигдата упихивается в постгрес и все счастливы
Постгрес лучшая DB, пока данные еще влезают на одну машину и IO еще успевает их пропускать.
> Постгрес лучшая DB, пока данные еще влезают на одну машину и IO
> еще успевает их пропускать.+1
А если не влазят, то лучше не заниматься БД самим, а использовать сервисы от GCP или AWS.
>> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)
> Всё bigdata написано на жабе, не нравится, можешь остановить планету и сойти.бидата и жаба в оном предложении - заводомый когнитвный диссонанс.
даже иерархические БД там носят вторичный характер и использутся сугубо для оперативной аналитики а основная обработка идет в Распределенных бд.
ортодоскальные вещи - не масштабируются так хорошо и не расшмиряются функционально так(не без исключений, не меняющих ничего принципиально, конечно).
> Интересная новость... "Код OrientDB написан на языке Java..." И до свидания! :)Значит ты не попадаешь в мир кластеров и BigData. Вырастешь - может быть сможешь вернуться.
