我们通过 ORDER BY ASC 而不是 BY DESC 获取数据

Question

我们遇到了多个奇怪的场景。

例如：

a) 我们无法通过 _ts 订购：空结果

SELECT * FROM data ORDER BY data._ts DESC

b) 我们可以按 ASC 排序并得到结果（超过 100）。但是如果我们按 DESC 排序，我们得到零结果，对我们没有意义:(,

假设 c 是一个整数，这就是我们看到的行为：

SELECT * FROM data ORDER BY data.c ASC  = RESULTS
SELECT * FROM data ORDER BY data.c DESC = zero results

c) 我们有一个 UDF 要做包含不敏感的，但并不适用于所有情况，JS 函数在外部测试并且 IT 正在工作，我们不明白 SELECT * 来自数据 r 其中 udf.TEST(r.c, "AS") = 结果 SELECT * FROM 数据 r 其中 udf.TEST(r.c, "health") = 零结果（但通过其他字段我可以找到值）

非常感谢！

Answer 1

jamesjara 和我离线同步...为了其他人的利益在这里发布我们的讨论:)

1) 查询响应限制和延续令牌

查询在 DocumentDB 上执行的时间有限制。这些限制包括查询的资源消耗（您可以将其与预配置的数量 RU/sec * 5 秒 + 未公开的缓冲区相结合）、响应大小 (1mb) 和超时（5 秒）。

如果达到这些限制，则可能会返回部分结果集。通过以延续令牌（HTTP 响应 header 中的x-ms-continuation）的形式传回状态，保留查询执行完成的工作。您可以通过在 follow-up 查询中传递继续标记来恢复查询的执行。客户端 SDK 通过 toList() 或 toArray()（取决于 SDK 风格）自动对结果进行分页，从而简化了这种交互。

结果中可能出现空白页。当在查询引擎找到第一个结果之前达到资源消耗限制时（例如，当扫描通过 collection 以在大型数据集中查找少量文档时，可能会发生这种情况。

2) ORDER BY 和索引策略

为了在您的查询中使用 ORDER BY 或范围比较（<、> 等），您应该指定一个索引策略，其中包含具有最大值的范围索引用于排序的 JSON 属性的精度（精度 = -1）。这允许查询引擎利用索引。

否则，您可以通过指定 x-ms-documentdb-query-enable-scan HTTP 请求 header 并将值设置为 true 来强制扫描。在客户端 SDK 中，这是通过 FeedOptions object.

公开的

ORDER BY 的建议索引策略：

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

3) UDF 和索引

UDF 无法利用索引，并且会导致扫描。因此，建议在您的查询 WHERE 子句中包含额外的过滤器，以减少要扫描的文档数量。

我们通过 ORDER BY ASC 而不是 BY DESC 获取数据

We get data with ORDER BY ASC but NOT BY DESC

azure-cosmosdb