【问题标题】:Use vertex property value to create edge when traversing multiple vertex programatically以编程方式遍历多个顶点时使用顶点属性值创建边
【发布时间】:2018-10-13 09:38:25
【问题描述】:

我发现当从数据库或任何我有关系作为列键的格式将数据导入图表时,我需要使用这些键创建边,这些键已经是顶点中的属性。

如何使用我已经摄取到图中的这些 FK 来遍历所有创建边的顶点?

而且我需要以编程方式执行此操作,因为我有大量数据需要执行此步骤。目前我正在使用 Gremlin.Net,因为我使用的大部分代码已经是 C#

示例: 想象一下,我吸收了一些客户

g.addV('customer').property('id', c_id).property('product', product_id)

还有一些产品

g.addV('product').property('id', product_id)

我想创建像这样的边缘:costumer[bought-> project] 如何使用 id 来创建边缘? 我似乎无法在其顶点的上下文中引用属性。

我想做这样的事情:

g.V.hasLabel('customer').as('c').addE('bought').to(g.V(c.product))

显然我做不到c.product,如果有任何使用循环的解决方案,很遗憾这是不可能的,因为 Cosmos Graph 不支持它。

到目前为止,我一直在 C# 中使用循环,但即使是我的示例数据也无法扩展。

【问题讨论】:

    标签: azure-cosmosdb gremlin


    【解决方案1】:

    可能有更好的方法来做到这一点,但我会提供这个:

    gremlin> g = TinkerGraph.open().traversal()
    ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
    gremlin> g.addV('customer').property('id', 321).property('productBought', 123)
    ==>v[0]
    gremlin> g.addV('product').property('id', 123)
    ==>v[3]
    gremlin> g.addV('customer').property('id', 987).property('productBought', 789)
    ==>v[5]
    gremlin> g.addV('product').property('id', 789)
    ==>v[8]
    gremlin> g.V().hasLabel('customer').as('c').
    ......1>   V().hasLabel('product').as('p').
    ......2>   where('p', eq('c')).
    ......3>     by('id').
    ......4>     by('productBought').
    ......5>   select('p').
    ......6>   addE('buys').from('c').to('p')
    ==>e[10][0-buys->3]
    ==>e[11][5-buys->8]
    

    上面的那个概念有点基于“遍历诱导值”,这在here 中有更详细的描述。

    我最近看到很多问题都在问这类问题 - 人们想要在哪里进行无边连接(即在顶点属性值上连接)。这不是图形查询大放异彩的地方,对于 Gremlin 的大多数实现,也可能是 CosmosDB,这将是一项昂贵的操作,具体取决于您拥有多少数据。

    当关系的知识已知时,最好生成边。因此,如果您在某一时刻知道“productBought”存在,那么它不应该作为“productBought”属性键加载,而是作为“product”顶点的边加载。在您的架构设计中预先做出这些选择将在以后节省很多困难。

    【讨论】:

    • 谢谢,我认为这可以让我开始,认为它看起来像一个非常昂贵的操作。至于您的评论,该图不是我的事实来源,我有大量具有多种关系的预先存在的数据,其中一些不容易查询,因此我无法一次加载 50 多个顶点,并且所有边都到位。我认为这是一种常见的情况,因为几乎没有人会想到首先从图表开始。但是考虑到优势之一应该是人际关系,我惊讶地发现它是如此难以完成
    • 图表旨在强调关系,并且它们在边上是明确的。对属性进行连接就是将图视为关系数据存储,当发生这种情况时,查询通常会很昂贵,因为您放弃了图最宝贵的方面——实体之间通过实体之间的链接直接连接。所以,你所做的根本不是一个常见的场景。刚才在 gremlin-users 邮件列表上的某个人竟然说永远不应该使用“加入”模式:groups.google.com/d/msg/gremlin-users/H-_1olyYPkA/uS0Zng77BAAJ
    • 我不确定我是否理解为什么你不能加载带有边的顶点。无论您拥有多少数据源,我都认为可以通过清晰的架构设计以及在加载到图表之前进行适当的数据分段来缓解该问题。
    • 这与我的数据的复杂性以及我不是从零开始的事实有很大关系,我希望图表可以作为关系模型中极其昂贵的方法,也就是遍历关系。当我在图中加载数据时(来自其他地方,如 sql、mongodb、json blobs,你可以命名它),这种从属性派生边的操作会很少出现。我确实尝试过这种方法,但是我必须添加的大量数据、关系和验证很快就会变得荒谬。
    • 另外,我希望我不必假设我的架构必须永远保持静态。虽然随着项目的发展会出现一些新的关系,因此可以与更新的顶点一起摄取,但对我们来说最有趣的是那些我们可以从数据中派生的关系,这里是我需要再次基于特性。如果没有这种能力,我想我可能想在寻找关系创建和遍历的过程中寻找其他地方。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-10-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-06-04
    相关资源
    最近更新 更多