为什么按时间戳(字符串)排序的Azure Cosmos查询的成本要比按_ts(内置)的成本高得多? [英] Why does a Azure Cosmos query sorting by timestamp (string) cost so much more than by _ts (built in)?
问题描述
此查询的费用为265卢布/秒:
SELECT top 1 * FROM c
WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
ORDER BY c.StartFetchDateTimeUtc DESC
This query cost 265 RU/s:
SELECT top 1 * FROM c
WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
ORDER BY c.StartFetchDateTimeUtc DESC
StartFetchDateTimeUtc 是一个字符串属性，使用Cosmos API进行了序列化
StartFetchDateTimeUtc is a string property, serialized by using the Cosmos API
此查询的费用为5 RU/s :
SELECT top 1 * FROM c
WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
ORDER BY c._ts DESC
This query cost 5 RU/s:
SELECT top 1 * FROM c
WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
ORDER BY c._ts DESC
_ts 是一个内置字段，它是基于Unix的数字时间戳.
_ts is a built in field, a Unix-based numeric timestamp.
示例结果(仅包括此字段和_ts):
"StartFetchDateTimeUtc": "2017-08-08T03:35:04.1654152Z",
"_ts": 1502163306
Example result (only including this field and _ts):
"StartFetchDateTimeUtc": "2017-08-08T03:35:04.1654152Z",
"_ts": 1502163306
索引已到位，并遵循建议&教程如何配置可排序的字符串/时间戳.看起来像:
{
"path": "/StartFetchDateTimeUtc/?",
"indexes": [
{
"kind": "Range",
"dataType": "String",
"precision": -1
}
]
}
The index is in place and follows the suggestions & tutorials how to configure a sortable string/timestamp. It looks like:
{
"path": "/StartFetchDateTimeUtc/?",
"indexes": [
{
"kind": "Range",
"dataType": "String",
"precision": -1
}
]
}
推荐答案
根据此将影响RU.
According to this article, the "Item size,Item property count,Data consistency,Indexed properties,Document indexing,Query patterns,Script usage" variables will affect the RU.
因此，不同的财产花费不同的RU是很奇怪的.
So it is very strange that different property costs different RU.
我也在自己的旁边创建了一个测试演示(带有您的索引和相同的文档属性).我已经在documentdb中插入了1000条记录.两个不同的查询费用相同.我建议您可以开始一个新的收藏并再次测试.
I also create a test demo on my side(with your index and same document property). I have inserted 1000 records to the documentdb. The two different query costs same RU. I suggest you could start a new collection and test again.
结果是这样的:
通过StartFetchDateTimeUtc排序
Order by StartFetchDateTimeUtc
按_ts排序
这篇关于为什么按时间戳(字符串)排序的Azure Cosmos查询的成本要比按_ts(内置)的成本高得多?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
