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 automatic
van á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 isemployees
/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
Feljegyzés
A teljes szöveges index megadásához engedélyeznie kell a Full Text > Hybrid Search for NoSQL API előzetes verzióját.
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"
}
]
}
Fontos
A teljes szöveges indexelési szabályzatnak a tároló teljes szöveges szabályzatában meghatározott elérési úton kell lennie. További információ a tárolóvektor-szabályzatokról.
Vektorindexek
Feljegyzés
A vektorindex megadásához engedélyeznie kell az Azure Cosmos DB NoSQL Vector Search szolgáltatást .
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 |
Fontos
A vektorszabályzatok és a vektorindexek jelenleg nem módosíthatók a létrehozás után. A módosítások elvégzéséhez hozzon létre egy új gyűjteményt.
Néhány megjegyzés:
Az
flat
indextípusok azquantizedFlat
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ói505
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éggelquantized flat
kell rendelkeznie, mint egyflat
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, mintquantizedFlat
vagyflat
.
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 mindquantizedFlat
azDiskANN
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 azDiskANN
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"
}
]
}
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.
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.
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.
Feljegyzés
A belefoglalt vagy kizárt elérési utaktól eltérően nem hozhat létre elérési utat a /* helyettesítő karakterrel. Minden útnak "/?" végződéssel kell végződnie. Ha egy rekord elérési útjának rekordja nem létezik egy elemben, a rendszer hozzáad egy értéket az indexhez, amely jelzi, hogy a rekord nincs definiálva.
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
/
- A kukák a bevezetővel kezdődnek
/events/[]/{name/?,category/?}/?
- A csuples egy
?
- 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ő).
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:
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:
Ö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 aORDER 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
vagyDESC
) 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 |
Ö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.
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
none
van á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.