Правильна ли база данных графа для определения бизнес-маршрута?

Question

У меня есть бизнес-логин c для определения экономически эффективного route, который приносит пользу бизнесу. route здесь означает, технически, API / связность (поставщик услуг), к которому приложение должно подключиться для выполнения транзакции, а выгода здесь в том, что бизнес получает цену за выполнение транзакции.

A route должен быть идентифицирован на основе различных параметров - некоторые из них: стоимость транзакции, возможность подключения к поставщику услуг для выполнения транзакции, флаг приоритета, установленный для поставщика услуг, счетчики транзакций для поставщиков услуг, клиент, который выполняет транзакцию, тип выполненной транзакции, свойства, присутствующие в транзакции, которую ожидает поставщик услуг, сборы поставщиков услуг (самые низкие) и др.

На данный момент эти свойства сжаты в реляционная база данных, маршруты запрашиваются в середине сложного запроса. Мне интересно посмотреть, подходит ли graph database как Apache Tinkerpop для таких случаев. Я уже использовал graphdb для своего рода механизма рекомендации продукта, основанного на отношениях с клиентами. Стоит отметить, что бизнес продолжает менять маршруты в любое время в зависимости от трафика c и спроса.

Я добавлю детали, если потребуется.

Answer 1

Прежде всего, я бы сказал, что это типичный случай использования графовой базы данных.

Вам нужен алгоритм кратчайшего пути, который поможет вам найти наиболее экономически эффективный путь для бизнеса. Принимая во внимание параметры, которые вы упомянули в вопросе, вам может понадобиться использовать их в качестве вершин, ребер (отношений) или свойств вершины / ребра в графовой модели.

Сейчас я пытаюсь представить модель, основанную на вашем описании и моем понимании. Это ни в коем случае не полная (или правильная) модель, так как я уверен, что здесь не хватает информации. Просто образец для справки.

Обычно в модели графа свойств есть три понятия:

• Вершина
• Край / Связь
• Свойства для вершины или ребра

На основе предоставленной вами информации модель графа может иметь:

• Вершины - поставщик услуг, с приоритетом, расходами и транзакциями счетчики в качестве его свойств client клиент
• Edges - транзакция со значением транзакции в качестве его свойства

Вы можете придумать что-то вроде этого:

Базовая c единица модели графа

Наконец, если ваш набор данных не слишком велик, скажем, менее 1 миллиарда (вершины и ребра вместе), большинство графовых баз данных могут справиться с этим. Что касается их производительности, то если ваши данные могут быть размещены на одном узле (хосте), то нет большой разницы.