DBMS для стартапа: (ArangoDB | OrientDB) + MongoDB(GeoIndexes), что выбрать?
Подбираю СУБД для стартапа, есть следующие требования:
1) Поддержка GeoSpatial индексов и запросов, не только по точкам, но и с полигонами
2) Возможность встраивать объекты, что бы избежать лишних запросов по сущностям (Document-oriented)
3) Где нет возможности встраивать объекты, работать с Document refs без кучи лишних запросов (e.g., список друзей)
4) Replication, Sharding etc
Первым вариантом была MongoDB, за счет отличных GeoIndex'ов и возможностью работать с разными геометрическими фигурами. Но при большом количестве Doc refs в одном массиве и необходимости подгружать эти документы будет множество ограничений, которые не допустимы в приложении.
Поэтому следующим вариантом был Neo4j, т.к. был большой опыт работы с community версией. Doc refs таким образом будут связями, и все будет вообще шикарно, и моделировать проще, и кластеризация не сложная. Но цена коммерческой версии в $12k не устраивает.
Остались multi-model DBs, совмещающие в себе возможности doc-oriented и graph DBs. А конкретнее, выбор стоит между ArangoDB и OrientDB. Но их GeoIndex'ы не позволяют работать с полигонами, только точки. Также сомневаюсь в их надежности, новые все-таки продукты.
Есть ли у кого-нибудь опыт использования оговоренных выше СУБД? Готовы ли они уже к полноценному коммерческому использованию?
Если есть еще варианты, даже включающие RDBMS, то очень хочу их узнать :)
В Tarantool есть всё что вам нужно, полигоны и точки в geo-index, поддержка JSON, вторичные ключи.
Пока нет встроенного шардинга, но судя по тому что у вас в списке есть Neo4J, это не критично
OrientDB мне тут нахваливали, оно вроде бы работает, но в продакшен такое выкатывать я бы не стал, страшно.
Если у вас стартап - смело пробуйте и то и другое, пока данных мало вы сможете это все попробовать и мигрировать, если в этом будет необходимость.
И на счет 2-3, я бы на вашем месте отделил прямо сейчас все реляционные данные и запихнул их в постгрес, потому что иначе вы обрекаете себя на множество проблем и "нетрадиционных" решений, чтобы эти проблемы решить. А потом все остальное перенесете в монгу и будет вам счастье.
То есть Ваш вариант -- MongoDB + PgSQL?
И не заморачиваться со свежими технологиями? Ведь имея над Doc-oriented базой еще и графовые связи, можно избавиться от джоинов.
Извиняюсь, если я слишком яро отстаиваю NoSQL, но я ими проникся )
"Серебряной пули не бывает". Если вы думаете, что графы решат все проблемы, то вы ошибаетесь. Очевидно, что оно все рано или поздно упрется в быстродействие/производительность или масштабируемость.
psql + mongo это лишь мое предположение, мысль, которую я хотел до вас донести - не нужно использовать nosql для реляционных данных.
Простой
