Возможны ли множественные метки вершин в Gremlin / Janusgraph или альтернативное решение лучше?

Я работаю над средством импорта для новой базы данных графов.

Он должен работать с:

  • Amazon Neptune - реализация Gremlin, имеет отличную поддержку инфраструктуры в производственной среде, но с ней сложно работать локально, и она не поддерживает Cypher. Инструмент визуализации не предусмотрен.

  • Janusgraph - с ним легко работать локально как с реализацией Gremlin, но для поддержки производства требуются большие инвестиции, следовательно, с использованием Amazon Neptune. Инструмент визуализации не предоставляется.

  • Neo4j - отличный инструмент визуализации, язык Cypher кажется очень знакомым, работает даже с клиентами Gremlin, но требует значительных инвестиций для поддержки в производстве, и, похоже, нет инструмента визуализации, который был бы где-нибудь почти так же хорош, как один найденный в Neo4j, который работает с реализациями Gremlin.

Итак, я создаю график, в котором сущности (узлы / вершины) имеют несколько типов (меток), некоторые из которых ортогональны друг другу, а также многомерны.

Например, Сущность, представляющая заказ, сделанный онлайн, будет помечена как Order, Online, Spend, Transaction.

             | Spend       Chargeback
----------------------------------------
 Transaction | Purchase    Refund
 Line        | Sale        Return

Увеличиваем столбец Spend.

          | Online      Instore
----------------------------------------
 Purchase | Order       InstorePurchase
 Sale     | OnlineSale  InstoreSale 

В Neo4j и его языке запросов Cypher это оказывается очень мощным средством для создания Отношений / Ребер между несколькими типами без явного знания того, какие transaction_id значения находятся на графике:

MATCH (a:Transaction), (b:Line)
WHERE a.transaction_id = b.transaction_id
MERGE (a)<-[edge:TRANSACTED_IN]-(b)
RETURN count(edge);

Проблема в том, что Gremlin / Tinkerpop изначально не поддерживает несколько меток для своих Verticies.

Такие серверные реализации, как AWS Neptune, будут поддерживать это используя разделитель, например. Order::Online::Spend::Transaction и клиент Gremlin поддерживает его для сервера Neo4j, но Мне не удалось найти пример, где это работает для JanusGraph.

В конечном итоге мне нужно иметь возможность выполнить запрос Gremlin, эквивалентный приведенному выше Cypher:

g
  .V().hasLabel("Line").as("b")
  .V().hasLabel("Transaction").as("a")
  .where("b", eq("a")).by("transaction_id")
  .addE("TRANSACTED_IN").from("b").to("a")';

Итак, здесь есть несколько вопросов:

  1. Есть ли способ заставить JanusGraph принимать несколько меток вершин?
  2. Если это невозможно или это не лучший подход, нужно ли добавить дополнительное свойство вершины, содержащее список меток?
  3. В случае варианта 2 должно ли имя метки быть меткой высокого уровня (Transaction) или меткой низкого уровня (Order)?

person Adam Elsodaney    schedule 06.01.2020    source источник
comment
Просто небольшое замечание о том, что для Amazon Neptune у вас «не предусмотрен инструмент визуализации». На вместо экземпляра Marketplace.   -  person James Render    schedule 08.01.2020
comment
Я использую Amazon Neptune. При локальной работе я раскручиваю Gremlin-Server с помощью докера. Как только обход графа сработает против этого, я попробую его против Нептуна. Я думаю, что за несколько месяцев этого у меня была одна проблема, которая была решена обновлением версии Нептуна, которую я использовал.   -  person James Render    schedule 08.01.2020


Ответы (1)


Есть ли способ заставить JanusGraph принимать несколько меток вершин?

Нет, в JanusGraph невозможно создать несколько меток вершин.

Если это невозможно или это не лучший подход, должно ли быть дополнительное свойство вершины, содержащее список меток?

В случае варианта 2 должно ли имя метки быть меткой высокого уровня (Транзакция) или меткой низкого уровня (Заказ)?

Я отвечу на эти два вместе. Основываясь на том, что вы описали выше, я бы создал одну метку, вероятно, с именем «Транзакция» и с различными свойствами, связанными с ними, такими как местоположение (онлайн или в магазине) и тип (покупка, возврат, возврат, возврат платежа и т. Д.). Глядя на то, как вы описываете проблему выше, вы на самом деле говорите только об одном объекте, транзакции, где все другие элементы, которые вы используете в качестве ярлыков (Online / InStore, Spend / Refund), на самом деле являются просто дополнительными метаданными о том, как эта транзакция произошла. Таким образом, вышеупомянутый подход позволит выполнить простую фильтрацию по одному или нескольким из этих атрибутов, чтобы добиться чего-либо, что можно сделать с несколькими метками, которые вы используете в Neo4j.

person bechbd    schedule 08.01.2020