Zásady indexování v Azure Cosmos DB

  • Platí pro: ✅ NoSQL

V Azure Cosmos DB má každý kontejner zásadu indexování, která určuje, jak se mají položky kontejneru indexovat. Výchozí zásady indexování pro nově vytvořené kontejnery indexují všechny vlastnosti všech položek a u všech řetězců a čísel vynucují indexy rozsahu. Díky tomu můžete dosáhnout vysokého výkonu dotazů, aniž byste předem museli myslet na indexování a správu indexů.

V některých situacích můžete chtít toto automatické chování přepsat, aby lépe vyhovovalo vašim požadavkům. Zásady indexování kontejneru můžete přizpůsobit nastavením režimu indexování a zahrnutím nebo vyloučením vlastnostních cest.

Note

Metoda aktualizace zásad indexování popsaných v tomto článku se vztahuje pouze na rozhraní API Azure Cosmos DB pro NoSQL. Informace o indexování v rozhraní API Azure Cosmos DB pro MongoDB

Režim indexování

Azure Cosmos DB podporuje dva režimy indexování:

  • Konzistentní: Index se při vytváření, aktualizaci nebo odstraňování položek aktualizuje synchronně. To znamená, že konzistence vašich dotazů pro čtení bude konzistencí nakonfigurovaná pro účet.
  • Žádné: Indexování je v kontejneru zakázané. Tento režim se běžně používá, když se kontejner používá jako čisté úložiště klíč-hodnota bez nutnosti sekundárních indexů. Dá se také použít ke zlepšení výkonu hromadných operací. Po dokončení hromadných operací je možné režim indexu nastavit na Konzistentní a pak monitorovat pomocí indexTransformationProgress , dokud nebude dokončen.

Note

Azure Cosmos DB podporuje také opožděný režim indexování. Opožděné indexování provádí aktualizace indexu na nižší úrovni priority, když modul neprovádí žádnou jinou práci. To může vést k nekonzistentním nebo neúplným výsledkům dotazů. Pokud plánujete dotazovat Azure Cosmos DB kontejner, neměli byste vybírat opožděné indexování. Nové kontejnery nemůžou vybrat opožděné indexování. Výjimku můžete požádat kontaktováním cosmosdbindexing@microsoft.com (s výjimkou případů, kdy používáte účet Azure Cosmos DB v režimu serverless, který nepodporuje opožděné indexování).

Velikost indexu

V Azure Cosmos DB je celkové spotřebované úložiště kombinací velikosti dat i velikosti indexu. Tady jsou některé funkce velikosti indexu:

  • Velikost indexu závisí na zásadách indexování. Pokud jsou indexovány všechny vlastnosti, může být velikost indexu větší než velikost dat.
  • Při odstranění dat se indexy komprimují téměř nepřetržitě. U malých odstranění dat však nemusíte okamžitě pozorovat snížení velikosti indexu.
  • Velikost indexu se může dočasně zvětšit, když se fyzické oddíly rozdělí. Po dokončení rozdělení diskového oddílu bude uvolněn prostor indexu.

Important

Klíč oddílu (pokud není také "/ID") není indexován a měl by být zahrnut do indexu. Klíče oddílů nevyžadují indexování, aby fungovaly, ale pokud je nezahrnete do zásad indexování, všechny dotazy filtrující na hierarchii klíčů oddílů budou chtít plné prohledávání, což vede k vyšší spotřebě RU. V případě hierarchických partitionních klíčů chcete do politiky indexování zahrnout jednotlivé úrovně hierarchie partitionních klíčů, abyste zajistili efektivní výkon dotazů.

  • ID systémových vlastností a _ts se vždy indexují, když je režim indexování účtu Cosmos na konzistentní.
  • ID systémových vlastností a _ts nejsou zahrnuty do popisu indexovaných cest zásad kontejneru. Důvodem je návrh, protože tyto systémové vlastnosti jsou ve výchozím nastavení indexovány a toto chování nelze zakázat.

Zahrnutí a vyloučení cest vlastností

Vlastní zásada indexování může určovat cesty vlastností, které jsou explicitně zahrnuty nebo vyloučeny z indexování. Optimalizací počtu indexovaných cest můžete podstatně snížit latenci a poplatky za RU operací zápisu. Tyto cesty jsou definovány podle metody popsané v části přehledu indexování s následujícími dodatky:

  • cesta vedoucí ke skalární hodnotě (řetězec nebo číslo) končí na /?
  • prvky z pole jsou adresovány společně notací /[] (místo /0, /1 atd.).
  • /* Zástupný znak lze použít k propojení s libovolnými prvky pod uzlem.

Opětovné provedení stejného příkladu:

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

  • headquarters employees cesta je /headquarters/employees/?

  • locations' country cesta je /locations/[]/country/?

  • cesta k čemukoliv, co je pod headquarters, je /headquarters/*

Mohli bychom například zahrnout /headquarters/employees/? cestu. Tato cesta zajistí, že vlastnost employees indexujeme, ale nebudeme indexovat přídatně vnořený JSON v rámci této vlastnosti.

Strategie zahrnutí/vyloučení

Všechny zásady indexování musí obsahovat kořenovou cestu /* jako zahrnutou nebo vyloučenou cestu.

  • Pokud chcete selektivně vyloučit cesty, které nemusí být indexované, zahrňte kořenovou cestu. Tento přístup se doporučuje, protože umožňuje Azure Cosmos DB proaktivně indexovat všechny nové vlastnosti, které mohou být přidány do modelu.

  • Vylučte kořenovou cestu, aby selektivně zahrnovala cesty, které je potřeba indexovat. Cesta vlastnosti klíče oddílu se ve výchozím nastavení neindexuje se strategií vyloučení a v případě potřeby by měla být explicitně zahrnuta.

  • U cest s běžnými znaky, které zahrnují alfanumerické znaky a _ (podtržítko), nemusíte text cesty uzavírat do dvojitých uvozovek (například "/path/?"). U cest s jinými speciálními znaky je nutné zapsat cestu do uvozovek (například "/\"path-abc\"/?"). Pokud očekáváte ve své cestě speciální znaky, můžete utéct každou cestu pro bezpečnost. Z funkčního hlediska nezáleží, jestli escapujete všechny cesty, anebo jen ty, které obsahují speciální znaky.

  • Systémová vlastnost _etag je ve výchozím nastavení vyloučena z indexování, pokud není přidána etag do zahrnuté cesty pro indexování.

  • Pokud je režim indexování nastaven na konzistentní, systémové vlastnosti id a _ts jsou automaticky indexovány.

  • Pokud explicitně indexovaná cesta v položce neexistuje, přidá se do indexu hodnota, která označuje, že cesta není definována.

Všechny explicitně zahrnuté cesty mají hodnoty přidané do indexu pro každou položku v kontejneru, i když je cesta pro danou položku nedefinovaná.

V této části najdete příklady zásad indexování pro zahrnutí a vyloučení cest.

Zahrnutí nebo vyloučení priority

Pokud mezi zahrnutými a vyloučenými cestami dochází ke konfliktu, přednost má ta, která je přesnější.

Tady je příklad:

Zahrnutá cesta: /food/ingredients/nutrition/*

Vyloučená cesta: /food/ingredients/*

V tomto případě má zahrnutá cesta přednost před vyloučenou cestou, protože je přesnější. Na základě těchto cest by byla jakákoli data v food/ingredients cestě nebo v ní vnořená vyloučena z indexu. Výjimkou by byla data v zahrnuté cestě: /food/ingredients/nutrition/*, která by byla indexována.

Tady jsou některá pravidla pro prioritu zahrnutých a vyloučených cest v Azure Cosmos DB:

  • Hlubší cesty jsou přesnější než užší cesty. Například: /a/b/? je přesnější než /a/?.

  • Je /? přesnější než /*. Například /a/? je přesnější, než /a/* má /a/? přednost.

  • Cesta /* musí být zahrnutá nebo vyloučená cesta.

Fulltextové indexy

Note

Chcete-li zadat fulltextový index, musíte povolit funkci FullText & Hybrid Search pro rozhraní API NoSQL .

Fulltextové indexy umožňují efektivní vyhledávání a hodnocení textu pomocí indexu. Definování úplné textové cesty v zásadách indexování lze snadno provést zahrnutím fullTextIndexes části zásad indexování, která obsahuje všechny textové cesty, které se mají indexovat. Například:

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

Important

Zásady indexování fulltextu musí být umístěny na cestě, která je definována v zásadách fulltextového kontejneru. Přečtěte si další informace o zásadách vektoru kontejneru.

Vektorové indexy

Note

Chcete-li zadat vektorový index, musíte povolit funkci Azure Cosmos DB NoSQL Vektorové vyhledávání.

Vektorové indexy zvyšují efektivitu při provádění vektorových hledání pomocí VectorDistance systémové funkce. Při použití vektorového indexu mají vyhledávání vektorů nižší latenci, vyšší propustnost a nižší spotřebu RU. Můžete zadat následující typy zásad indexu vektorů:

Typ Description Maximální rozměry
flat Ukládá vektory do stejného indexu jako ostatní indexované vlastnosti. 505
quantizedFlat Kvantuje (komprimuje) vektory před uložením do indexu. To může zlepšit latenci a propustnost za cenu malé přesnosti. 4096
diskANN Vytvoří index založený na diskANN pro rychlé a efektivní přibližné vyhledávání. 4096

Important

V současné době jsou vektorové zásady a indexy vektorů neměnné po vytvoření. Pokud chcete provést změny, vytvořte novou kolekci.

Několik bodů na poznámku:

  • Typy indexů flat a quantizedFlat používají index Azure Cosmos DB k ukládání a čtení jednotlivých vektorů při provádění vektorového vyhledávání. Vektorové vyhledávání s flat indexem je vyhledávání hrubou silou a zaručuje 100% přesnost nebo zachycení. To znamená, že zaručuje nalezení nejvíce podobných vektorů v datové sadě. Existují však omezení 505 dimenzí vektorů na plochém indexu.

    • Index quantizedFlat ukládá do indexu kvantované (komprimované) vektory. Vektorové vyhledávání s indexem quantizedFlat jsou také hrubou silou hledání, ale jejich přesnost může být o něco menší než 100 %, protože vektory jsou před přidáním do indexu kvantovány. Vektorové vyhledávání pomocí quantized flat by mělo mít nižší latenci, vyšší propustnost a nižší náklady na jednotky požadavků (RU) než vektorové vyhledávání v indexu flat. Tato možnost je vhodná pro scénáře, ve kterých používáte filtry dotazů k zúžení vektorového vyhledávání na relativně malou sadu vektorů a vyžaduje se vysoká přesnost.

    • Index diskANN je samostatný index definovaný speciálně pro vektory, které používají DiskANN, sadu algoritmů indexování vektorů s vysokým výkonem vyvinutých Microsoft Research. Indexy DiskANN můžou nabízet některé dotazy s nejnižší latencí, nejvyšší propustností a nejnižšími náklady na RU a přitom zachovat vysokou přesnost. Vzhledem k tomu, že diskANN je přibližný index nejbližších sousedů (ANN), může být přesnost nižší než quantizedFlat nebo flat.

diskANN a quantizedFlat indexy můžou využívat volitelné parametry pro sestavení indexu, které se dají použít k ladění kompromisu mezi přesností a latencí, které platí pro každý index vektoru Přibližně nejbližších sousedů.

  • quantizationByteSize: Nastaví velikost (v bajtech) pro kvantování produktu. Min=1, Default=dynamic (systém rozhoduje), Max=512. Nastavení na vyšší hodnotu může vést k vyšší přesnosti vektorového vyhledávání, avšak za cenu vyšších nákladů na RU a delší latence. To platí pro oba typy indexů quantizedFlat a DiskANN.
    • indexingSearchListSize: Nastaví, kolik vektorů se má prohledávat během sestavování indexů. Min=10, Default=100, Max=500. Nastavení tohoto parametru na vyšší hodnotu může vést k vyšší přesnosti vektorových vyhledávání na úkor delší doby sestavení indexu a vyšší latenci při ingestování vektorů. To platí jenom pro DiskANN indexy.

Tady je příklad zásady indexování s vektorovým indexem:

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

Important

Zásada indexování vektorů musí být na cestě definované v zásadě vektoru kontejneru. Přečtěte si další informace o zásadách vektoru kontejneru.

Prostorové indexy

Při definování prostorové cesty v zásadách indexování byste měli definovat, který index type se má na tuto cestu použít. Mezi možné typy prostorových indexů patří:

  • Point

  • Polygon

  • MultiPolygon

  • LineString

Azure Cosmos DB ve výchozím nastavení nevytváří žádné prostorové indexy. Pokud chcete použít předdefinované funkce prostorového SQL, měli byste pro požadované vlastnosti vytvořit prostorový index. V této části najdete příklady zásad indexování pro přidání prostorových indexů.

Indexy systémové řazené n-tice

Indexy řazené kolekce členů jsou užitečné při filtrování více polí v rámci prvku pole. Indexy typu tuple jsou definovány v části includedPaths zásad indexování pomocí specifikátoru "[]".

Note

Na rozdíl od zahrnutých nebo vyloučených cest nemůžete vytvořit cestu se zástupným znakem /*. Každá cesta k-tice musí končit "/?". Pokud n-tice v cestě n-tice v položce neexistuje, přidá se do indexu hodnota označující, že n-tice není definovaná.

Cesty řazené kolekce členů pole jsou definovány v části includedPaths a budou používat následující zápis.

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

Všimněte si, že:

  • První část, předpona cesty, je cesta, která se sdílí mezi n-ticemi. Je to cesta z kořenového adresáře do pole. V našem příkladu je to /events.
  • Dále je specifikátor zástupného znaku pole "[]". Všechny cesty prvků pole by měly mít zástupný znak pole před specifikátorem pro prvky "{}".
  • Dále je specifikování n-tic pomocí specifikátoru n-tice "{}".
  • n-tice budou odděleny čárkou.
  • Řazená dvojice musí používat stejnou specifikaci cesty jako jiné cesty indexu s několika výjimkami:
  • N-tice by neměly začínat úvodním znakem /.
  • Řazené kolekce členů by neměly obsahovat zástupné řady.
  • N-tice by neměly končit "?" nebo "*".
  • "?" je poslední úsek v cestě ve formátu n-tice a měl by být zadán bezprostředně za segmentem specifikátoru n-tice.

Příklad:

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

Tady je několik příkladů platných cest řazené kolekce členů pole:

    "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}/?"} 
    ]

Toto je několik příkladů neplatných cest pole typu tuple.

  • /events/[]/{name/[]/first, category}/?
    • Jeden z n-tic má zástupný znak v poli.
  • /events/[]/{name, category}/*
    • Poslední segment v cestě řazené kolekce členů pole by měl být "?" a ne *
  • /events/[]/{{name, first},category}/?
    • Specifikátor n-tice je vnořený.
  • /events/{name, category}/?
    • Před specifikátorem řazené kolekce členů chybí zástupný znak pole.
  • /events/[]/{/name,/category}/?
    • N-tice začínají s úvodním /
  • /events/[]/{name/?,category/?}/?
    • n-tice končí ?
  • /city/[]/events/[]/{name, category}/?
    • Předpona cesty jako dva zástupné znaky pole

Složené indexy

Dotazy, které mají ORDER BY klauzuli se dvěma nebo více vlastnostmi, vyžadují složený index. Můžete také definovat složený index, který zlepší výkon mnoha dotazů na rovnost a rozsah. Ve výchozím nastavení nejsou definované žádné složené indexy, takže byste měli podle potřeby přidávat složené indexy .

Na rozdíl od zahrnutých nebo vyloučených cest nemůžete vytvořit cestu se zástupným znakem /* . Každá složená cesta má implicitní /? na konci cesty, kterou nemusíte zadávat. Složené cesty vedou ke skalární hodnotě, která je jedinou hodnotou obsaženou ve složeného indexu. Pokud cesta ve složeného indexu v položce neexistuje nebo vede k nekalarní hodnotě, přidá se do indexu hodnota, která označuje, že cesta není definována.

Při definování složeného indexu zadáte:

  • Dvě nebo více cest vlastností. Pořadí, ve kterém jsou cesty vlastností definovány, záleží.

  • Pořadí (vzestupné nebo sestupné).

Note

Když přidáte složený index, dotaz použije existující indexy rozsahu, dokud není přidání nového složeného indexu dokončeno. Proto při přidávání složeného indexu nemusíte okamžitě sledovat vylepšení výkonu. Průběh transformace indexu je možné sledovat pomocí jedné ze sad SDK.

Dotazy ORDER BY na více vlastností:

Při použití složených indexů pro dotazy s klauzulí se ORDER BY dvěma nebo více vlastnostmi se používají následující aspekty.

  • Pokud složené cesty indexu neodpovídají sekvenci vlastností v ORDER BY klauzuli, složený index nemůže dotaz podporovat.

  • Pořadí složených indexových cest (vzestupně nebo sestupně) by se také mělo shodovat s order v klauzuli ORDER BY.

  • Složený index také podporuje ORDER BY klauzuli s opačným pořadím na všech trasách.

Podívejte se na následující příklad, ve kterém je složený index definován pro název vlastnosti, věk a _ts:

Složený index Ukázkový ORDER BY dotaz Podpora složeného indexu
(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

Zásady indexování byste měli přizpůsobit, abyste mohli obsluhovat všechny potřebné ORDER BY dotazy.

Dotazy s filtry na více vlastností

Pokud dotaz obsahuje filtry dvou nebo více vlastností, může být užitečné vytvořit složený index pro tyto vlastnosti.

Představte si například následující dotaz, který má filtr rovnosti i rozsahu:

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

Tento dotaz je efektivnější, trvá méně času a spotřebovává méně RU, pokud je schopen použít složený index pro (name ASC, age ASC).

Dotazy s více filtry rozsahu je také možné optimalizovat pomocí složeného indexu. Každý složený index ale může optimalizovat pouze jeden filtr rozsahu. Filtry rozsahů zahrnují >, <, <=, >=a !=. Filtr rozsahu by měl být definován jako poslední ve složeného indexu.

Zvažte následující dotaz s filtrem rovnosti a dvěma filtry rozsahu:

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

Tento dotaz je efektivnější se složeným indexem na (name ASC, age ASC) a (name ASC, _ts ASC). Dotaz by však nevyužil složený index (age ASC, name ASC) , protože vlastnosti s filtry rovnosti musí být definovány jako první ve složeného indexu. Místo jednoho složeného indexu jsou vyžadovány dva samostatné složené indexy (name ASC, age ASC, _ts ASC) , protože každý složený index může optimalizovat pouze jeden filtr rozsahu.

Při vytváření složených indexů pro dotazy s filtry pro více vlastností se používají následující aspekty.

  • Výrazy filtru můžou používat více složených indexů.
  • Vlastnosti ve filtru dotazu by se měly shodovat s vlastnostmi ve složeného indexu. Pokud je vlastnost ve složeného indexu, ale není součástí dotazu jako filtr, dotaz nevyužívá složený index.
  • Pokud má dotaz v filtru jiné vlastnosti, které nejsou definovány ve složeného indexu, použije se k vyhodnocení dotazu kombinace složených indexů a indexů rozsahu. To vyžaduje méně RU než výhradním použitím indexů rozsahu.
  • Pokud má vlastnost filtr rozsahu (>, <, <=, >=, nebo !=), měla by být tato vlastnost definována jako poslední ve složeného indexu. Pokud má dotaz více než jeden filtr rozsahu, může mít prospěch z několika složených indexů.
  • Při vytváření složeného indexu pro optimalizaci dotazů s více filtry ORDER nemá složený index žádný vliv na výsledky. Tato vlastnost je volitelná.

Podívejte se na následující příklady, ve kterých je složený index definovaný podle názvu vlastností, stáří a časového razítka:

Složený index Ukázkový dotaz Podpora složeného indexu
(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

Dotazy s filtrem a příkazem ORDER BY

Pokud dotaz filtruje jednu nebo více vlastností a má v klauzuli ORDER BY různé vlastnosti, může být užitečné přidat do klauzule vlastnosti ve filtru ORDER BY .

Například přidáním vlastností ve filtru do ORDER BY klauzule lze přepsat následující dotaz, aby použil složený index:

Dotaz pomocí indexu rozsahu:

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

Dotaz pomocí složeného indexu:

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

Stejné optimalizace dotazů lze zobecnit pro všechny ORDER BY dotazy s filtry, přičemž mějte na paměti, že jednotlivé složené indexy můžou podporovat maximálně jeden filtr rozsahu.

Dotaz pomocí indexu rozsahu:

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

Dotaz pomocí složeného indexu:

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

Kromě toho můžete použít složené indexy k optimalizaci dotazů pomocí systémových funkcí a ORDER BY.

Dotaz pomocí indexu rozsahu:

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

Dotaz pomocí složeného indexu:

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

Při vytváření složených indexů pro optimalizaci dotazu pomocí filtru a ORDER BY klauzule platí následující aspekty:

  • Pokud pro dotaz nedefinujete složený index s filtrem jedné vlastnosti a samostatnou ORDER BY klauzulí s jinou vlastností, dotaz bude i nadále úspěšný. Náklady na RU dotazu lze však snížit pomocí složeného indexu, zejména pokud má vlastnost v klauzuli ORDER BY vysokou kardinalitu.
  • Pokud jsou filtry dotazu na vlastnosti, měly by být tyto vlastnosti zahrnuty jako první do ORDER BY klauzule.
  • Pokud dotaz filtruje více vlastností, musí být filtry rovnosti prvními vlastnostmi v klauzuli ORDER BY .
  • Pokud dotaz filtruje na více vlastností, můžete mít maximálně jeden filtr rozsahu nebo systémovou funkci využitou na kompozitní index. Vlastnost použitá ve filtru rozsahu nebo systémové funkci by měla být definována jako poslední ve složeného indexu.
  • Všechny aspekty vytváření složených indexů pro ORDER BY dotazy s více vlastnostmi a dotazy s filtry u více vlastností stále platí.
Složený index Ukázkový ORDER BY dotaz Podpora složeného indexu
(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

Dotazy s filtrem a agregací

Pokud dotaz filtruje jednu nebo více vlastností a má agregační systémovou funkci, může být užitečné vytvořit složený index pro vlastnosti ve funkci filtru a agregace systému. Tato optimalizace platí pro systémové funkce SUMa a AVG .

Při vytváření složených indexů platí následující aspekty, které optimalizují dotaz pomocí funkce filtru a agregace systému.

  • Složené indexy jsou volitelné při spouštění dotazů s agregacemi. Náklady na RU dotazu se ale často dají snížit pomocí složeného indexu.
  • Pokud dotaz filtruje více vlastností, musí být filtry rovnosti prvními vlastnostmi ve složeného indexu.
  • Můžete mít maximálně jeden filtr rozsahu na složený index a musí být aplikován na vlastnost používanou v agregační systémové funkci.
  • Vlastnost v agregační systémové funkci by měla být definována jako poslední ve složeného indexu.
  • Na order (ASC nebo DESC) nezáleží.
Složený index Ukázkový dotaz Podpora složeného indexu
(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

Složené indexy s využitím zástupných znaků v poli

Níže je příklad složeného indexu, jenž obsahuje zástupný znak pole.

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

Ukázkový dotaz, který může těžit z tohoto složeného indexu, je:

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

Úprava zásad indexování

Zásady indexování kontejneru je možné kdykoli aktualizovat pomocí portálu Azure nebo některé z podporovaných sad SDK. Aktualizace zásad indexování aktivuje transformaci ze starého indexu na nový, který se provádí online a na místě (takže během této operace se nevyužívají žádné další prostory úložiště). Staré zásady indexování se efektivně transformují na nové zásady, aniž by to ovlivnilo dostupnost zápisu, dostupnost čtení nebo propustnost zřízenou v kontejneru. Transformace indexu je asynchronní operace a doba dokončení závisí na zřízené propustnosti, počtu položek a jejich velikosti. Pokud je potřeba provést několik aktualizací zásad indexování, doporučujeme provést všechny změny jako jednu operaci, aby se transformace indexu co nejrychleji dokončila.

Important

Transformace indexu je operace, která spotřebovává požadované jednotky.

Note

Průběh transformace indexu můžete sledovat na portálu Azure nebo pomocí jednoho z SDK.

Dostupnost zápisu není během transformací indexu žádným způsobem ovlivněna. Transformace indexu používá zřízené RU, ale s nižší prioritou než operace CRUD nebo dotazy.

Při přidávání nových indexovaných cest není dostupnost čtení ovlivněna. Po dokončení transformace indexu budou dotazy využívat nové indexované cesty. Jinými slovy, když přidáváte novou indexovanou cestu, dotazy, které z této indexované cesty využívají, mají stejný výkon před a během transformace indexu. Po dokončení transformace indexu začne dotazovací modul používat nové indexované cesty.

Při odebírání indexovaných cest byste měli všechny změny seskupovat do jedné transformace zásad indexování. Pokud odeberete více indexů a provedete to v jedné změně zásad indexování, dotazovací modul poskytuje konzistentní a úplné výsledky v rámci transformace indexu. Pokud ale indexy odeberete prostřednictvím několika změn zásad indexování, dotazovací modul nebude poskytovat konzistentní ani kompletní výsledky, dokud se všechny transformace indexu nedokončí. Většina vývojářů indexy neodstraní a okamžitě se pokusí spustit dotazy, které tyto indexy využívají, takže v praxi je tato situace nepravděpodobné.

Když zahodíte indexovanou cestu, dotazovací modul ho okamžitě přestane používat a místo toho provede úplnou kontrolu.

Note

Pokud je to možné, měli byste se vždy pokusit seskupit několik odebrání indexů do jedné úpravy zásad indexování.

Important

Odebrání indexu se projeví okamžitě, zatímco přidání nového indexu nějakou dobu trvá, protože vyžaduje transformaci indexování. Při nahrazení jednoho indexu jiným (například nahrazení jednoho indexu vlastností složeným indexem) nezapomeňte nejprve přidat nový index a potom počkat na dokončení transformace indexu před odebráním předchozího indexu ze zásad indexování. Jinak to negativně ovlivní vaši schopnost dotazovat se na předchozí index a může narušit všechny aktivní úlohy, které odkazují na předchozí index.

Zásady indexování a TTL

Použití funkce TTL (Time-to Live) vyžaduje indexování. To znamená, že:

  • Není možné aktivovat hodnotu TTL v kontejneru, kde je režim indexování nastavený na none,
  • Není možné nastavit režim indexování na žádný (None) v kontejneru, kde je aktivován TTL.

Ve scénářích, kdy není potřeba indexovat žádnou cestu k vlastnosti, ale vyžaduje se hodnota TTL, můžete použít zásadu indexování s režimem indexování nastaveným na consistent, žádné zahrnuté cesty a /* jako jedinou vyloučenou cestu.

Související obsah

  • Last updated on