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.

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.

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.

Teljes szöveges indexek

A teljes szöveges indexek lehetővé teszik a teljes szöveges keresést és a pontozást az index használatával. Egy teljes szöveges elérési út indexelési szabályzatban való definiálása egyszerűen elvégezhető az indexelési szabályzat egy fullTextIndexes szakaszának beírásával, amely tartalmazza az összes indexelendő szöveges elérési utat. Példa:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/\"_etag\"/?"
        },
    ],
    "fullTextIndexes": [
        {
            "path": "/text"
        }
    ]
}

Vektorindexek

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:

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.

Az diskANN és quantizedFlat az indexek opcionális indexépítési paramétereket is igénybe vehetnek, amelyek a pontosság és a késés közötti kompromisszum finomhangolásához használhatók, amelyek minden közelítő szomszéd vektorindexre vonatkoznak.

• quantizationByteSize: A termékkvantálás méretét (bájtban) állítja be. Min=1, Default=dynamic (rendszer dönt), Max=512. A nagyobb beállítás nagyobb pontosságú vektorkereséseket eredményezhet a magasabb RU-költségek és a nagyobb késés rovására. Ez mind a mind quantizedFlat az DiskANN indextípusokra vonatkozik.
  • indexingSearchListSize: Beállítja, hogy hány vektort keressen át az index buildelése során. Min=10, Default=100, Max=500. A nagyobb beállítás nagyobb pontosságú vektorkereséseket eredményezhet a hosszabb indexépítési idők és a nagyobb vektorbetöltési késések rovására. Ez csak az DiskANN indexekre vonatkozik.

Í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"
        }
    ]
}

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.

Rekordindexek

A rekordindexek akkor hasznosak, ha egy tömbelem több mezőjén végez szűrést. A rekordindexek az indexelési szabályzat includedPaths szakaszában vannak definiálva a"[]" tuple-definícióval.

A tömbök elérési útjai a includedPaths szakaszban lesznek definiálva, és a következő jelölést fogják használni.

<path prefix>/[]/{<tuple 1>, <tuple 2> … <tuple n>}/?

Vegye figyelembe:

• Az első rész, az elérési út előtagja a kötőjelek között gyakori elérési út. Ez az elérési út a gyökértől a tömbig. A példánkban ez "/events".
• Ezután a "[]" tömb helyettesítő karaktert adja meg. Az összes tömbútvonalnak rendelkeznie kell egy tömb helyettesítő karakterrel a "{}" rekordkijelölő előtt.
• Ezután adja meg a rekordokat a "{}" rekordkijelölővel.
• A csuplokat vessző választja el egymástól.
• A Tuple-nak ugyanazt az elérési utat kell használnia, mint a többi indexútvonalat néhány kivétellel:
• A csuples nem kezdődhet a kezdő "/" karakterrel.
• A csuploknak nem szabad tömb helyettesítő karakterekkel rendelkezniük.
• A csuples nem végződhet "?" vagy "*"
• “?” a rekord elérési útjának utolsó szegmense, amelyet közvetlenül a rekordkijelölő szegmens után kell megadni.

Például,

/events/[]/{name, category}/?

Az alábbiakban néhány példát mutatunk be az érvényes tömbök elérési útjaira:

    “includedPaths”:[  
        {“path”: “/events/[]/{name/first, name/last}/?”}, 
        {“path”: “/events/[]/{name/first, category}/?”}, 
        {“path”: “/events/[]/{name/first, category/subcategory}/?”}, 
        {“path”: “/events/[]/{name/[1]/first, category}/?”}, 
        {“path”: “/events/[]/{[1], [3]}/?”}, 
        {“path”: “/city/[1]/events/[]/{name, category}/?”} 
    ]

Néhány példa az érvénytelen tömbök elérési útjaira

• /events/[]/{name/[]/first, category}/?
  • Az egyik tuples tömb helyettesítő karaktert kapott
• /events/[]/{name, category}/*
  • A tömbös elérési út utolsó szegmensének "?" és nem *
• /events/[]/{{name, first},category}/?
  • A rekordkijelölő beágyazott
• /events/{name, category}/?
  • A tömb helyettesítő karaktere hiányzik a rekordválasztó előtt
• /events/[]/{/name,/category}/?
  • A kukák a bevezetővel kezdődnek /
• /events/[]/{name/?,category/?}/?
  • A csuples egy ?
• /city/[]/events/[]/{name, category}/?
  • Az elérési út előtagja 2 tömb helyettesítő karakterként

Ö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ő).

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

A két vagy több tulajdonsággal rendelkező záradékkal rendelkező ORDER BY lekérdezések összetett indexeinek használatakor a következő szempontokat kell figyelembe venni.

• 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:

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:

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.

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 indexek tömb helyettesítő karakterrel

Az alábbiakban egy tömb helyettesítő karaktert tartalmazó összetett indexet mutatunk be.

{  
    "automatic":true,
    "indexingMode":"Consistent",
    "includedPaths":[  
        {  
            "path":"/*"
        }
    ],
    "excludedPaths":[],
    "compositeIndexes":[  
        [  
            {"path":"/familyname", "order":"ascending"},
            {"path":"/children/[]/age", "order":"descending"}
        ]
    ]
}

Az összetett index előnyeit kihasználó lekérdezések például a következőek:

SELECT r.id
FROM root r
JOIN ch IN r.children
WHERE r.familyname = 'Anderson' AND ch.age > 20

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.

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.

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