1

使用 Gremlin.Net 3.3.2 我从 Neptune 和 Cosmos DB 得到了非常不同的结果。两个平台上的图形数据相同。Cosmos DB 为我提供了我需要的一切（顶点 ID、标签和属性）。

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

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

查询 = 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"
      }
    ]
  }
}
4

1 回答 1

8

Neptune 更符合 TinkerPop 本身提供的预期输出，而 CosmosDB 则返回一种较旧的方法。TinkerPop 建议将“引用”返回到图形元素（即 id 和 label 而不是属性），这似乎是 Neptune 提供的。我不知道 Neptune 是否可以配置为不同的行为。

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

此外，返回元素上的所有属性可能会非常昂贵。由于多属性，TinkerPop 很难建议返回除参考之外的任何内容。如果 aVertex可以容纳数百万个属性，那么我们最不想看到的就是元素默认序列化所有这些属性。

不幸的是，当我们开始定义 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以便它们在所有平台上保持一致。

于 2018-04-11T10:40:58.303 回答