Есть ли база данных графического документа, которая поддерживает геопространственные запросы?

Question

Вот краткое изложение того, что мне нужно:

• График базы данных
• Каждый узел является документом; будут сотни типов узлов; каждый из этих нескольких сотен типов будет иметь свою собственную согласованную схему.
• может масштабироваться до миллиардов узлов
• Каждый узел также имеет (лат, LNG) cooordinate в дополнение к краям между узлами
• я хочу использовать (лат, LNG) в качестве ключа шарда так что это может быть масштабируется до крупного осколочного реплицированного кластера. Пограничные обходы пройдут ~ 95% в соседних (лат, lng) местах.
• Я хочу, чтобы иметь возможность выдавать запросы geo + document. Например: «Покажите мне все узлы графа/документы, соответствующие этому запросу {...}, упорядоченные по расстоянию от (lat_0, lng_0)»
• Я хочу, чтобы что-то хорошо документированное, имеющее активное сообщество разработчиков, рекомендуется для производства использовать и, вероятно, быть в течение многих лет.

Здесь нет проблем с существующими базами данных:

• MongoDB: нет поддержки граф, не присоединяется
• Neo4j: нет шардинга
• OrientDB: нет геопространственной индексации
• ArangoDB: может сделать ТЕЧЕНИЕ запросов, но не может иметь дополнительных условий запроса (например, у geoNear у MongoDB есть параметр запроса)

Есть ли что-нибудь, что подходит для моего использования?

Answer 1

Вы хотите единорога и машину, которая печатает неограниченное количество счетов в размере 100 долларов, чтобы согласиться с этим? Har har har ....

Хорошо, но серьезно, у вас там высокий порядок. Вам понадобится специальная система, которая объединяет некоторые из этих вещей вместе. Во-первых, как вы заметили, на самом деле нет такой вещи, как база данных «graph/document».

Как общая область системных исследований, многие люди ищут гибридные системы. Например, вы поддерживаете свою структуру графика в neo4j и что идентификаторы узлов в neo4j указывают на идентификаторы для документов в MongoDB. Таким образом, у вас будет база данных графиков/документов, но на самом деле это будет две базы данных. Такие гибридные системы изобилуют компромиссами. Во-первых, писать запрос в обеих системах будет крайне сложно. Во-вторых, вы введете в себя данные зависимости между ними, так что может быть нелегко обновить структуру графика без изменения ваших документов или наоборот.

Для действительно интенсивных требований к производительности гибридные системы - это единственный путь. Но так же, как правило, за каждые 100 раз вы видите, что кто-то говорит, что им нужно такое решение, возможно, в 80 раз лучше, чем выбрать одну базу данных, а затем жить с плюсами и минусами, которые они им предоставляют. Технология в конечном счете касается выбора, плюсов и минусов и обучения жить с тем, что вы выбрали. :)

Чтобы дать вам краткий ответ на заданный вами вопрос, нет ничего, что бы все это делало.Я бы рекомендовал вам работать с архитектором или консультантом, который может подробно изучить ваши требования и сделать рекомендацию о том, какая архитектура наилучшим образом соответствует большинству ваших потребностей, балансируя простоту и стоимость. Это искусство, как наука.