Есть ли причина не использовать OrientDB?

Question

Я экспериментировал со многими базами данных noSQL. Я просто «наткнулся» на OrientDB, который, по-видимому, является гибридом хранилища документов, такого как MongoDB и базы данных графа, такой как Neo4j.

В каком-то блоге я читал, что OrientDB выполняет как минимум хорошее, если не лучше, чем Neo4j, а также предлагает более сложные типы, такие как MongoDB.

Есть ли какая-либо причина для выбора MongoDB или Neo4j? В чем подвох? Что мне не хватает? Как это сравнить с использованием MongoDB для хранения документов в сочетании с Neo4j для хранения графа (например, данные пользователя в MongoDB, отношения в Neo4j)?

Answer 1

Основная причина: Ошибки, многие из них.

Дополнительная информация: Отсутствие надлежащей документации. В прошлый раз, когда мы пытались использовать Orient, это невозможно было использовать в масштабе в производственной среде. Почему? Просто потому, что мы не могли выйти за рамки режима разработки. Мы даже не могли его перенести на тестирование. Что это за ошибки? Вы можете прочитать форумы обо всех этих или просто Google «ошибки» «orientdb». Сказав это, технология выглядит многообещающей, и мы можем дать ей еще один шаг через два года, когда она станет более зрелой.

Почему у этого так много ошибок?

Как сказал кто-то, гибридный db - сложная вещь для решения, много места для ошибок. Это тяжело.

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

Answer 2

(Отказ от ответственности: Я основатель проекта OrientDB)

Даже если около 50% пользователей OrientDB использует OrientDB в качестве базы данных Graph (замена для Neo4j), идея OrientDB была создайте первую базу данных с несколькими исходными кодами Open Source. 6 лет назад слово «Multi-Model» не существовало, но теперь поставщики СУБД, такие как DataStax (Cassandra), MongoDB и CouchBase, становятся мультимодельными или объявляются мультимодельными в предстоящем будущем. Это, конечно же, валидация концепции Multi-Model OrientDB, созданной давно.

Это означает, что в начале цель OrientDB заключалась не в том, чтобы иметь «просто» суперстабильную базу данных Graph, а скорее экспериментировать с концепцией Multi-Model. Поэтому частично верно, что команда больше ориентировалась на добавление новых моделей (вы можете увидеть их как функции), чем сделать rock-solid OrientDB и супер проста в использовании для новичков.

Однако тысячи компаний уже находятся в производстве с OrientDB. Посмотрите на Success Stories и Press, просто чтобы назвать несколько из них.

Начиная с версии 2.2, приоритет команды OrientDB изменяется: теперь, когда концепция Multi-Model стабильна, настало время сделать OrientDB суперпрочным. Если вы попробовали OrientDB до 2.2, я предлагаю предоставить OrientDB v.2.2.x шанс.Чтобы помочь новым пользователям, documentation был улучшен и для новичков.

Is OrientDB отлично? Нет СУБД без ошибок, но OrientDB имеет одну из самых низких ошибок по сравнению с другими СУБД. Посмотрите на Let's Talk about OrientDB Stability, Code Coverage and Bugs (этот пост не обновлен: он сообщает 343 ошибки, но, проверяя сегодня, количество открытых ошибок для проекта OrientDB составляет 254. Я не проверял, улучшили ли другие СУБД, которые являются частью эталона, их номера.)

Если у вас уже есть опыт работы с Neo4j, OrientDB должен быть довольно прост в использовании. Если вы использовали стандарт TinkerPop/Gremlin, OrientDB является заменой замены, в противном случае требуется определенная работа, особенно для перевода Cypher на OrientDB SQL (используйте оператор OrientDB MATCH!). Многие пользователи уже перешли на OrientDB из Neo4j, и они сообщают о сопоставимой или даже лучшей производительности.

Мое предложение: попробуйте OrientDB v2.2.x. Если это слишком сложно или плохо работает для вашего случая использования, пожалуйста, не бросайте его немедленно, но сначала попробуйте обратиться за помощью к StackOverflow или к Community Group.