Представлен (http://www.orientechnologies.com/orientdb-2-0-production-rea... релиз системы управления базами данных OrientDB 2.0 (http://www.orientdb.org/), которая объединяет в себе возможности документо-ориентированной и графо-ориентированной БД (http://ru.wikipedia.org/wiki/%D0%91%D0%B.... Код OrientDB написан на языке Java и распространяется (https://github.com/nuvolabase/orientdb/) под лицензией Apache. Новая ветка отмечена как достигшая уровня стабильности, пригодного для промышленной эксплуатации.Отличительной чертой OrientDB 2.0 является новая распределённая архитектура, поддерживающая параллельные запросы, асинхронную репликацию и автоматический шардинг данных по узлам кластера. По сравнению с прошлыми выпусками OrientDB в новой ветке отмечается в среднем рост производительности на 40%, для распределённых на несколько серверов конфигураций в тестах наблюдается трёхкратное ускорение работы. Благодаря кэшированию JavaScript-движка в JVM вызов JavaScript-функций теперь осуществляется до 10 раз быстрее. Переписана и заметно ускорена функция поиска кратчайшего пути в графе (shortestPath).
Кроме того, в OrientDB 2.0 задействован новый бинарный протокол, обеспечивающий хранение данных с использованием сжатия, что позволило заметно сократить занимаемое базой место на диске и уменьшить интенсивность ввода/вывода. Для повышения защищённости реализована возможность шифрования каналов связи с использованием SSL. Повышена устойчивость СУБД к повреждениям индексов. В графическом интерфейсе OrientDB Studio переработан интерфейс, представлен новый редактор графов, добавлена панель управления доступом пользователей и ролями. Добавлены ETL-модули для импорта данных из JDBC, CVS и JSON.В OrientDB даже при работе с документ-ориентированными данными взаимодействие между документами обрабатывается как в графо-ориентированной БД с определением прямых связей между записями. При этом, можно в считанные миллисекунды пройти по цепочке содержимого деревьев и графов, как целиком так и частями. Дополнительно поддерживается интерфейс объектно-ориентированной БД, который работает поверх документо-ориентированного слоя.
OrientDB отличается высокой скоростью работы, на обычном оборудовании позволяя сохранять до 150 000 записей в секунду. При тестировании производительности, один сервер с OrientDB оказался способен заменить собой 125 серверов MySQL. Распределённая сеть серверов способна обеспечить хранение до 9 223 372 036 миллиардов записей (2^63) и 19 807 040 628 566 084 Тб данных. Оперирующий запросами ключ/значение кластер OrientDB может состоять из тысяч узлов, используя для организации единого хранилища алгоритм распределённой хэш-таблицы (DHT). Для непосредственного хранения данных используется собственный алгоритм RB+Tree, сочетающий в себе особенности Red-Black Tree и B+Tree, что позволяет добиться вдвое меньшего потребления памяти при сохранении скорости Red-Black Tree за счёт балансировки операций добавления и обновления данных.
Основные особенности OrientDB:
- Полная поддержка ACID транзакций;
- Поддержка подмножества (http://code.google.com/p/orient/wiki/SQLQuery) языка SQL для выполнения запросов c использованием конструкции SELECT (OrientDB не является реляционной БД, поэтому в полной мере все возможности SQL не поддерживает);
- Поддержка хранения данных без описания предварительной схемы, с описанием полной структуры или в смешанном режиме;
- 100% совместима со стандартом TinkerPop Blueprints для графо-ориентированных БД;
- Поддержка языка запросов Gremlin (https://github.com/tinkerpop/gremlin/wiki);
- Нативно поддерживает HTTP, RESTful и JSON протоколы без использования сторонних компонентов;
- Возможность работы как в режиме встраивания в другие приложения, так и в качестве выделенного сервера;
- Возможность отката внесённых в документ локальных изменений (ODocument.undo);
- Имеет очень малый размер и не имеет сторонних зависимостей;
- Поддерживается строгая политика разграничения доступа на основе ролей и полномочий пользователей;
- Дистрибутив полностью самодостаточен;
- Поддерживает отказоустойчивые конфигурации и репликацию (архитектура OrientDB изначально рассчитана на мультимастер репликацию);
- Поддержка запуска скриптов на стороне сервера (Server Side Scripting);
- Доступна коммерческая поддержка.
URL: http://www.orientechnologies.com/orientdb-2-0-production-ready/
Новость: http://www.opennet.me/opennews/art.shtml?num=41504
Кто нибудь сравнивал с ArangoDB?
>При тестировании производительности, один сервер с OrientDB оказался способен заменить собой 125 серверов MySQL.Теститовании на чем, нету линков на мощность серваков, если стравнивать 125 серверов на одном ядре 1Гб оперативки и базой в 5 гигов с одним HP Gen8 Server на котором установлен этот монстр то да, нету ссыллок на том какими запросамим тестилось, а так маркетологический булшит
>OrientDB отличается высокой скоростью работы, на обычном оборудовании позволяя сохранять до 150 000 записей в секундуРаздражают такие заявления. Как-нибудь вменяемно нельзя было представить чтобы цифры сравнить. Или решили умолчать потому что на этом же оборудовании mysql дает 149 999 записей в секунду?
http://www.orientechnologies.com/why-orientdb/> On writes, it can store up to 150,000 records per second*.
> ...
> * On Common hardware (laptop with 4 core CPU, 8 GB RAM, HDD7200 RPM)
"Java" и "Marketing bullshit" - это неразлучная сладкая парочка, всегда идущая бок о бок.
>Возможность работы как в режиме встраивания в другие приложения, так и в качестве выделенного сервера;Если на Си было сделано - не было претензии. А тут Java, не канает.
Претензии к Java -- только сборщик мусора. Но он ныне вроде достаточно хорош. Вот в форуме по D человек писал: в его программе нв D слишком много времени занимала сборка мусора. Запретил её вручную -- и всё стало хорошо. Причина -- объекты долгоживущие, а сборщик каждый раз пыталтся что-то подобрать. На java такого уже быть не может, так как сборщики
мусора там гораздо лучше.
> Причина -- объекты долгоживущие, а сборщик каждый раз пыталтся что-то подобрать. На java такого уже быть не может, так как сборщики мусора там гораздо лучше.Ага, а в виндоусе вирусов больше нет, так как там все нормально теперь, не то что раньше.
> Претензии к Java -- только сборщик мусораНет, не только, хотя его уже хватает.
Если нужно, то можно не плодить объекты.
Если очень нужно, то можно OffHeap использовать. Это не Java-way, но прямой доступ к памяти проще, чем на C.
Ты идиот? Напуркуа тогда жаба нужна _вообще_ ?!
Уважаемый! Пока одни ковыряются с С++ другие используют Java и делают деньги.Лондонская фондовая биржа в 2011г. обрабатывала 6 миллионов заявок в секунду на ОДИН поток. http://martinfowler.com/articles/lmax.html
Как пример.
Перепутал. Это LMAX Exchange, а не London Stock Exchange.
Код выкладывают https://github.com/LMAX-Exchange
Они много лет назад на С++ начинали.
Это не даёт преимуществ. Т.к. основная фишка - собственный алгоритм.
>Поддерживает отказоустойчивые конфигурации и репликацию (архитектура OrientDB изначально рассчитана на мультимастер репликацию);Бугогашечки. Только что проверил создание базы данных (plocal, graph) на 3-х нодовом кластере и получил хрен, а не репликацию. Если системные классы ещё с горем пополам создались на всех нодах (хотя я не знаю, насколько будут реплицироваться данные), то схема создалась только на 2-х из 3-х. После перезапуска этой невезучей ноды схема, вроде бы, реплицировалась, но попытка записи чего-либо в базу валится с "Quorum 2 not reached for request ...". Охрененная репликация, скажу я вам. Ичсх, разработчиков в ЭТО ещё летом носом ткнули, даже была т.н. "коммерческая поддержка".
p.s. А ещё мне нравятся вот такие ошибки в реплицируемой отказоустойчивой базе данных при гашении ноды:
...
java.lang.NullPointerException
at com.orientechnologies.orient.server.OClientConnectionManager.pushDistribCfg2Clients(OClientConnectionManager.java:303)
at com.orientechnologies.orient.server.hazelcast.OHazelcastPlugin.memberRemoved(OHazelcastPlugin.java:560)
p.p.s. В общем, orientdb ещё пока на уровне поделия и "не готов".
>p.s. А ещё мне нравятся вот такие ошибки в реплицируемой отказоустойчивой базе данных при гашении ноды:
>..Ну вот, все эти разговоры вокруг Java на деле лишь "пыль в глаза", т.к. на практике качество продукта в первую и единственную очередь определяется уровнем интеллекта программиста. Даже такая "блондиночная" декорация имен
>com.orientechnologies.orient.server.OClientConnectionManager.pushDistribCfg2Clients(OClientConnectionManagerне спасает положение.
Ха!
Если бы Вы знали сколько багов в Oracle Database. Вам бы плохо стало!
И кучу из них НИКОГДА не починят.
А как вам коммерческий продукт от Oracle, у которого даже инсталятор не работает.Здесь, хоть исходники открытые и всегда можно разобраться, если очень нужно.
Ну сколько там багов?
Столько же, сколько и кода.
Шьерт, поддерживает 19 807 040 628 566 084 Тб, а мне нужно было 19 807 040 628 566 085 Тб. И эта не подходит...А вообще, кто так новости подает)))