Indexing policies in Azure Cosmos DB

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

In Azure Cosmos DB, every container has an indexing policy that dictates how the container's items should be indexed. The default indexing policy for newly created containers indexes every property of every item and enforces range indexes for any string or number. This allows you to get good query performance without having to think about indexing and index management upfront.

In some situations, you may want to override this automatic behavior to better suit your requirements. 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.

Megjegyzé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.

Megjegyzé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 tapasztal 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 az alkalmazottak tulajdonságát, de nem indexelnénk 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ívan 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 definiálva.

A kifejezetten belefoglalt elérési utak mindegyikében a tároló minden eleméhez hozzá lesznek adva értékek az indexhez, 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.

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 skaláris é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ő).

Megjegyzé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 orderORDER 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 lesz, kevesebb időt vesz igénybe, és kevesebb kérelemegységet vesz igénybe, ha képes összetett indexet használni.(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 lesz 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 lesz 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 index is előnyére vá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és újraírható egy összetett index használatá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ágokkal rendelkező lekérdezésekhez, valamint a több tulajdonságon szűrővel rendelkező lekérdezésekhez továbbra is érvényesek az összetett indexek ORDER BY létrehozásának szempontjai.
Ö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 jelentősen 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, amelyet online és helyben hajt végre (í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. Az indexátalakítás által felhasznált kérelemegységek számlázása jelenleg nem történik meg kiszolgáló nélküli tárolók használata esetén. Ezek a kérelemegységek a kiszolgáló nélküli általános elérhetővé válás után lesznek számlázva.

Megjegyzé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.

Megjegyzé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 hatással van, míg egy új index hozzáadása egy ideig tart, 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. This means that:

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

További lépések

Az indexelésről az alábbi cikkekben olvashat bővebben: