Az Azure Cosmos DB indexelési szabályzatai

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az Azure Cosmos DB-ben minden tároló rendelkezik indexelési szabályzattal, amely meghatározza a tároló elemeinek indexelési módját. Az újonnan létrehozott tárolók alapértelmezett indexelési szabályzata az összes elem minden tulajdonságát indexeli, és minden sztringhez vagy számhoz tartományindexeket kényszerít ki. Ez lehetővé teszi a nagy lekérdezési teljesítményt anélkül, hogy az indexelést és az indexkezelést előre át kellene gondolni.

Bizonyos esetekben érdemes lehet felülbírálni ezt az automatikus viselkedést, hogy jobban megfeleljen a követelményeknek. A tároló indexelési házirendjét testre szabhatja az indexelési mód beállításával, valamint a tulajdonságelérési útvonalak belefoglalásával vagy kizárásával.

Feljegyzés

A cikkben ismertetett indexelési szabályzatok frissítésének módja csak a NoSQL-hez készült Azure Cosmos DB API-ra vonatkozik. Az indexelés ismertetése a MongoDB-hez készült Azure Cosmos DB API-ban

Indexelési mód

Az Azure Cosmos DB két indexelési módot támogat:

• Konzisztens: Az index szinkron módon frissül az elemek létrehozása, frissítése vagy törlése során. Ez azt jelenti, hogy az olvasási lekérdezések konzisztenciája a fiók konzisztenciája lesz.
• Nincs: Az indexelés le van tiltva a tárolón. Ezt a módot általában akkor használják, ha egy tárolót tiszta kulcs-érték tárolóként használnak másodlagos indexek nélkül. A tömeges műveletek teljesítményének javítására is használható. A tömeges műveletek befejezése után az index mód konzisztensre állítható, majd az IndexTransformationProgress használatával monitorozható, amíg be nem fejeződik.

Feljegyzés

Az Azure Cosmos DB a lusta indexelési módot is támogatja. A szakaszolt indexelés sokkal alacsonyabb prioritási szinttel végzi el az index frissítését, tehát akkor, amikor a motor nem végez semmilyen más munkát. Ez inkonzisztens vagy hiányos lekérdezési eredményekhez vezethet. Ha azure Cosmos DB-tárolót szeretne lekérdezni, ne válassza a lusta indexelést. Az új tárolók nem választhatják a lusta indexelést. Kivételt kérhet a kapcsolatfelvétellel cosmosdbindexing@microsoft.com (kivéve, ha kiszolgáló nélküli módban használ Azure Cosmos DB-fiókot, amely nem támogatja a lusta indexelést).

Az indexelési szabályzat alapértelmezés szerint a következőre automaticvan állítva: . Ez úgy érhető el, hogy az automatic indexelési házirend tulajdonságát a következőre trueállítja: . A tulajdonság beállításával true az Azure Cosmos DB automatikusan indexelheti az elemeket írás közben.

Indexméret

Az Azure Cosmos DB-ben a teljes felhasznált tárterület az adatméret és az indexméret kombinációja. Az indexméret néhány funkciója a következő:

• Az index mérete az indexelési szabályzattól függ. Ha az összes tulajdonság indexelve van, akkor az index mérete nagyobb lehet, mint az adatméret.
• Az adatok törlésekor az indexek tömörítése közel folyamatos. Kis adattörlések esetén azonban előfordulhat, hogy nem észleli azonnal az index méretének csökkenését.
• A fizikai partíciók felosztásakor az index mérete átmenetileg növekedhet. Az indexterület a partíció felosztása után szabadul fel.

Tulajdonság-útvonalak belefoglalása és kizárása

Az egyéni indexelési szabályzatok olyan tulajdonságelérési útvonalakat is megadhatnak, amelyek kifejezetten bele vannak foglalva az indexelésbe, vagy kizárhatók az indexelésből. Az indexelt útvonalak számának optimalizálásával jelentősen csökkentheti az írási műveletek késését és RU-díját. Ezeket az elérési utakat az indexelés áttekintési szakaszában leírt módszer alapján definiáljuk az alábbi kiegészítésekkel:

• egy skaláris értékhez (sztringhez vagy számhoz) vezető elérési út a /?
• a tömb elemeit a rendszer a /[] jelöléssel együtt kezeli (ahelyett /0, hogy stb /1 .)
• a /* helyettesítő karakter használható a csomópont alatti elemek egyeztetésére

Ugyanezt a példát ismételje meg:

    {
        "locations": [
            { "country": "Germany", "city": "Berlin" },
            { "country": "France", "city": "Paris" }
        ],
        "headquarters": { "country": "Belgium", "employees": 250 },
        "exports": [
            { "city": "Moscow" },
            { "city": "Athens" }
        ]
    }

• az headquarters's path is employees/headquarters/employees/?

• az locations' country elérési út /locations/[]/country/?

• az út, hogy bármi alatt headquarters van /headquarters/*

Belefoglalhatjuk például az /headquarters/employees/? elérési utat. Ez az elérési út biztosítaná, hogy indexeljük a employees tulajdonságot, de nem indexelnénk a további beágyazott JSON-t ebben a tulajdonságban.

Stratégia belefoglalása/kizárása

Minden indexelési szabályzatnak tartalmaznia kell a gyökér elérési útját /* belefoglalt vagy kizárt elérési útként.

• Adja meg a gyökér elérési utat, hogy szelektíven kizárja az indexelendő útvonalakat. Ez a megközelítés ajánlott, mivel lehetővé teszi, hogy az Azure Cosmos DB proaktív módon indexelje a modellhez esetlegesen hozzáadott új tulajdonságokat.

• Zárja ki az indexelendő elérési utak szelektív belefoglalásához szükséges gyökér elérési utat. A partíciókulcs tulajdonságelérési útvonala alapértelmezés szerint nem indexelt a kizárási stratégiával, és szükség esetén kifejezetten szerepelnie kell benne.

• Az olyan normál karaktereket tartalmazó elérési utak esetében, amelyek tartalmazzák a következő karaktereket: alfanumerikus karakterek és _ (aláhúzásjel), nem kell feloldania az elérési út sztringet dupla idézőjelek (például "/path/?"). Más speciális karaktereket tartalmazó elérési utak esetében meg kell szabadulnia az elérési út sztringje elől a dupla idézőjelek (például "/"path-abc"/?"). Ha különleges karaktereket vár az útvonalon, a biztonság érdekében minden utat elkerülhet. Funkcionálisan ez nem jelent különbséget, ha elkerül minden útvonalat, vagy csak azokat, amelyek speciális karaktereket.

• A rendszertulajdonság _etag alapértelmezés szerint ki van zárva az indexelésből, kivéve, ha az etag hozzá van adva a belefoglalt indexelési útvonalhoz.

• Ha az indexelési mód konzisztensre van állítva, a rendszer tulajdonságai id és _ts automatikus indexelése történik.

• Ha egy explicit módon indexelt elérési út nem létezik egy elemben, a rendszer hozzáad egy értéket az indexhez, amely jelzi, hogy az elérési út nincs meghatározva.

Minden kifejezetten belefoglalt elérési út értékeket ad hozzá az indexhez a tároló minden eleméhez, még akkor is, ha az elérési út nincs meghatározva egy adott elemhez.

Ebben a szakaszban az elérési utak belefoglalására és kizárására vonatkozó házirend-példák indexelését tekinti meg.

Elsőbbség belefoglalása/kizárása

Ha a belefoglalt és a kizárt útvonalak ütközést mutatnak, a pontosabb elérési út elsőbbséget élvez.

Példa:

Tartalmazott elérési út: /food/ingredients/nutrition/*

Kizárt elérési út: /food/ingredients/*

Ebben az esetben a belefoglalt elérési út elsőbbséget élvez a kizárt útvonallal szemben, mert pontosabb. Ezen elérési utak alapján az food/ingredients elérési úton lévő vagy az abban beágyazott adatok ki lesznek zárva az indexből. Ez alól kivételt képeznek a belefoglalt elérési út adatai: /food/ingredients/nutrition/*az indexelt adatok.

Íme néhány szabály az Azure Cosmos DB-ben a belefoglalt és kizárt elérési utakra vonatkozóan:

• A mélyebb útvonalak pontosabbak, mint a keskenyebb útvonalak. például: /a/b/? pontosabb, mint /a/?.

• A /? pontosabb, mint /*. Például /a/? pontosabb, mint /a/* ez /a/? elsőbbséget élvez.

• Az elérési útnak /* belefoglalt vagy kizárt elérési útnak kell lennie.

Vektorindexek

Feljegyzés

A vektorindexelési szabályzat megadásához regisztrálnia kell az Azure Cosmos DB NoSQL Vektorindex előzetes verziójának funkcióját .>

A vektorindexek növelik a hatékonyságot a vektorkeresések rendszerfüggvény használatával VectorDistance történő végrehajtásakor. A vektorkeresések kisebb késéssel, nagyobb átviteli sebességgel és kevesebb RU-használattal rendelkeznek vektorindex alkalmazásakor. A vektorindex-szabályzatok alábbi típusait adhatja meg:

Típus	Leírás	Maximális méretek
flat	A vektorokat ugyanabban az indexben tárolja, mint a többi indexelt tulajdonságot.	505
quantizedFlat	Az indexen való tárolás előtt számszerűsíti (tömöríti) a vektorokat. Ez kis pontosság árán javíthatja a késést és az átviteli sebességet.	4096
diskANN	A DiskANN alapján létrehoz egy indexet a gyors és hatékony hozzávetőleges kereséshez.	4096

Néhány megjegyzés:

• Az flat indextípusok az quantizedFlat Azure Cosmos DB indexét alkalmazzák az egyes vektorok vektorkereséskor történő tárolására és olvasására. Az indexet tartalmazó flat vektorkeresések találgatásos keresések, amelyek 100%-os pontosságot vagy visszahívást eredményeznek. Ez azt jelenti, hogy garantáltan megtalálja az adathalmazban a leginkább hasonló vektorokat. A vektorok dimenziói 505 azonban korlátozottak egy lapos indexen.

• Az quantizedFlat index számszerűsített (tömörített) vektorokat tárol az indexen. Az indexet tartalmazó quantizedFlat vektorkeresések is találgatásos keresések, de pontosságuk valamivel kisebb lehet, mint 100%, mivel a vektorok kvantálva vannak az indexhez való hozzáadás előtt. A vektorkeresésnek azonban alacsonyabb késéssel, nagyobb átviteli sebességgel és alacsonyabb RU-költséggel quantized flat kell rendelkeznie, mint egy flat index vektorkeresésének. Ez egy jó lehetőség olyan helyzetekben, amikor lekérdezési szűrőkkel szűkíti a vektorkeresést viszonylag kis számú vektorra, és nagy pontosságra van szükség.

• Az diskANN index egy külön index, amely kifejezetten a DiskANN-t alkalmazó vektorokhoz van definiálva, amely a Microsoft Research által kifejlesztett nagy teljesítményű vektorindexelési algoritmusok csomagja. A DiskANN-indexek a legalacsonyabb késést, a legmagasabb átviteli sebességet és a legalacsonyabb ru-költség lekérdezéseket kínálhatják, miközben továbbra is magas pontosságot biztosítanak. Mivel azonban a DiskANN egy közelítő szomszéd (ANN) index, a pontosság kisebb lehet, mint quantizedFlat vagy flat.

Íme egy példa egy vektorindexkel rendelkező indexelési szabályzatra:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/_etag/?",
        },
        {
            "path": "/vector/*"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector",
            "type": "diskANN"
        }
    ]
}

Fontos

A vektorindexelési szabályzatnak a tároló vektorszabályzatában meghatározott elérési úton kell lennie. További információ a tárolóvektor-szabályzatokról. A vektorindexeket a tároló létrehozásakor is meg kell határozni, és a létrehozás után nem módosíthatók. Egy későbbi kiadásban a vektorindexek módosíthatók lesznek.

Fontos

Az indexelési szabályzat "excludedPaths" szakaszához hozzáadott vektorútvonal a beszúrás optimalizált teljesítményének biztosítása érdekében. Ha nem adja hozzá a vektor elérési útját a "excludedPaths" elemhez, az magasabb RU-díjat és késést eredményez a vektorbeszúrások esetében.

Térbeli indexek

Ha térbeli elérési utat határoz meg az indexelési szabályzatban, meg kell határoznia, hogy melyik indexet type kell alkalmazni az adott útvonalra. A térbeli indexek lehetséges típusai a következők:

• Pont

• Polygon

• MultiPolygon

• LineString

Az Azure Cosmos DB alapértelmezés szerint nem hoz létre térbeli indexeket. Ha beépített térbeli SQL-függvényeket szeretne használni, létre kell hoznia egy térbeli indexet a szükséges tulajdonságokon. Ez a szakasz a térbeli indexek hozzáadására vonatkozó házirend-példák indexelését ismerteti.

Összetett indexek

A két vagy több tulajdonsággal rendelkező záradékkal rendelkező ORDER BY lekérdezésekhez összetett indexre van szükség. Összetett indexet is meghatározhat számos egyenlőségi és tartomány-lekérdezés teljesítményének javítása érdekében. Alapértelmezés szerint nincs megadva összetett index, ezért szükség szerint összetett indexeket kell hozzáadnia.

A belefoglalt vagy kizárt elérési utaktól eltérően a helyettesítő karakterrel /* nem hozhat létre elérési utat. Minden összetett elérési út rendelkezik implicit módon /? annak az elérési útnak a végén, amelyet nem kell megadnia. Az összetett útvonalak olyan skaláris értéket eredményeznek, amely az összetett index egyetlen értéke. Ha egy összetett index elérési útja nem létezik egy elemben, vagy nem skálázási értékhez vezet, a rendszer hozzáad egy értéket az indexhez, amely azt jelzi, hogy az elérési út nincs meghatározva.

Összetett index definiálásakor a következőket kell megadnia:

• Két vagy több tulajdonságútvonal. A tulajdonságútvonalak meghatározásának sorrendje számít.

• A sorrend (növekvő vagy csökkenő).

Feljegyzés

Összetett index hozzáadásakor a lekérdezés a meglévő tartományindexeket fogja használni, amíg az új összetett index hozzáadása be nem fejeződik. Ezért ha összetett indexet ad hozzá, előfordulhat, hogy nem figyeli meg azonnal a teljesítménybeli javulást. Az indexátalakítás előrehaladását az egyik SDK használatával követheti nyomon.

ORDER BY lekérdezések több tulajdonságon:

Az összetett indexek két vagy több tulajdonságokkal rendelkező záradékkal rendelkező ORDER BY lekérdezésekhez az alábbi szempontokat használják:

• Ha az összetett index elérési útjai nem egyeznek a záradék tulajdonságainak sorrendjével ORDER BY , akkor az összetett index nem tudja támogatni a lekérdezést.

• Az összetett index elérési útjainak (növekvő vagy csökkenő) sorrendjének is meg kell egyeznie a order ORDER BY záradékban megadott sorrenddel.

• Az összetett index egy olyan záradékot ORDER BY is támogat, amely minden útvonalon ellentétes sorrendben jelenik meg.

Tekintse meg az alábbi példát, ahol a tulajdonságok neve, életkora és _ts alapján határoz meg összetett indexet:

Összetett index	Minta ORDER BY lekérdezés	Támogatja az összetett index?
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age asc	Yes
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.age ASC, c.name asc	No
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name DESC, c.age DESC	Yes
(name ASC, age ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age DESC	No
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age ASC, timestamp ASC	Yes
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c ORDER BY c.name ASC, c.age ASC	No

Testre kell szabnia az indexelési szabályzatot, hogy az összes szükséges ORDER BY lekérdezést kiszolgálhassa.

A több tulajdonság alapján szűrt lekérdezések

Ha egy lekérdezés két vagy több tulajdonságon rendelkezik szűrőkkel, hasznos lehet összetett indexet létrehozni ezekhez a tulajdonságokhoz.

Vegyük például a következő lekérdezést, amely egyenlőség- és tartományszűrővel is rendelkezik:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18

Ez a lekérdezés hatékonyabb, kevesebb időt vesz igénybe, és kevesebb kérelemegységet vesz igénybe, ha képes összetett indexet alkalmazni.(name ASC, age ASC)

A több tartományszűrővel rendelkező lekérdezések összetett indexekkel is optimalizálhatók. Az egyes összetett indexek azonban csak egyetlen tartományszűrőt képesek optimalizálni. A tartományszűrők közé tartoznak a >következők: , <, <=, >=és !=. A tartományszűrőt utoljára az összetett indexben kell definiálni.

Vegye figyelembe a következő lekérdezést egyenlőségszűrővel és két tartományszűrővel:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18 AND c._ts > 1612212188

Ez a lekérdezés hatékonyabb egy összetett index be- (name ASC, age ASC) és (name ASC, _ts ASC)bekapcsolásához. A lekérdezés azonban nem használna összetett indexet (age ASC, name ASC) , mert az egyenlőségi szűrőkkel rendelkező tulajdonságokat először az összetett indexben kell meghatározni. Egyetlen összetett index (name ASC, age ASC, _ts ASC) helyett két különálló összetett indexre van szükség, mivel minden összetett index csak egyetlen tartományszűrőt képes optimalizálni.

A következő szempontokat kell figyelembe venni a több tulajdonságon lévő szűrőkkel rendelkező lekérdezések összetett indexeinek létrehozásakor

• A szűrőkifejezések több összetett indexet is használhatnak.
• A lekérdezés szűrőjének tulajdonságainak meg kell egyeznie az összetett indexben találhatóakkal. Ha egy tulajdonság az összetett indexben található, de szűrőként nem szerepel a lekérdezésben, a lekérdezés nem használja az összetett indexet.
• Ha egy lekérdezés más tulajdonságokkal is rendelkezik a szűrőben, amelyek nincsenek összetett indexben definiálva, akkor a rendszer összetett és tartományindexek kombinációját használja a lekérdezés kiértékeléséhez. Ehhez kevesebb kérelemegységre van szükség, mint kizárólag tartományindexek használatával.
• Ha egy tulajdonság tartományszűrővel (>, , <, <=, >=vagy !=) rendelkezik, akkor ezt a tulajdonságot utoljára az összetett indexben kell definiálni. Ha egy lekérdezés több tartományszűrővel is rendelkezik, több összetett indexet is használhat.
• Ha összetett indexet hoz létre több szűrővel rendelkező lekérdezések optimalizálásához, az ORDER összetett indexnek nincs hatása az eredményekre. Ez a tulajdonság opcionális.

Vegye figyelembe az alábbi példákat, amelyekben a tulajdonságok neve, életkora és időbélyege alapján van meghatározva az összetett index:

Összetett index	Minta lekérdezés	Támogatja az összetett index?
(name ASC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age = 18	Yes
(name ASC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name ASC, age ASC)	SELECT COUNT(1) FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name DESC, age ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age > 18	Yes
(name ASC, age ASC)	SELECT * FROM c WHERE c.name != "John" AND c.age > 18	No
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 123049923	Yes
(name ASC, age ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp = 123049923	No
(name ASC, age ASC) and (name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp > 123049923	Yes

Lekérdezések szűrővel és ORDER BY

Ha egy lekérdezés egy vagy több tulajdonságra szűr, és az ORDER BY záradék eltérő tulajdonságokkal rendelkezik, hasznos lehet a szűrő tulajdonságait hozzáadni a ORDER BY záradékhoz.

Ha például hozzáadja a szűrő tulajdonságait a ORDER BY záradékhoz, a következő lekérdezést újra lehet írni egy összetett index alkalmazásához:

Lekérdezés tartományindex használatával:

SELECT *
FROM c 
WHERE c.name = "John" 
ORDER BY c.timestamp

Lekérdezés összetett index használatával:

SELECT * 
FROM c 
WHERE c.name = "John"
ORDER BY c.name, c.timestamp

A szűrőkkel rendelkező lekérdezések esetében ORDER BY ugyanezek a lekérdezésoptimalizálások általánosíthatók, szem előtt tartva, hogy az egyes összetett indexek legfeljebb egy tartományszűrőt támogatnak.

Lekérdezés tartományindex használatával:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.timestamp

Lekérdezés összetett index használatával:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.name, c.age, c.timestamp

Emellett összetett indexekkel optimalizálhatja a lekérdezéseket rendszerfüggvényekkel és ORDER BY:

Lekérdezés tartományindex használatával:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.lastName

Lekérdezés összetett index használatával:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.firstName, c.lastName

Az összetett indexek létrehozásakor a következő szempontok vonatkoznak egy szűrővel és ORDER BY záradékkal rendelkező lekérdezés optimalizálásához:

• Ha nem határoz meg összetett indexet egy olyan lekérdezésen, amely egy tulajdonság szűrőjével és egy másik tulajdonságot használó külön ORDER BY záradékkal rendelkezik, a lekérdezés továbbra is sikeres lesz. A lekérdezés RU-költsége azonban csökkenthető összetett indexekkel, különösen akkor, ha a ORDER BY záradék tulajdonsága nagy számossággal rendelkezik.
• Ha a lekérdezés tulajdonságokra szűr, ezeket a tulajdonságokat először a ORDER BY záradékban kell szerepeltetni.
• Ha a lekérdezés több tulajdonságra is szűr, az egyenlőségi szűrőknek a záradék első tulajdonságainak kell lenniük ORDER BY .
• Ha a lekérdezés több tulajdonságra is szűr, összetett indexenként legfeljebb egy tartományszűrő vagy rendszerfüggvény használható. A tartományszűrőben vagy a rendszerfüggvényben használt tulajdonságot utoljára az összetett indexben kell meghatározni.
• A több tulajdonsággal rendelkező lekérdezésekhez és a több tulajdonságokkal rendelkező szűrőkkel rendelkező lekérdezésekhez továbbra is alkalmazni kell az összetett indexek ORDER BY létrehozását.

Összetett index	Minta ORDER BY lekérdezés	Támogatja az összetett index?
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.name ASC, c.timestamp ASC	Yes
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" AND c.timestamp > 1589840355 ORDER BY c.name ASC, c.timestamp ASC	Yes
(timestamp ASC, name ASC)	SELECT * FROM c WHERE c.timestamp > 1589840355 AND c.name = "John" ORDER BY c.timestamp ASC, c.name ASC	No
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC, c.name ASC	No
(name ASC, timestamp ASC)	SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC	No
(age ASC, name ASC, timestamp ASC)	SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.age ASC, c.name ASC,c.timestamp ASC	Yes
(age ASC, name ASC, timestamp ASC)	SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.timestamp ASC	No

Lekérdezések szűrővel és összesítéssel

Ha egy lekérdezés egy vagy több tulajdonságra szűr, és aggregátumrendszer-függvénnyel rendelkezik, hasznos lehet összetett indexet létrehozni a szűrő- és összesítőrendszerfüggvény tulajdonságaihoz. Ez az optimalizálás a SZUM és az AVG rendszerfüggvényekre vonatkozik.

Az összetett indexek létrehozásakor a következő szempontok vonatkoznak a lekérdezések szűrő- és összesítőrendszerfüggvényekkel való optimalizálására.

• Az összetett indexek nem kötelezőek, ha összesítő lekérdezéseket futtatnak. A lekérdezés ru-költségei azonban gyakran csökkenthetők összetett indexekkel.
• Ha a lekérdezés több tulajdonságra is szűr, az egyenlőségi szűrőknek az összetett index első tulajdonságainak kell lenniük.
• Összetett indexenként legfeljebb egy tartományszűrővel rendelkezhet, és az aggregátumrendszer-függvény tulajdonságán kell lennie.
• Az összesített rendszerfüggvény tulajdonságát utoljára az összetett indexben kell meghatározni.
• A order (ASC vagy DESC) nem számít.

Összetett index	Minta lekérdezés	Támogatja az összetett index?
(name ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"	Yes
(timestamp ASC, name ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"	No
(name ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name > "John"	No
(name ASC, age ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age = 25	Yes
(age ASC, timestamp ASC)	SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age > 25	No

Az indexelési szabályzat módosítása

A tároló indexelési szabályzata bármikor frissíthető az Azure Portal vagy valamelyik támogatott SDK használatával. Az indexelési szabályzat frissítése a régi indexről az újra való átalakítást váltja ki, amely online és helyben történik (így a művelet során nem használ fel további tárhelyet). A régi indexelési szabályzat hatékonyan át lesz alakítva az új szabályzatra anélkül, hogy befolyásolná az írási rendelkezésre állást, az olvasási rendelkezésre állást vagy a tárolón kiosztott átviteli sebességet. Az indexátalakítás aszinkron művelet, és a befejezéshez szükséges idő a kiosztott átviteli sebességtől, az elemek számától és méretétől függ. Ha több indexelési szabályzatfrissítést kell végrehajtani, javasoljuk, hogy az összes módosítást egyetlen műveletként végezze el, hogy az indexátalakítás a lehető leggyorsabban befejeződjön.

Fontos

Az indexátalakítás kérelemegységeket használó művelet.

Feljegyzés

Az indexátalakítás előrehaladását az Azure Portalon vagy az egyik SDK használatával követheti nyomon.

Az indexátalakítások során nincs hatással az írási rendelkezésre állásra. Az indexátalakítás a kiosztott kérelemegységeket használja, de alacsonyabb prioritással, mint a CRUD-műveletek vagy -lekérdezések.

Új indexelt elérési utak hozzáadásakor nincs hatással az olvasási rendelkezésre állásra. A lekérdezések csak akkor használják az új indexelt elérési utakat, ha az indexátalakítás befejeződött. Más szóval, ha új indexelt elérési utat ad hozzá, az indexelt elérési út előnyeit élvező lekérdezések ugyanolyan teljesítménnyel rendelkeznek az indexátalakítás előtt és alatt. Az indexátalakítás befejezése után a lekérdezési motor elkezdi használni az új indexelt elérési utakat.

Az indexelt útvonalak eltávolításakor az összes módosítást egyetlen indexelési szabályzatátalakításba kell csoportosítania. Ha több indexet távolít el, és egyetlen indexelési házirend-módosítással teszi ezt meg, a lekérdezési motor konzisztens és teljes eredményeket biztosít az indexátalakítás során. Ha azonban több indexelési szabályzat módosításával távolítja el az indexeket, a lekérdezési motor nem biztosít konzisztens vagy teljes eredményeket, amíg az összes indexátalakítás be nem fejeződik. A fejlesztők többsége nem ejti le az indexeket, majd azonnal megpróbál olyan lekérdezéseket futtatni, amelyek ezeket az indexeket használják, így a gyakorlatban ez a helyzet nem valószínű.

Az indexelt elérési út elvetésekor a lekérdezési motor azonnal leáll, és ehelyett teljes vizsgálatot végez.

Feljegyzés

Ahol lehetséges, mindig próbáljon meg több indexeltávolítást egyetlen indexelési házirend-módosításba csoportosítani.

Fontos

Az index eltávolítása azonnal érvénybe lép, míg egy új index hozzáadása némi időt vesz igénybe, mivel az indexelési átalakítást igényel. Ha egy indexet lecserél egy másikra (például egy tulajdonságindexet összetett indexre cserél), először adja hozzá az új indexet, majd várja meg, amíg az indexátalakítás befejeződik , mielőtt eltávolítja az előző indexet az indexelési szabályzatból. Ellenkező esetben ez negatívan befolyásolja az előző index lekérdezésének képességét, és megszakíthatja az előző indexre hivatkozó aktív számítási feladatokat.

Indexelési szabályzatok és TTL

Az élettartam (TTL) funkció használatához indexelésre van szükség. Ez azt jelenti, hogy:

• nem lehet aktiválni a TTL-t olyan tárolón, ahol az indexelési mód a következőre nonevan állítva:
• az indexelési módot nem lehet None értékre állítani egy olyan tárolón, ahol a TTL aktiválva van.

Olyan forgatókönyvek esetén, ahol nem kell indexelni a tulajdonság elérési útját, de TTL-ra van szükség, indexelési házirendet használhat indexelési móddal consistent, nem tartalmazott elérési utakat, és /* az egyetlen kizárt elérési utat.

Kapcsolódó tartalom

• Indexelés áttekintése
• Indexelési szabályzat kezelése