如何从Cosmos DB获得与Amazon Neptune相同的结果？

Question

使用Gremlin.Net 3.3.2我得到了与Neptune和Cosmos DB截然不同的结果.两个平台上的图表数据相同.Cosmos DB为我提供了我需要的一切(顶点id,标签和属性).

当使用Gremlin.Net对Neptune进行查询时,我只获得顶点Id和标签.这是Neptune和Gremlin.net的错误吗？海王星的错误？

如果在gremlin控制台中执行查询,Neptune会返回所有数据,因此问题似乎仅限于Gremlin.Net.

query = gV().has('name',within('wind'))

Amazon Neptune results
{
  "Id": "14b15642-842f-888a-a28e-3ed117a07d5b",
  "Label": "keyword"
}

Cosmos DB results
{
  "id": "wind",
  "label": "keyword",
  "type": "vertex",
  "properties": {
    "popularity": [
      {
        "id": "8f9967f1-cead-41d6-a432-de025d9dc14b",
        "value": "16"
      }
    ],
    "name": [
      {
        "id": "fb90af3f-828b-4cc0-b9f8-b571a30c6b14",
        "value": "wind"
      }
    ]
  }
}

Answer 1

海王星与TinkerPop本身提供的预期输出更为一致,而CosmosDB则回归旧方法.TinkerPop建议将"引用"返回到图形元素(即id和label而不是属性),这似乎是Neptune提供的.我不知道Neptune是否可以配置为表现不同.

虽然看起来不方便,但TinkerPop推荐这种方法的原因是用户应该只返回他们请求的数据.例如,您通常不会SELECT * FROM table为SQL查询执行操作 - 您将在SELECT子句中包含要返回的字段.出于与SQL相同的原因,您可以在Gremlin中执行此操作.

此外,返回元素上的所有属性可能非常昂贵.由于多属性,TinkerPop很难建议返回除引用之外的任何内容.如果a Vertex可以容纳数百万个属性,那么我们希望看到的最后一件事就是元素默认使用所有这些属性进行序列化.

不幸的是,当我们开始定义IO格式的路径时,TinkerPop社区中的大部分思路都不明确.OLAP仍然是一个实验,GLV不是一个想法,所以"参考元素作为默认值"的想法直到后来的版本才出现.希望我们有一天可以使TinkerPop 4.x的IO更加一致.

获得相同结果的方法是遵循TinkerPop的建议并避免返回图元素.最好的方法可能是使用project()或valueMap()以某种形式:

g.V().valueMap('popularity','name')
g.V().
  project('popularity','name').
    by('popularity').
    by('name')

注意,虽然project()在这个例子更详细一点但它确实提供了更紧凑的输出,因为它没有嵌入在每个键的值List的方式valueMap()一样.以上将强制结果,Map以便它们在所有平台上保持一致.