我有一个cosmosdb集合(sql api),我已经填充了代表CIDR网络范围的文档 .
每个文件的相关部分是
{
"Network": "31.216.102.0/23",
"IPRangeStart": 534275584,
"IPRangeEnd": 534276095,
每个CIDR块都将其起始和结束IP地址转换为 uint
并存储在hte RangeStart
和 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": []
}
1 回答
想想我解决了 . 问题源于这样一个事实,即我对一个属性的查询大于查询,而对不同的属性查询的查询少于查询 .
宇宙似乎正在合并满足每个独立过滤条款的全套文档 .
由于集合中最大的CIDR范围是/ 18(16k地址块),因此能够使其工作 .