Cosmos DocumentDb：低效的ORDER BY

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

截至2017年12月更新：

我重新访问了我未更改的数据库并再次运行相同的查询。这一次，它快速而不是> 87000 RU，它吃掉大约6个RU。结论：宇宙数据库似乎有一些非常非常错误的东西，但无论如何，它似乎已经消失了。