Question

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

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

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

query = g.V（）。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建议返回＆＃34;参考＆＃34;图表元素（即id和标签，而不是属性），这似乎是海王星提供的。我不知道Neptune是否可以配置为表现不同。

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

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

不幸的是，当我们开始定义IO格式的路径时，TinkerPop社区中的大部分思路都不明确。 OLAP仍然是一个实验，GLV不是一个想法等等，所以＆＃34;参考元素的概念作为默认＆＃34;直到后来的版本才出现。希望我们有一天可以使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，以便它们在所有平台上保持一致。

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

1 个答案: