Zásady indexování ve službě Cosmos DB (v Azure a Fabric)

Platí pro: ✅ Azure Cosmos DB for NoSQL, ✅ Cosmos DB in Microsoft Fabric

Cosmos DB (v rámci Azure a Fabric) je databáze nezávislá na schématu, která umožňuje iterovat na vaší aplikaci bez nutnosti zabývat se správou schématu nebo indexu. Indexování ve službě Cosmos DB je navržené tak, aby poskytovalo rychlý a flexibilní výkon dotazů bez ohledu na to, jak se vaše data vyvíjejí. Ve službě 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. Tato výchozí konfigurace umožňuje získat dobrý výkon dotazů, aniž byste museli předem přemýšlet o indexování a správě 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í.

Režim indexování

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

Konzistentní: Index se při vytváření, aktualizaci nebo odstraňování položek aktualizuje synchronně.
Žá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 Consistent a pak monitorovat pomocí funkce IndexTransformationProgress v sadě SDK až do dokončení.

Poznámka:

Cosmos DB také podporuje 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. Toto chování může vést k nekonzistentním nebo neúplným výsledkům dotazu. Pokud plánujete dotazovat kontejner Cosmos DB, neměli byste vybírat opožděné indexování. Nové kontejnery nemohou zvolit opožděné indexování.

Velikost indexu

Ve službě 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í oddílu se uvolní prostor indexu.
Systémové vlastnosti id a _ts jsou vždy indexovány, pokud je režim indexování kontejneru konzistentní.
Systémové vlastnosti id a _ts nejsou zahrnuté v popisu indexovaných cest pro zásady kontejneru. Toto vyloučení je záměrně, protože tyto systémové vlastnosti jsou ve výchozím nastavení vždy indexovány a toto chování nelze zakázat.

Poznámka:

Klíč oddílu (pokud to není také /id) není indexován a měl by být zařazen do 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.

Zvažte tuto položku JSON znovu:

{
  "id": "00000000-0000-0000-0000-000000004368",
  "name": "Cofaz Jacket",
  "tags": [
    { "category": "clothing", "type": "jacket" },
    { "category": "outdoor", "type": "winter" }
  ],
  "inventory": { "warehouse": "Seattle", "quantity": 50 },
  "distributors": [
    { "name": "Contoso" },
    { "name": "AdventureWorks" }
  ]
}

Výsledkem této zásady indexování jsou tyto cesty indexování:

Cesta	Hodnota
`/id`	`"00000000-0000-0000-0000-000000004368"`
`/name`	`"Cofaz Jacket"`
`/tags/0/category`	`"clothing"`
`/tags/0/type`	`"jacket"`
`/tags/1/category`	`"outdoor"`
`/tags/1/type`	`"winter"`
`/inventory/warehouse`	`"Seattle"`
`/inventory/quantity`	`50`
`/distributors/0/name`	`"Contoso"`
`/distributors/1/name`	`"AdventureWorks"`

Tyto cesty jsou definovány s následujícími dodatky:

cesta vedoucí ke skalární hodnotě (řetězec nebo číslo) končí na /?
prvky z pole jsou adresovány prostřednictvím zápisu /[] (místo /0, /1atd.)
/* Zástupný znak lze použít ke shodě libovolných prvků pod uzlem.

Zásady indexování podle směrného plánu pro ukázkovou položku můžou zahrnovat tyto optimalizace:

inventory quantity cesta je/inventory/quantity/?
tagscesta je category/tags/[]/category/?
cesta k všemu, co je pod inventory/inventory/*

Mohli bychom například zahrnout /inventory/quantity/? cestu. Tato cesta zajistí, že vlastnost indexujeme quantity , 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ě Cosmos DB proaktivně indexovat všechny nové vlastnosti, které by mohly 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 není ve výchozím nastavení indexována kvůli použité strategii 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á.

Další informace najdete v ukázkových zásadách indexování.

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.

Podívejte se na tento příklad:

Zahrnutá cesta: /model/manufacturer/*
Vyloučená cesta: /model/*

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 budou z indexu vyloučena veškerá data v cestě /model nebo data vnořená v této cestě. Výjimkou by byla data v zahrnuté cestě: /model/manufacturer/*, která by byla indexována.

Tady jsou některá pravidla pro prioritu zahrnutých a vyloučených cest ve službě 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/*, takže /a/? má přednost.
Cesta /* musí být zahrnutá nebo vyloučená cesta.

Fulltextové indexy

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

Důležité

Zásady indexování fulltextu musí být na cestě definované v zásadách fulltextového kontejneru. Další informace najdete v tématu fulltextové vyhledávání.

Vektorové indexy

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í hledání vektorů nižší latenci, vyšší propustnost a nižší spotřebu jednotek žádostí (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. Tento typ může zvýš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é

Zásady vektoru a indexy vektorů jsou po vytvoření neměnné. Pokud chcete provést změny, vytvořte novou kolekci.

Několik bodů na poznámku:

Typy indexů flat a quantizedFlat využívají index služby Cosmos DB k ukládání a čtení jednotlivých vektorů během hledání vektorů. Vektorové vyhledávání s indexem jsou vyhledávání hrubou silou a poskytují 100% přesnosti a úplnosti. Tato přesnost znamená, že hledání vždy najde nejvíce podobných vektorů v datové sadě. flat Index však podporuje vektory s až 505 dimenzemi.
- 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ů pomocí 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. Tento typ je dobrou volbou 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ů. V tomto scénáři je vyžadována 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.
- diskANN Indexy quantizedFlat 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=dynamicsystém rozhodne), Max=512). Nastavení této velikosti na vyšší může mít za následek vyhledávání vektorů s vyšší přesností na úkor vyšších nákladů na RU a zvýšené latence. Tento kompromis platí pro quantizedFlat a DiskANN oba typy indexů.
- indexingSearchListSize: Nastaví, kolik vektorů se má prohledávat během sestavování indexů. Min=10, Default=100, Max=500. Nastavení větší velikosti by mohlo vést k větší přesnosti vektorových hledání na úkor delší doby pro sestavení indexu a vyšší latence při ingestování vektorů. Tato charakteristika se vztahuje pouze na 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é

Cesta vektoru by se měla přidat do excludedPaths části zásad indexování, aby se zajistil optimalizovaný výkon pro vložení. Nepřidání cesty vektoru k excludedPaths vede k vyššímu poplatku za RU a vyšší latenci při vkládání vektorů.

Zásada indexování vektorů musí být také na cestě definované v zásadě vektorů kontejneru. Další informace najdete v tématu zásady vektoru.

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

Cosmos DB ve výchozím nastavení nevytváří žádné prostorové indexy. Pokud chcete použít předdefinované funkce prostorového SQL, vytvořte prostorový index požadovaných vlastností. Další informace najdete v tématu prostorové indexy.

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 sekci 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 n-tice musí končit /?. Pokud v cestě n-tice v položce neexistuje n-tice, přidá se do indexu hodnota, která označuje, že n-tice není definovaná.

Cesty n-tic pole jsou určeny v sekci includedPaths pomocí následujícího zápisu: <path prefix>/[]/{<tuple 1>, <tuple 2>, …, <tuple n>}/?

Zvažte tato důležitá pravidla pro n-tice polí:

Každá část n-tice je oddělena čárkou.
První část, předpona cesty, je cesta, která je společná mezi n-ticemi. Je to cesta od kořenového uzlu k poli. V našem příkladu je to /tags.
Po první části by n-tice měla obsahovat specifikátor zástupného znaku pole []. Všechny cesty n-tice pole by měly mít zástupný specifikátor pole před specifikátorem n-tice {}.
Další část určuje n-tice pomocí specifikátoru {}.
Řazená kolekce členů musí používat stejnou specifikaci cesty jako jiné cesty indexu s několika výjimkami:
- n-tice by neměly začínat /.
- Řady by neměly mít zástupné symboly.
- N-tice by neměly končit ? nebo *.
- ? je poslední segment v cestě n-tice a měl by být specifikován ihned po segmentu specifikátoru n-tice.

Například tato specifikace je platná cesta n-tice: /tags/[]/{category, type}/?

Tady je několik platných příkladů cest n-tic pole:

[
  { "path": "/tags/[]/{category, type}/?" },
  { "path": "/distributors/[]/{name}/?" },
  { "path": "/tags/[]/{category}/?" },
  { "path": "/tags/[]/{{category, type}}/?" },
  { "path": "/tags/[]/{[0], [1]}/?" },
  { "path": "/inventory/items/[]/tags/[]/{category, type}/?" }
]

Tady je několik příkladů neplatných cest řazené kolekce členů pole s vysvětlením:

Neplatná cesta	Explanation
`/tags/[]/{category/[]/type}/?`	Jeden z řazených kolekcí členů má zástupný znak pole.
`/tags/[]/{category, type}/*`	Poslední segment v cestě tuple pole by měl být `?` a ne `*`
`/tags/[]/{{category, type}}/?`	Specifikátor řazené kolekce členů je vnořený.
`/tags/{category, type}/?`	Před specifikátorem řazené kolekce členů chybí zástupný znak pole.
`/tags/[]/{/category,/type}/?`	n-tice musí začínat počátečním `/`
`/tags/[]/{category/?,type/?}/?`	N-tice musí končit `?`
`/inventory/[]/tags/[]/{category, type}/?`	Předpona cesty jako dva zástupné řady

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.

Zástupný znak /* nemůžete použít ve složených cestách indexu. Každá složená cesta automaticky končí symbolem /?, takže jej nemusíte přidávat. Složené cesty musí odkazovat na skalární hodnotu, což je jediná hodnota zahrnutá do složeného indexu. Pokud složená cesta indexu v položce neexistuje nebo odkazuje na necalarovou hodnotu, Cosmos DB přidá do indexu hodnotu, která ukazuje, že cesta není definována.

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

Dvě nebo více cest vlastností definovaných v určitém pořadí, které ovlivňují způsob použití složeného indexu.
Pořadí definované jako vzestupné nebo sestupné.

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.

Návod

Průběh transformace indexu je možné sledovat pomocí jedné ze sad SDK (Software Development Kit).

`ORDER BY` dotazy 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, množství a _ts:

Složený index	Ukázkový `ORDER BY` dotaz	Je podporován složený index?
`(name ASC, quantity ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.inventory.quantity asc`	`Yes`
`(name ASC, quantity ASC)`	`SELECT * FROM c ORDER BY c.inventory.quantity ASC, c.name asc`	`No`
`(name ASC, quantity ASC)`	`SELECT * FROM c ORDER BY c.name DESC, c.inventory.quantity DESC`	`Yes`
`(name ASC, quantity ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.inventory.quantity DESC`	`No`
`(name ASC, quantity ASC, timestamp ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.inventory.quantity ASC, timestamp ASC`	`Yes`
`(name ASC, quantity ASC, timestamp ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.inventory.quantity 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
  container c
WHERE
  c.name = "Cofaz Jacket" AND c.inventory.quantity > 18

Tento dotaz je efektivnější, trvá méně času a spotřebovává méně jednotek žádostí (RU), pokud je schopen použít složený index pro (name ASC, quantity 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
  container c
WHERE
  c.name = "Cofaz Jacket" AND
  c.inventory.quantity > 18 AND
  c._ts > 1612212188

Tento dotaz je efektivnější pomocí složeného indexu zapnutého (name ASC, quantity ASC) a (name ASC, _ts ASC). Dotaz by však nevyužil složený index (quantity 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, quantity 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í zahrnuta v dotazu jako filtr, dotaz nevyužívá složený index.
Pokud dotaz filtruje vlastnosti, které nejsou součástí složeného indexu, použije se k vyhodnocení dotazu kombinace složených indexů a indexů rozsahu. Tento přístup spotřebovává méně RU než výhradní spoléhání na indexy 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í, množství a časového razítka:

Složený index	Ukázkový dotaz	Je podporován složený index?
`(name ASC, quantity ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity = 18`	`Yes`
`(name ASC, quantity ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity > 18`	`Yes`
`(name ASC, quantity ASC)`	`SELECT COUNT(1) FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity > 18`	`Yes`
`(name DESC, quantity ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity > 18`	`Yes`
`(name ASC, quantity ASC)`	`SELECT * FROM c WHERE c.name != "Cofaz Jacket" AND c.inventory.quantity > 18`	`No`
`(name ASC, quantity ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity = 18 AND c.timestamp > 123049923`	`Yes`
`(name ASC, quantity ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity < 18 AND c.timestamp = 123049923`	`No`
`(name ASC, quantity ASC) and (name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity < 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
  container c
WHERE
  c.name = "Cofaz Jacket"
ORDER BY
  c.timestamp

Dotaz pomocí složeného indexu:

SELECT
  *
FROM
  container c
WHERE
  c.name = "Cofaz Jacket"
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
  container c
WHERE
  c.name = "Cofaz Jacket" AND
  c.inventory.quantity = 18 AND
  c.timestamp > 1611947901
ORDER BY
  c.timestamp

Dotaz pomocí složeného indexu:

SELECT
  *
FROM
  container c
WHERE
  c.name = "Cofaz Jacket" AND
  c.inventory.quantity = 18 AND
  c.timestamp > 1611947901
ORDER BY
  c.name,
  c.inventory.quantity,
  c.timestamp

Kromě toho můžete pomocí složených indexů optimalizovat dotazy pomocí systémových funkcí a ORDER BY:

Dotaz pomocí indexu rozsahu:

SELECT
  *
FROM
  container c
WHERE
  c.name = "Cofaz Jacket" AND
  CONTAINS(c.distributors[0].name, "Contoso", true)
ORDER BY
  c.distributors[0].name

Dotaz pomocí složeného indexu:

SELECT
  *
FROM
  container c
WHERE
  c.name = "Cofaz Jacket" AND
  CONTAINS(c.distributors[0].name, "Contoso", true)
ORDER BY
  c.name, c.distributors[0].name

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 na jednu vlastnost a samostatnou ORDER BY klauzulí, která používá jinou vlastnost, bude dotaz stá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	Je podporován složeným indexem?
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" ORDER BY c.name ASC, c.timestamp ASC`	`Yes`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" 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 = "Cofaz Jacket" ORDER BY c.timestamp ASC, c.name ASC`	`No`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" ORDER BY c.timestamp ASC, c.name ASC`	`No`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "Cofaz Jacket" ORDER BY c.timestamp ASC`	`No`
`(quantity ASC, name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.inventory.quantity = 18 and c.name = "Cofaz Jacket" ORDER BY c.inventory.quantity ASC, c.name ASC,c.timestamp ASC`	`Yes`
`(quantity ASC, name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.inventory.quantity = 18 and c.name = "Cofaz Jacket" 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 SUMAVG systémové funkce.

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	Podporuje složený index?
`(name ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "Cofaz Jacket"`	`Yes`
`(timestamp ASC, name ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "Cofaz Jacket"`	`No`
`(name ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name > "Cofaz Jacket"`	`No`
`(name ASC, quantity ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity = 25`	`Yes`
`(quantity ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "Cofaz Jacket" AND c.inventory.quantity > 25`	`No`

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

Zde je příklad složeného indexu, který obsahuje zástupný znak v poli.

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

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

SELECT VALUE
  p.id
FROM
  products p
JOIN
  d IN p.distributors
WHERE
  p.name = "Cofaz Jacket" AND
  d.name > "Contoso"

Úprava zásad indexování

Aktualizace zásad indexování aktivuje transformaci ze starého indexu na nový. Tato transformace se provádí na místě a online. Během 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 potřebujete provést několik aktualizací zásad indexování, proveďte všechny změny v jedné operaci. Tento přístup umožňuje rychlejší dokončení transformace indexu.

Důležité

Transformace indexu je operace, která spotřebovává jednotky žádostí. Průběh a spotřebu operace transformace indexu můžete sledovat pomocí jedné ze sad SDK.

Během transformací indexu není nijak ovlivněna dostupnost zápisu. 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í. Dotazy používají nové indexované cesty až po dokončení transformace indexu. 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 však odeberete indexy prostřednictvím několika změn zásad indexování, dotazovací modul neposkytuje konzistentní nebo úplné výsledky, dokud se všechny transformace indexu nedokončí. Většina vývojářů nezahazuje indexy a okamžitě se pokusí spustit dotazy, které tyto indexy využívají. 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. Pokud je to možné, vždy seskupte několik odebrání indexů do jedné změny zásad indexování.

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řed odebráním předchozího indexu ze zásad indexování nezapomeňte nejprve přidat nový index a potom počkat, než se transformace indexu dokončí, když nahradíte jeden index jiným indexem. Pokud například nahradíte jeden index vlastností složeným indexem, postupujte podle této strategie. Jinak tento krok negativně ovlivňuje 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í.

Tento požadavek znamená, že:

Hodnotu TTL není možné aktivovat v kontejneru, kde je režim indexování nastavený na none,
Režim indexování nelze nastavit na "Žádný" u kontejneru, ve kterém je aktivována 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.

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-11-23

Sdílet prostřednictvím

Zásady indexování ve službě Cosmos DB (v Azure a Fabric)

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

ORDER BY dotazy 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

`ORDER BY` dotazy na více vlastností: