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

  • Článek

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 možná budete 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 indexujeme vlastnost zaměstnanci, ale nebudeme indexovat další 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 budou mít 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.

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

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 nes skalární 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á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 má dotaz 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 bude efektivnější, trvá méně času a spotřebovává méně RU, pokud je schopen využít složený index (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 bude efektivnější s využitím složeného indexu a (name ASC, age ASC)(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 bude vyžadovat 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 více složených indexů.
  • Při vytváření složeného indexu pro optimalizaci dotazů s více filtry ORDER nebude mít 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 může být následující dotaz přepsán, aby využíval 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í výrazně 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

Ú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 místní (takže 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 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á využívá jednotky žádostí. Jednotky žádostí spotřebované transformací indexu se v současné době nefakturují, pokud používáte bezserverové kontejnery. Tyto jednotky žádostí se budou účtovat, jakmile bude bezserverová služba obecně dostupná.

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áte novou indexovanou cestu, dotazy, které z této indexované cesty využívají, budou mít 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.

Další kroky

Další informace o indexování najdete v následujících článcích: