Zasady indeksowania w usłudze Azure Cosmos DB

Artykuł
11/19/2024

DOTYCZY: NoSQL

W usłudze Azure Cosmos DB każdy kontener ma zasady indeksowania, które określają sposób indeksowania elementów tego kontenera. Domyślne zasady indeksowania dla nowo utworzonych kontenerów indeksują każdą właściwość każdego elementu oraz wymuszają indeksy zakresu dla wszelkich ciągów i liczb. Dzięki temu można uzyskać dobrą wydajność zapytań bez konieczności wcześniejszego myślenia o indeksowaniu i zarządzania indeksami.

W niektórych sytuacjach warto zastąpić to automatyczne zachowanie, aby lepiej odpowiadało twoim wymaganiom. Zasady indeksowania kontenera można dostosować, ustawiając jego tryb indeksowania i dołączając lub wykluczając ścieżki właściwości.

Uwaga

Metoda aktualizowania zasad indeksowania opisanych w tym artykule dotyczy tylko interfejsu API usługi Azure Cosmos DB dla noSQL. Dowiedz się więcej o indeksowaniu w interfejsie API usługi Azure Cosmos DB dla bazy danych MongoDB

Tryb indeksowania

Usługa Azure Cosmos DB obsługuje dwa tryby indeksowania:

Spójny: indeks jest aktualizowany synchronicznie podczas tworzenia, aktualizowania lub usuwania elementów. Oznacza to, że spójność zapytań odczytu będzie spójnością skonfigurowaną dla konta.
Brak: indeksowanie jest wyłączone w kontenerze. Ten tryb jest często używany, gdy kontener jest używany jako czysty magazyn klucz-wartość bez konieczności obsługi indeksów pomocniczych. Może również służyć do poprawy wydajności operacji zbiorczych. Po zakończeniu operacji zbiorczych tryb indeksu można ustawić na Spójny, a następnie monitorować przy użyciu indeksu IndexTransformationProgress do ukończenia.

Uwaga

Usługa Azure Cosmos DB obsługuje również tryb indeksowania z opóźnieniem. Indeksowanie z opóźnieniem aktualizuje indeks na znacznie niższym poziomie priorytetu, gdy aparat nie wykonuje żadnej innej pracy. Może to doprowadzić do niespójnych lub niekompletnych wyników zapytań. Jeśli planujesz wykonywanie zapytań względem kontenera usługi Azure Cosmos DB, nie należy wybierać indeksowania z opóźnieniem. Nowe kontenery nie mogą wybierać indeksowania z opóźnieniem. Możesz zażądać wykluczenia, kontaktując się z cosmosdbindexing@microsoft.com nami (z wyjątkiem sytuacji, gdy używasz konta usługi Azure Cosmos DB w trybie bezserwerowym , który nie obsługuje indeksowania leniwego).

Domyślnie zasady indeksowania są ustawione na automaticwartość . Można to osiągnąć, ustawiając automatic właściwość w zasadach indeksowania na truewartość . Ustawienie tej właściwości na true umożliwia usłudze Azure Cosmos DB automatyczne indeksowanie elementów podczas ich zapisywania.

Rozmiar indeksu

W usłudze Azure Cosmos DB łączna ilość zużytego magazynu jest kombinacją rozmiaru danych i rozmiaru indeksu. Poniżej przedstawiono niektóre funkcje rozmiaru indeksu:

Rozmiar indeksu zależy od zasad indeksowania. Jeśli wszystkie właściwości są indeksowane, rozmiar indeksu może być większy niż rozmiar danych.
Po usunięciu danych indeksy są kompaktowane niemal w sposób ciągły. Jednak w przypadku małych operacji usuwania danych nie można natychmiast obserwować spadku rozmiaru indeksu.
Rozmiar indeksu może tymczasowo rosnąć po podzieleniu partycji fizycznych. Miejsce indeksu jest zwalniane po zakończeniu podziału partycji.

Dołączanie i wykluczanie ścieżek właściwości

Niestandardowe zasady indeksowania mogą określać ścieżki właściwości jawnie dołączone lub wykluczone z indeksowania. Optymalizując liczbę indeksowanych ścieżek, można znacznie zmniejszyć opóźnienie i obciążenie jednostek RU operacji zapisu. Te ścieżki są definiowane zgodnie z metodą opisaną w sekcji Omówienie indeksowania z następującymi dodatkami:

ścieżka prowadząca do wartości skalarnej (ciągu lub liczby) kończy się znakiem /?
elementy z tablicy są adresowane razem za pośrednictwem /[] notacji (zamiast /0, /1 itp.)
symbol wieloznaczny /* może być używany do dopasowania dowolnych elementów poniżej węzła

Ponownie biorąc ten sam przykład:

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

headquartersścieżka 's employees is/headquarters/employees/?
locationsścieżka " country to/locations/[]/country/?
ścieżka do dowolnego elementu poniżej headquarters to /headquarters/*

Możemy na przykład uwzględnić ścieżkę /headquarters/employees/? . Ta ścieżka gwarantuje indeksowanie employees właściwości, ale nie indeksuje dodatkowych zagnieżdżonych danych JSON w ramach tej właściwości.

Strategia dołączania/wykluczania

Wszystkie zasady indeksowania muszą zawierać ścieżkę /* główną jako dołączona lub wykluczona ścieżka.

Dołącz ścieżkę główną do selektywnego wykluczania ścieżek, które nie muszą być indeksowane. To podejście jest zalecane, ponieważ umożliwia usłudze Azure Cosmos DB proaktywne indeksowanie wszelkich nowych właściwości, które mogą zostać dodane do modelu.
Wyklucz ścieżkę główną, aby selektywnie uwzględnić ścieżki, które muszą być indeksowane. Ścieżka właściwości klucza partycji nie jest domyślnie indeksowana ze strategią wykluczania i powinna zostać jawnie uwzględniona w razie potrzeby.
W przypadku ścieżek ze zwykłymi znakami, które obejmują: znaki alfanumeryczne i _ (podkreślenie), nie musisz unikać ciągu ścieżki wokół podwójnych cudzysłowów (na przykład "/path/?"). W przypadku ścieżek z innymi znakami specjalnymi należy wrócić do ciągu ścieżki wokół podwójnych cudzysłowów (na przykład "/"path-abc"/?"). Jeśli spodziewasz się znaków specjalnych w ścieżce, możesz uniknąć każdej ścieżki bezpieczeństwa. Funkcjonalnie nie ma żadnej różnicy w przypadku ucieczki od każdej ścieżki lub tylko tych, które mają znaki specjalne.
Właściwość _etag systemowa jest domyślnie wykluczona z indeksowania, chyba że element etag zostanie dodany do dołączonej ścieżki do indeksowania.
Jeśli tryb indeksowania jest ustawiony na spójny, właściwości id systemu i _ts są automatycznie indeksowane.
Jeśli jawnie indeksowana ścieżka nie istnieje w elemencie, wartość zostanie dodana do indeksu, aby wskazać, że ścieżka jest niezdefiniowana.

Wszystkie jawnie dołączone ścieżki mają wartości dodane do indeksu dla każdego elementu w kontenerze, nawet jeśli ścieżka jest niezdefiniowana dla danego elementu.

Zobacz tę sekcję, aby zapoznać się z przykładami zasad indeksowania, aby dołączać i wykluczać ścieżki.

Pierwszeństwo dołączania/wykluczania

Jeśli dołączone ścieżki i wykluczone ścieżki mają konflikt, bardziej precyzyjna ścieżka ma pierwszeństwo.

Oto przykład:

Dołączona ścieżka: /food/ingredients/nutrition/*

Wykluczona ścieżka: /food/ingredients/*

W takim przypadku dołączona ścieżka ma pierwszeństwo przed wykluczonym ścieżką, ponieważ jest bardziej precyzyjna. Na podstawie tych ścieżek wszystkie dane w ścieżce lub zagnieżdżone w food/ingredients obrębie elementu zostaną wykluczone z indeksu. Wyjątkiem będą dane w dołączonej ścieżce: /food/ingredients/nutrition/*, która zostanie zindeksowana.

Poniżej przedstawiono kilka reguł pierwszeństwa uwzględnionych i wykluczonych ścieżek w usłudze Azure Cosmos DB:

Głębsze ścieżki są bardziej precyzyjne niż węższe ścieżki. na przykład: /a/b/? jest bardziej precyzyjne niż /a/?.
Wartość jest bardziej precyzyjna /? niż /*. Na przykład /a/? jest bardziej precyzyjne niż /a/* /a/? ma pierwszeństwo.
Ścieżka /* musi być dołączona lub wykluczona ścieżka.

Indeksy pełnotekstowe

Uwaga

Aby określić indeks pełnotekstowy, należy włączyć funkcję pełnotekstowego i hybrydowego wyszukiwania dla interfejsu API NoSQL w wersji zapoznawczej.

Indeksy pełnotekstowe umożliwiają wydajne wyszukiwanie pełnotekstowe i ocenianie przy użyciu indeksu. Definiowanie pełnej ścieżki tekstowej w zasadach indeksowania można łatwo wykonać, uwzględniając sekcję fullTextIndexes zasad indeksowania, która zawiera wszystkie ścieżki tekstowe do indeksowania. Na przykład:

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

Ważne

Zasady indeksowania pełnotekstowego muszą znajdować się w ścieżce zdefiniowanej w zasadach pełnotekstowych kontenera. Dowiedz się więcej o zasadach wektorów kontenerów.

Indeksy wektorowe

Uwaga

Aby określić indeks wektorowy, należy włączyć funkcję wyszukiwania wektorowego w usłudze Azure Cosmos DB.

Indeksy wektorowe zwiększają wydajność podczas przeprowadzania wyszukiwania wektorów przy użyciu funkcji systemowej VectorDistance . Wyszukiwania wektorów mają mniejsze opóźnienia, wyższą przepływność i mniejsze użycie jednostek RU podczas stosowania indeksu wektorowego. Można określić następujące typy zasad indeksu wektorowego:

Type	Opis	Maksymalna liczba wymiarów
`flat`	Przechowuje wektory na tym samym indeksie co inne właściwości indeksowane.	505
`quantizedFlat`	Kwantyzuje (kompresuje) wektory przed zapisaniem w indeksie. Może to poprawić opóźnienie i przepływność kosztem niewielkiej dokładności.	4096
`diskANN`	Tworzy indeks na podstawie nazwy DiskANN na potrzeby szybkiego i wydajnego przybliżonego wyszukiwania.	4096

Kilka kwestii, które należy zwrócić uwagę:

Typy flat i quantizedFlat indeksów stosują indeks usługi Azure Cosmos DB do przechowywania i odczytywania każdego wektora podczas wykonywania wyszukiwania wektorowego. Wyszukiwania wektorowe z indeksem flat to wyszukiwania siłowe i generują 100% dokładności lub kompletności. Oznacza to, że gwarantowane jest znalezienie najbardziej podobnych wektorów w zestawie danych. Istnieje jednak ograniczenie 505 wymiarów dla wektorów w indeksie płaskim.
- Indeks quantizedFlat przechowuje kwantyzowane (skompresowane) wektory indeksu. Wyszukiwania wektorowe z indeksem quantizedFlat są również wyszukiwaniem siłowym, jednak ich dokładność może być nieco mniejsza niż 100%, ponieważ wektory są kwantyzowane przed dodaniem do indeksu. Jednak wyszukiwanie wektorów z quantized flat użyciem powinno mieć mniejsze opóźnienie, wyższą przepływność i niższy koszt jednostek RU niż wyszukiwanie wektorów w indeksie flat . Jest to dobra opcja w scenariuszach, w których używasz filtrów zapytań, aby zawęzić wyszukiwanie wektorów do stosunkowo małego zestawu wektorów, a wymagana jest wysoka dokładność.
- Indeks diskANN jest oddzielnym indeksem zdefiniowanym specjalnie dla wektorów stosujących nazwę DiskANN, zestaw algorytmów indeksowania wektorów o wysokiej wydajności opracowanych przez firmę Microsoft Research. Indeksy DiskANN mogą oferować jedne z najniższych opóźnień, najwyższej przepływności i najniższych zapytań dotyczących kosztów jednostek RU, przy jednoczesnym zachowaniu wysokiej dokładności. Jednak ponieważ diskANN jest przybliżonym indeksem najbliższych sąsiadów (ANN), dokładność może być niższa niż quantizedFlat lub flat.

Indeksy diskANN i quantizedFlat mogą przyjmować opcjonalne parametry kompilacji indeksu, które mogą służyć do dostrajania dokładności i opóźnień kompromisu, który ma zastosowanie do każdego przybliżonego indeksu wektora najbliższych sąsiadów.

quantizationByteSize: Ustawia rozmiar (w bajtach) dla kwantyzacji produktu. Min=1, Default=dynamic (system decyduje), Max=512. Ustawienie tego większego może spowodować większe wyszukiwanie wektorów dokładności kosztem wyższego kosztu jednostek RU i większe opóźnienie. Dotyczy to zarówno quantizedFlat typów indeksów, jak i DiskANN .
- indexingSearchListSize: Określa liczbę wektorów do przeszukiwania podczas konstruowania kompilacji indeksu. Min=10, Default=100, Max=500. Ustawienie tego większego może spowodować większe wyszukiwanie wektorów dokładności kosztem dłuższych czasów kompilacji indeksu i wyższych opóźnień pozyskiwania wektorów. Dotyczy DiskANN to tylko indeksów.

Oto przykład zasad indeksowania z indeksem wektorowym:

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

Ważne

Zasady indeksowania wektorów muszą znajdować się na ścieżce zdefiniowanej w zasadach wektorów kontenera. Dowiedz się więcej o zasadach wektorów kontenerów.

Ważne

Ścieżka wektorowa dodana do sekcji "excludedPaths" zasad indeksowania w celu zapewnienia zoptymalizowanej wydajności wstawiania. Dodanie ścieżki wektora do "excludedPaths" spowoduje wyższe obciążenie jednostek RU i opóźnienie dla wstawiania wektorów.

Indeksy przestrzenne

Podczas definiowania ścieżki przestrzennej w zasadach indeksowania należy zdefiniować, który indeks type ma zostać zastosowany do tej ścieżki. Możliwe typy indeksów przestrzennych to:

Osoba
Wielokąt
MultiPolygon
LineString

Usługa Azure Cosmos DB domyślnie nie tworzy żadnych indeksów przestrzennych. Jeśli chcesz używać wbudowanych funkcji przestrzennych SQL, utwórz indeks przestrzenny dla wymaganych właściwości. Zobacz tę sekcję, aby zapoznać się z przykładami zasad indeksowania na potrzeby dodawania indeksów przestrzennych.

Indeksy krotek

Indeksy krotek są przydatne podczas filtrowania w wielu polach w elemecie tablicy. Indeksy krotki są definiowane w sekcji includedPaths zasad indeksowania przy użyciu specyfikatora krotki "[]".

Uwaga

W przeciwieństwie do dołączonych lub wykluczonych ścieżek nie można utworzyć ścieżki z symbolem wieloznacznymi /*. Każda ścieżka krotki musi kończyć się ciągiem "/?". Jeśli krotka w ścieżce krotki nie istnieje w elemencie, do indeksu zostanie dodana wartość wskazująca, że krotka jest niezdefiniowana.

Ścieżki krotki tablicowej zostaną zdefiniowane w sekcji includedPaths i będą używać następującej notacji.

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

Należy pamiętać, że:

Pierwsza część, prefiks ścieżki, jest ścieżką wspólną między krotkami. Jest to ścieżka z katalogu głównego do tablicy. W naszym przykładzie jest to "/events".
Dalej znajduje się specyfikator symboli wieloznacznych tablicy "[]". Wszystkie ścieżki krotki tablicy powinny mieć specyfikator wieloznaczny tablicy przed specyfikatorem krotki "{}".
Następnie określa krotki przy użyciu specyfikatora krotki "{}".
Krotki będą oddzielone przecinkami.
Krotka musi używać tej samej specyfikacji ścieżki co inne ścieżki indeksu z kilkoma wyjątkami:
Krotki nie powinny zaczynać się od wiodącego ciągu "/".
Krotki nie powinny mieć symboli wieloznacznych tablicy.
Krotki nie powinny kończyć się "?" lub "*"
“?” jest ostatnim segmentem w ścieżce krotki i powinien być określony bezpośrednio po segmencie specyfikatora krotki.

Na przykład:

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

Oto kilka przykładów prawidłowych ścieżek krotki tablicy:

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

Oto kilka przykładów nieprawidłowych ścieżek krotki tablicy

/events/[]/{name/[]/first, category}/?
- Jedna z krotk ma symbol wieloznaczny tablicy
/events/[]/{name, category}/*
- Ostatni segment w ścieżce krotki tablicowej powinien mieć wartość "?" i nie *
/events/[]/{{name, first},category}/?
- Specyfikator krotki jest zagnieżdżony
/events/{name, category}/?
- Brak symbolu wieloznacznych tablicy przed specyfikatorem krotki
/events/[]/{/name,/category}/?
- Krotki zaczynają się od wiodących /
/events/[]/{name/?,category/?}/?
- Krotki kończą się na ?
/city/[]/events/[]/{name, category}/?
- Prefiks ścieżki jako 2 symbole wieloznaczne

Indeksy złożone

Zapytania, które mają klauzulę ORDER BY z co najmniej dwiema właściwościami, wymagają indeksu złożonego. Możesz również zdefiniować indeks złożony, aby zwiększyć wydajność wielu zapytań dotyczących równości i zakresu. Domyślnie nie zdefiniowano indeksów złożonych, dlatego należy w razie potrzeby dodać indeksy złożone.

W przeciwieństwie do dołączonych lub wykluczonych ścieżek nie można utworzyć ścieżki z symbolem wieloznacznymi /* . Każda ścieżka złożona ma niejawną /? ścieżkę na końcu ścieżki, której nie trzeba określać. Ścieżki złożone prowadzą do wartości skalarnej, która jest jedyną wartością uwzględniną w indeksie złożonym. Jeśli ścieżka w indeksie złożonym nie istnieje w elemencie lub prowadzi do wartości innej niż niezdefiniowana, wartość zostanie dodana do indeksu, aby wskazać, że ścieżka jest niezdefiniowana.

Podczas definiowania indeksu złożonego należy określić:

Co najmniej dwie ścieżki właściwości. Sekwencja, w której zdefiniowano ścieżki właściwości, ma znaczenie.
Kolejność (rosnąco lub malejąco).

Uwaga

Po dodaniu indeksu złożonego zapytanie będzie używać istniejących indeksów zakresu do momentu zakończenia dodawania nowego indeksu złożonego. W związku z tym podczas dodawania indeksu złożonego nie można od razu obserwować poprawy wydajności. Istnieje możliwość śledzenia postępu transformacji indeksu przy użyciu jednego z zestawów SDK.

Zapytania ORDER BY dotyczące wielu właściwości:

Poniższe zagadnienia są używane podczas używania indeksów złożonych dla zapytań z klauzulą ORDER BY z co najmniej dwiema właściwościami.

Jeśli ścieżki indeksu złożonego nie są zgodne z sekwencją właściwości w ORDER BY klauzuli, indeks złożony nie może obsługiwać zapytania.
Kolejność ścieżek indeksu złożonego (rosnąco lub malejąco) powinna być również zgodna z order klauzulą w klauzuli ORDER BY .
Indeks złożony obsługuje również klauzulę ORDER BY z odwrotną kolejnością we wszystkich ścieżkach.

Rozważmy następujący przykład, w którym indeks złożony jest definiowany na podstawie nazwy właściwości, wieku i _ts:

Indeks złożony	Przykładowe `ORDER BY` zapytanie	Obsługiwane przez indeks złożony?
`(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`

Należy dostosować zasady indeksowania, aby umożliwić obsługę wszystkich niezbędnych ORDER BY zapytań.

Zapytania z filtrami na wielu właściwościach

Jeśli zapytanie zawiera filtry dla co najmniej dwóch właściwości, pomocne może być utworzenie indeksu złożonego dla tych właściwości.

Rozważmy na przykład następujące zapytanie, które ma zarówno filtr równości, jak i zakresu:

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

To zapytanie jest bardziej wydajne, zużywając mniej czasu i zużywając mniej jednostek RU, jeśli jest w stanie zastosować indeks złożony w systemie (name ASC, age ASC).

Zapytania z wieloma filtrami zakresu można również zoptymalizować za pomocą indeksu złożonego. Jednak każdy pojedynczy indeks złożony może zoptymalizować tylko jeden filtr zakresu. Filtry zakresu obejmują >, , <, <=>=, i !=. Filtr zakresu powinien być zdefiniowany jako ostatni w indeksie złożonym.

Rozważ następujące zapytanie z filtrem równości i dwoma filtrami zakresu:

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

To zapytanie jest bardziej wydajne dzięki indeksowi złożonego w systemach (name ASC, age ASC) i (name ASC, _ts ASC). Jednak zapytanie nie korzystałoby z indeksu (age ASC, name ASC) złożonego, ponieważ właściwości z filtrami równości muszą być zdefiniowane najpierw w indeksie złożonym. Dwa oddzielne indeksy złożone są wymagane zamiast pojedynczego indeksu złożonego, (name ASC, age ASC, _ts ASC) ponieważ każdy indeks złożony może zoptymalizować tylko jeden filtr zakresu.

Poniższe zagadnienia są używane podczas tworzenia indeksów złożonych dla zapytań z filtrami w wielu właściwościach

Wyrażenia filtrów mogą używać wielu indeksów złożonych.
Właściwości filtru zapytania powinny być zgodne z właściwościami w indeksie złożonym. Jeśli właściwość znajduje się w indeksie złożonym, ale nie jest uwzględniona w zapytaniu jako filtr, zapytanie nie będzie korzystać z indeksu złożonego.
Jeśli zapytanie ma inne właściwości w filtrze, które nie są zdefiniowane w indeksie złożonym, kombinacja indeksów złożonych i indeksów zakresu jest używana do oceny zapytania. Wymaga to mniejszej liczby jednostek RU niż wyłącznie przy użyciu indeksów zakresu.
Jeśli właściwość ma filtr zakresu (>, , <<=, >=lub !=), ta właściwość powinna być zdefiniowana jako ostatnia w indeksie złożonym. Jeśli zapytanie ma więcej niż jeden filtr zakresu, może skorzystać z wielu indeksów złożonych.
Podczas tworzenia indeksu złożonego w celu optymalizacji zapytań za pomocą wielu filtrów ORDER indeks złożony nie ma wpływu na wyniki. Ta właściwość jest opcjonalna.

Rozważmy następujące przykłady, w których indeks złożony jest zdefiniowany na podstawie nazwy właściwości, wieku i znacznika czasu:

Indeks złożony	Przykładowe zapytanie	Obsługiwane przez indeks złożony?
`(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`

Zapytania z filtrem i ORDER BY

Jeśli zapytanie filtruje co najmniej jedną właściwości i ma inne właściwości w klauzuli ORDER BY, warto dodać właściwości w filtrze do klauzuli ORDER BY .

Na przykład przez dodanie właściwości w filtrze ORDER BY do klauzuli można ponownie napisać następujące zapytanie w celu zastosowania indeksu złożonego:

Wykonywanie zapytań przy użyciu indeksu zakresu:

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

Wykonywanie zapytań przy użyciu indeksu złożonego:

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

Te same optymalizacje zapytań można uogólnić dla wszystkich ORDER BY zapytań z filtrami, pamiętając, że poszczególne indeksy złożone mogą obsługiwać tylko jeden filtr zakresu.

Wykonywanie zapytań przy użyciu indeksu zakresu:

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

Wykonywanie zapytań przy użyciu indeksu złożonego:

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

Ponadto można użyć indeksów złożonych, aby zoptymalizować zapytania za pomocą funkcji systemowych i ORDER BY:

Wykonywanie zapytań przy użyciu indeksu zakresu:

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

Wykonywanie zapytań przy użyciu indeksu złożonego:

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

Podczas tworzenia indeksów złożonych należy wziąć pod uwagę następujące kwestie, aby zoptymalizować zapytanie za pomocą filtru i ORDER BY klauzuli:

Jeśli nie zdefiniujesz indeksu złożonego dla zapytania z filtrem dla jednej właściwości i oddzielnej ORDER BY klauzuli przy użyciu innej właściwości, zapytanie nadal powiedzie się. Jednak koszt jednostek ŻĄDANIA zapytania można zmniejszyć przy użyciu indeksu złożonego, szczególnie jeśli właściwość w ORDER BY klauzuli ma wysoką kardynalność.
Jeśli zapytanie filtruje właściwości, te właściwości powinny zostać uwzględnione jako pierwsze w klauzuli ORDER BY .
Jeśli zapytanie filtruje wiele właściwości, filtry równości muszą być pierwszymi właściwościami w klauzuli ORDER BY .
Jeśli zapytanie filtruje wiele właściwości, można mieć maksymalnie jeden filtr zakresu lub funkcję systemową używaną dla indeksu złożonego. Właściwość używana w filtrze zakresu lub funkcji systemowej powinna być zdefiniowana jako ostatnia w indeksie złożonym.
Wszystkie zagadnienia dotyczące tworzenia indeksów złożonych dla ORDER BY zapytań z wieloma właściwościami i zapytaniami z filtrami dla wielu właściwości nadal mają zastosowanie.

Indeks złożony	Przykładowe `ORDER BY` zapytanie	Obsługiwane przez indeks złożony?
`(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`

Zapytania z filtrem i agregacji

Jeśli zapytanie filtruje co najmniej jedną właściwościę i ma funkcję systemową agregacji, przydatne może być utworzenie indeksu złożonego dla właściwości w funkcji systemu filtru i agregacji. Ta optymalizacja dotyczy funkcji systemowych SUM i AVG .

Poniższe zagadnienia dotyczą tworzenia indeksów złożonych w celu zoptymalizowania zapytania za pomocą funkcji systemu filtru i agregacji.

Indeksy złożone są opcjonalne podczas uruchamiania zapytań z agregacjami. Jednak koszt jednostek ŻĄDANIA zapytania można często zmniejszyć za pomocą indeksu złożonego.
Jeśli zapytanie filtruje wiele właściwości, filtry równości muszą być pierwszymi właściwościami w indeksie złożonym.
Można mieć maksymalnie jeden filtr zakresu na indeks złożony i musi znajdować się we właściwości w funkcji systemu agregacji.
Właściwość w funkcji systemowej agregacji powinna być zdefiniowana jako ostatnia w indeksie złożonym.
Parametr order (ASC lub DESC) nie ma znaczenia.

Indeks złożony	Przykładowe zapytanie	Obsługiwane przez indeks złożony?
`(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`

Indeksy złożone z symbolami wieloznacznymi tablicy

Poniżej znajduje się przykład indeksu złożonego zawierającego symbol wieloznaczny tablicy.

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

Przykładowe zapytanie, które może korzystać z tego indeksu złożonego, to:

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

Modyfikowanie zasad indeksowania

Zasady indeksowania kontenera można aktualizować w dowolnym momencie przy użyciu witryny Azure Portal lub jednego z obsługiwanych zestawów SDK. Aktualizacja zasad indeksowania wyzwala transformację ze starego indeksu do nowego, która jest wykonywana w trybie online i w miejscu (więc w trakcie operacji nie jest zużywana dodatkowa ilość miejsca do magazynowania). Stare zasady indeksowania są efektywnie przekształcane w nowe zasady bez wpływu na dostępność zapisu, dostępność odczytu lub przepływność aprowizowaną w kontenerze. Transformacja indeksu jest operacją asynchroniczną, a czas potrzebny do ukończenia zależy od aprowizowanej przepływności, liczby elementów i ich rozmiaru. Jeśli należy wprowadzić wiele aktualizacji zasad indeksowania, zaleca się wykonanie wszystkich zmian jako pojedynczej operacji w celu jak najszybszego zakończenia transformacji indeksu.

Ważne

Przekształcanie indeksu to operacja, która zużywa jednostki żądań i aktualizuje zasady indeksu, jest operacją związaną z ru. Jeśli jakikolwiek termin indeksowania zostanie pominięty, klient zobaczy zapytania zużywające więcej ogólnych jednostek RU.

Uwaga

Postęp transformacji indeksu można śledzić w witrynie Azure Portal lub przy użyciu jednego z zestawów SDK.

Podczas przekształceń indeksu nie ma wpływu na dostępność zapisu. Transformacja indeksu używa aprowizowanej jednostki RU, ale z niższym priorytetem niż operacje CRUD lub zapytania.

Podczas dodawania nowych ścieżek indeksowanych nie ma wpływu na dostępność odczytu. Zapytania będą korzystać tylko z nowych ścieżek indeksowanych po zakończeniu transformacji indeksu. Innymi słowy, podczas dodawania nowej ścieżki indeksowanej zapytania, które korzystają z tej ścieżki indeksowanej, mają taką samą wydajność przed i podczas transformacji indeksu. Po zakończeniu przekształcania indeksu aparat zapytań zacznie używać nowych ścieżek indeksowanych.

Podczas usuwania indeksowanych ścieżek należy zgrupować wszystkie zmiany w jednej transformacji zasad indeksowania. Jeśli usuniesz wiele indeksów i zrobisz to w jednej zmianie zasad indeksowania, aparat zapytań zapewnia spójne i kompletne wyniki w całej transformacji indeksu. Jeśli jednak usuniesz indeksy za pomocą wielu zmian zasad indeksowania, aparat zapytań nie zapewni spójnych ani pełnych wyników do momentu zakończenia wszystkich przekształceń indeksu. Większość deweloperów nie usuwa indeksów, a następnie natychmiast spróbuje uruchomić zapytania korzystające z tych indeksów, więc w praktyce taka sytuacja jest mało prawdopodobna.

Po usunięciu ścieżki indeksowanej aparat zapytań natychmiast przestanie go używać i wykona pełne skanowanie.

Uwaga

Jeśli to możliwe, zawsze należy pogrupować wiele usuwania indeksów w jedną modyfikację zasad indeksowania.

Ważne

Usunięcie indeksu zaczyna obowiązywać natychmiast, podczas gdy dodawanie nowego indeksu zajmuje trochę czasu, ponieważ wymaga przekształcenia indeksowania. Podczas zastępowania jednego indeksu innym (na przykład zastąpienie pojedynczego indeksu właściwości indeksem złożonym) najpierw dodaj nowy indeks, a następnie zaczekaj na zakończenie przekształcenia indeksu przed usunięciem poprzedniego indeksu z zasad indeksowania. W przeciwnym razie negatywnie wpłynie to na możliwość wykonywania zapytań względem poprzedniego indeksu i może spowodować przerwanie aktywnych obciążeń odwołujących się do poprzedniego indeksu.

Zasady indeksowania i czas wygaśnięcia

Korzystanie z funkcji Czas wygaśnięcia (TTL) wymaga indeksowania. To oznacza, że:

Nie można aktywować czasu wygaśnięcia w kontenerze, w którym tryb indeksowania jest ustawiony na nonewartość ,
Nie można ustawić trybu indeksowania na Brak w kontenerze, w którym jest aktywowany czas wygaśnięcia.

W scenariuszach, w których nie trzeba indeksować ścieżki właściwości, ale czas wygaśnięcia jest wymagany, można użyć zasad indeksowania z trybem indeksowania ustawionym na consistent, bez dołączonych ścieżek i /* jako jedyną wykluczona ścieżka.

Udostępnij za pośrednictwem

Zasady indeksowania w usłudze Azure Cosmos DB

Tryb indeksowania

Rozmiar indeksu

Dołączanie i wykluczanie ścieżek właściwości

Strategia dołączania/wykluczania

Pierwszeństwo dołączania/wykluczania

Indeksy pełnotekstowe

Indeksy wektorowe

Indeksy przestrzenne

Indeksy krotek

Indeksy złożone

Zapytania ORDER BY dotyczące wielu właściwości:

Zapytania z filtrami na wielu właściwościach

Zapytania z filtrem i ORDER BY

Zapytania z filtrem i agregacji

Indeksy złożone z symbolami wieloznacznymi tablicy

Modyfikowanie zasad indeksowania

Zasady indeksowania i czas wygaśnięcia

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Zasady indeksowania w usłudze Azure Cosmos DB

Tryb indeksowania

Rozmiar indeksu

Dołączanie i wykluczanie ścieżek właściwości

Strategia dołączania/wykluczania

Pierwszeństwo dołączania/wykluczania

Indeksy pełnotekstowe

Indeksy wektorowe

Indeksy przestrzenne

Indeksy krotek

Indeksy złożone

Zapytania ORDER BY dotyczące wielu właściwości:

Zapytania z filtrami na wielu właściwościach

Zapytania z filtrem i ORDER BY

Zapytania z filtrem i agregacji

Indeksy złożone z symbolami wieloznacznymi tablicy

Modyfikowanie zasad indeksowania

Zasady indeksowania i czas wygaśnięcia

Powiązana zawartość

Opinia

Dodatkowe zasoby