Question

我正在对Cosmos进行一些早期试验，并用一组DTO填充表格。虽然一些简单的WHERE查询似乎很快就会返回，但其他查询的效率非常低。一个简单的COUNT(1) from c占用了几个secons并使用了超过10K的请求单元。更糟糕的是，做一些订购实验也非常令人沮丧。这是我的查询

SELECT TOP 20  c.Foo, c.Location from c
ORDER BY c.Location.Position.Latitude DESC

我的收藏（如果计数正确，我在填充数据库时运行它的超级奇怪的结果，但这是另一个问题）包含大约300K DTO。上面的查询运行了大约30秒（我目前将数据库配置为使用4K RU / s执行），并且使用了8次往返的87453.439 RU。显然，那是不行的。

根据文档，数字Latitute属性应该被编入索引，因此我不确定我是否在这里搞砸了，或者现实并没有真正赶上这里的营销;）

有关为何没有正确执行的任何想法？谢谢你的建议！

这是一份返回的文件：

  {
    "Id": "y-139",
    "Location": {
      "Position": {
        "Latitude": 47.3796977,
        "Longitude": 8.523499
      },
      "Name": "Restaurant Eichhörnli",
      "Details": "Nietengasse 16, 8004 Zürich, Switzerland"
    },
    "TimeWindow": {
      "ReferenceTime": "2017-07-01T15:00:00",
      "ReferenceTimeUtc": "2017-07-01T15:00:00+02:00",
      "Direction": 0,
      "Minutes": 45
    }
  }

我使用的数据库/集合只是可以在Azure门户中为ToDo应用程序创建的默认数据库。这显然创建了以下索引策略：

{
  "indexingMode": "consistent",
  "automatic": true,
  "includedPaths": [
    {
      "path": "/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "Number",
          "precision": -1
        },
        {
          "kind": "Hash",
          "dataType": "String",
          "precision": 3
        }
      ]
    }
  ],
  "excludedPaths": []
}

Answer 1

Update as of Dec 2017:

I revisited my unchanged database and ran the same query again. This time, it's fast and instead of > 87000 RUs, it eats up around 6 RUs. Bottom line: It appears there was something very, very wrong with Cosmos DB, but whatever it was, it seems to be gone.

Cosmos DocumentDb：低效的ORDER BY

1 个答案: