时间戳

首页 > 解决方案 > 这是 CosmosDB 对整数属性的“之间”查询的预期查询性能吗

performance - 这是 CosmosDB 对整数属性的“之间”查询的预期查询性能吗

问题描述

我有一个 cosmosdb 集合（sql api），其中填充了代表 CIDR 网络范围的文档。

每个文件的相关部分是

{
        "Network": "31.216.102.0/23",
        "IPRangeStart": 534275584,
        "IPRangeEnd": 534276095,

每个 CIDR 块都将其开始和结束 IP 地址转换为uint并存储在 hteRangeStart和RangeEnd属性中。

当我运行查询以按起始范围搜索特定条目时，它按预期工作并且速度非常快。

SELECT top 1 * FROM c WHERE c.IPRangeStart = 532361216 
Request Charge: 3.02 RUs

但是，当我使用 <= / => 运算符引入查询之间时，它变得非常昂贵。

SELECT top 1 * FROM c WHERE c.IPRangeStart <= 534275590 AND c.IPRangeEnd >= 534275590 
Request Change: 1647.99 RUs

我已经查看了集合上的索引设置

我还在有问题的两个特定属性的集合上应用了 2 个额外的整数范围索引。尽管似乎没有办法检查这些索引在后台应用/创建的进度。

有什么明显的东西我可能会丢失。

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

标签： performanceazureindexingazure-cosmosdb

解决方案

想我解决了。问题源于这样一个事实，即我对一个属性进行了大于查询，对另一个属性进行了小于查询。

似乎 cosmos 正在合并满足每个独立过滤子句的完整文档集。

由于集合中最大的 CIDR 范围是 /18（16k 地址块），因此能够通过说来使其工作。

Where start <= value 
And start >= value-32786
And end >= value
And end <= value+32768

推荐阅读