Zásady indexování ve službě Azure Cosmos DB

Článek
11/19/2024

PLATÍ PRO: NoSQL

Ve službě Azure Cosmos DB má každý kontejner zásady indexování, které určují, jakým způsobem by se měly indexovat položky kontejneru. 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 cest vlastností.

Poznámka:

Metoda aktualizace zásad indexování popsaných v tomto článku se týká pouze rozhraní API služby Azure Cosmos DB pro NoSQL. Informace o indexování v rozhraní API služby 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.

Poznámka:

Azure Cosmos DB podporuje také opožděný režim indexování. Opožděné indexování provádí aktualizace indexu na mnohem nižší úrovni priority v době, 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 kontejner Azure Cosmos DB, 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řípadu, kdy používáte účet služby Azure Cosmos DB v bezserverovém režimu, který nepodporuje opožděné indexování).

Ve výchozím nastavení je zásada indexování nastavena na automatichodnotu . Toho dosáhnete nastavením automatic vlastnosti v zásadách indexování na truehodnotu . Nastavením této vlastnosti true umožníte službě Azure Cosmos DB automaticky indexovat položky při jejich zápisu.

Velikost indexu

V Azure Cosmos DB je celkové využité ú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í oddílu se uvolní prostor indexu.

Zahrnutí a vyloučení cest k vlastnostem

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 řešeny společně notací /[] (místo /0atd /1 .).
/* Zástupný znak lze použít ke shodě libovolných prvků 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" }
        ]
    }

headquartersemployees cesta je/headquarters/employees/?
locationscesta je country/locations/[]/country/?
cesta k všemu, co je pod headquarters/headquarters/*

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

Zahrnout nebo vyloučit strategii

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 službě Azure Cosmos DB proaktivně indexovat všechny nové vlastnosti, které se můžou přidat 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 uvozovat řetězec cesty kolem dvojitých uvozovek (například "/path/?"). U cest s jinými speciálními znaky je nutné uvozovky uvozovek 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. Funkčně se nijak neliší, pokud uniknete každou cestu nebo jenom ty, které mají 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 vaše zahrnuté cesty a vyloučené cesty mají konflikt, bude mít přednost přesnější cesta.

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 se všechna data v cestě nebo vnořená do food/ingredients tohoto indexu vyloučila. 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 ve službě Azure Cosmos DB:

Podrobnější 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

Poznámka:

Abyste mohli zadat fulltextový index, musíte povolit funkci FullText & Hybrid Search for NoSQL API Preview.

Fulltextové indexy umožňují efektivně používat fulltextové vyhledávání a bodování. 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. Příklad:

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

Důležité

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

Vektorové indexy

Poznámka:

Pokud chcete zadat vektorový index, musíte povolit funkci NoSQL Vector Search služby Azure Cosmos DB.

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	Popis	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

Důležité

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:

quantizedFlat Typy indexů flat použijí index služby 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 indexem jsou vyhledávání hrubou flat silou a vytvářejí 100% přesnost nebo úplnost. 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. Hledání vektorů by quantized flat ale mělo mít nižší latenci, vyšší propustnost a nižší náklady na 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 společností 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.

quantizedFlat Indexy diskANN můžou využívat volitelné parametry sestavení indexu, které se dají použít k ladění přesnosti a kompromisu latence, které platí pro každý index vektoru přibližných sousedů.

quantizationByteSize: Nastaví velikost (v bajtech) pro kvantování produktu. Min=1, Default=dynamic (systém rozhoduje), Max=512. Nastavení tohoto většího může vést k vyššímu vektoru přesnosti hledání na úkor vyšších nákladů na RU a vyšší latence. To platí pro quantizedFlat typy indexů i DiskANN pro oba typy.
- indexingSearchListSize: Nastaví, kolik vektorů se má prohledávat během sestavování indexů. Min=10, Default=100, Max=500. Nastavení tohoto většího může vést k vyššímu počtu vektorů přesnosti při hledání na úkor delší doby sestavení indexu a vyšší latence 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/?",
        },
        {
            "path": "/vector/*"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector",
            "type": "diskANN"
        }
    ]
}

Důležité

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

Důležité

Vektorová cesta přidaná do oddílu "excludedPaths" zásad indexování, aby se zajistil optimalizovaný výkon pro vložení. Přidáním vektorové cesty do vyloučených cest způsobíte vyšší poplatky za RU a latenci při vkládání vektorů.

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ří:

Bod
Mnohoúhelník
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 řazené kolekce členů

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

Poznámka:

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

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

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

Poznámky:

První část, předpona cesty, je cesta, která je společná mezi řazené kolekce členů. 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é matice []. Všechny cesty řazené kolekce členů pole by měly mít specifikátor zástupných znaků pole před specifikátorem řazené kolekce členů "{}".
Dále určuje řazené kolekce členů pomocí specifikátoru řazené kolekce členů "{}".
Řazené kolekce členů budou odděleny čárkami.
Řazená kolekce členů musí používat stejnou specifikaci cesty jako jiné cesty indexu s několika výjimkami:
Řazené kolekce členů by neměly začínat počátečním názvem /.
Řazené kolekce členů by neměly obsahovat zástupné řady.
Řazené kolekce členů by neměly končit "?" nebo "*"
“?” je poslední segment v cestě řazené kolekce členů a měl by být zadán bezprostředně za specifikátorem řazené kolekce členů.

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 řazené kolekce členů pole.

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

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

Poznámka:

Když přidáte složený index, dotaz bude využívat existující indexy rozsahu, dokud nebude 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 cest indexů (vzestupně nebo sestupně) by se také mělo shodovat s klauzulíorder.ORDER BY
Složený index také podporuje ORDER BY klauzuli s opačným pořadím na všech cestá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 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ší pomocí složeného indexu zapnutého (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ě pomocí 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 nepovinná.

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

Složené indexy navíc můžete použít k optimalizaci dotazů pomocí systémových funkcí a FUNKCE 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 se ale dají snížit pomocí složeného indexu, zejména pokud má vlastnost v ORDER BY klauzuli 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 filtry dotazu na více vlastností, můžete mít maximálně jeden filtr rozsahu nebo systémovou funkci využitou na složený 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 ve vlastnosti agregační systémové funkce.
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 se zástupným znakem pole

Níže je příklad složeného indexu, který 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í webu Azure Portal 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.

Důležité

Transformace indexu je operace, která spotřebovává jednotky žádostí.

Poznámka:

Průběh transformace indexu můžete sledovat na webu Azure Portal nebo pomocí jedné ze sad SDK.

Dostupnost zápisu během transformací indexu nemá žádný vliv. 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 nemá žádný vliv na dostupnost čtení. 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.

Poznámka:

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

Důležité

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 hodnota 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,
Režim indexování není možné nastavit v kontejneru, ve kterém je aktivovaný hodnota 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.

Sdílet prostřednictvím

Zásady indexování ve službě Azure Cosmos DB

Režim indexování

Velikost indexu

Zahrnutí a vyloučení cest k vlastnostem

Zahrnout nebo vyloučit strategii

Zahrnutí nebo vyloučení priority

Fulltextové indexy

Vektorové indexy

Prostorové indexy

Indexy řazené kolekce členů

Složené indexy

Dotazy ORDER BY na více vlastností:

Dotazy s filtry více vlastností

Dotazy s filtrem a ORDER BY

Dotazy s filtrem a agregací

Složené indexy se zástupným znakem pole

Úprava zásad indexování

Zásady indexování a hodnota TTL

Váš názor

Další materiály

Sdílet prostřednictvím

Zásady indexování ve službě Azure Cosmos DB

Režim indexování

Velikost indexu

Zahrnutí a vyloučení cest k vlastnostem

Zahrnout nebo vyloučit strategii

Zahrnutí nebo vyloučení priority

Fulltextové indexy

Vektorové indexy

Prostorové indexy

Indexy řazené kolekce členů

Složené indexy

Dotazy ORDER BY na více vlastností:

Dotazy s filtry více vlastností

Dotazy s filtrem a ORDER BY

Dotazy s filtrem a agregací

Složené indexy se zástupným znakem pole

Úprava zásad indexování

Zásady indexování a hodnota TTL

Související obsah

Váš názor

Další materiály