Как организовать единичную мощность для свойств Vertex, импортированных через CSV в AWS Neptune? - PullRequest
0 голосов
/ 16 ноября 2018

Документация Neptune гласит, что они поддерживают кардинальность свойства «Задать» только для данных свойств, импортированных через CSV, что означает, что вновь появившееся значение свойства не может перезаписать старое значение свойства в той же вершине и в том же свойстве.

Например, если первый CSV импортирует

~id,~label,age
Marko,person,29

, то у Марко день рождения, а второй CSV импортирует

~id,~label,age
Marko,person,30

свойство 'Marko' vertex 'age'будет содержать оба значения возраста, которые не кажутся полезными.

AWS говорит, что это (сворачивание свойства Set to Single cardinality (сохраняя только последнее полученное значение) необходимо выполнить с постобработкой, через обходы Gremlin.

Означает ли это, что должен существовать обход, который непрерывно сканирует вершины с несколькими свойствами (Set) и снова устанавливает свойство с единичным количеством элементов с последним возможным значением? ЕСЛИ так, каков оптимальный запрос Gremlin?чтобы сделать это?

В псевдо-Кремле я представляю что-то вроде:

g.V().property(single, properties(*), _.tail())

Есть ли вообще гарантия, что свойства Set-cardinality всегда перечислены в порядке поступления?

Или я здесь совсем не на том пути.

Любая помощь будет признательна.

Обновление: так что лучшее, что я смог сделатьмне до сих пор еще далеко от идеального решения, но оно все еще может быть полезным для кого-то на моем месте.

В Плане A, если нам случится знать имена свойств и порядок прибытия не имеет значения вообще (требуется только одна единица мощности для этих реквизитов), обход для всех вершин может быть примерно таким:

g.V().has(${propname}).where(property(single, ${propname}, properties(${propname}).value().order().tail() ) )

План B состоит в том, чтобы собирать новые значения свойств под временными именами свойств в одной и той же вершине (например, начиная с _), проходить через вершины, имеющие такие временные имена свойств, и задавать исходные свойства с их хвостовыми значениями с однимкардинальность:

g.V().has(${temp_propname}).where(property(single, ${propname}, properties(${temp_propname}).value().order().tail() ) ).properties('temp_propname').drop()

План C, который был бы самым крутым, но, к сожалению, не работает, состоит в том, чтобы продолжать собирать значения свойств в выделенной вершине, отметки времени эпохи в качестве имен свойств и значения свойств в качестве ихзначения:

g.V(${vertexid}).out('has_propnames').properties()
==>vp[1542827843->value1]
==>vp[1542827798->value2]
==>vp[1542887080->latestvalue]

и отсортируйте имена свойств (ключи), возьмите последнее и используйте его значение, чтобы поддерживать значение основного свойства вершины актуальным с последним значением:

g.V().has(${propname}).where(out(${has_these_properties}).count().is(gt(0))).where(property(single, ${propname}, out(${has_these_properties}).properties().value(  out(${has_these_properties}).properties().keys().order().tail()  ) ) )

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

1 Ответ

0 голосов
/ 20 ноября 2018

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

Таким образом, вашЗапрос на обновление gremlin будет выглядеть следующим образом.

g.V(${id})
 .property(single,${key},${value})

В отношении того, является ли set гарантированным порядком, я не знаю.(

...