Това очаквана ли е производителност на заявка от CosmosDB за между заявки за свойство на цяло число

Имам колекция cosmosdb (sql api), която съм попълнил с документи, представляващи CIDR мрежови диапазони.

Съответната част от всеки документ е

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

Всеки CIDR блок има своя начален и краен IP адрес, преобразуван в uint и съхранен в свойствата 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": []
}

azure performance azure-cosmosdb indexing
person Eoin Campbell    schedule 16.06.2018    source източник
comment
Знам, че сте решили проблема си, но... само за информация, че няма нужда да указвате изрично включването на двете свойства във вашия план за индексиране, тъй като вече сте имали заместващ знак, включващ всички свойства.   -  person David Makogon    schedule 17.06.2018

Отговори (1)


arrow_upward
0
arrow_downward

Мисля, че го реших. Проблемът произтичаше от факта, че имах заявка за по-голямо от едно свойство и заявка за по-малко от друго свойство.

Изглежда, че cosmos обединява пълния набор от документи, които отговарят на всяка независима филтърна клауза.

Тъй като най-големият CIDR диапазон в комплекта беше /18 (16k адресен блок), успях да го накарам да работи, като каза.

Where start <= value 
And start >= value-32786
And end >= value
And end <= value+32768
person Eoin Campbell    schedule 16.06.2018