Indeksy są ważnym czynnikiem wydajności bazy danych. Podobnie jak indeks książki, który mapuje tematy w książce na numery stron, indeks bazy danych mapuje elementy w bazie danych na ich lokalizacje w bazie danych. Gdy wyślesz zapytanie do bazy danych, może ona użyć indeksu do szybkiego wyszukiwania lokalizacji żądanych elementów.
Na tej stronie opisujemy 2 typy indeksów używane przez Cloud Firestore: indeksy z jednym polem i indeksy złożone.
Definicja i struktura indeksu
Indeks jest zdefiniowany na liście pól danego dokumentu, wraz z odpowiadającym mu trybem indeksowania dla każdego pola.
Indeks zawiera wpis dotyczący każdego pola nazwanego w definicji indeksu. Indeks obejmuje wszystkie dokumenty, które mogą być wynikami dla zapytań opartych na indeksie. Dokument jest uwzględniany w indeksie tylko wtedy, gdy ma ustawioną wartość indeksowaną dla każdego pola używanego w indeksie. Jeśli definicja indeksu odnosi się do pola, dla którego dokument nie ma ustawionej wartości, dokument nie zostanie uwzględniony w indeksie, więc nigdy nie zostanie zwrócony w wyniku żadnego zapytania korzystającego z indeksu.
Indeks złożony jest sortowany według wartości pól w kolejności określonej w definicji indeksu.
Indeks za każdym zapytaniem
Jeśli dla zapytania nie ma indeksu, większość baz danych indeksuje jego zawartość po kolei. Jest to powolny proces, który spowalnia pracę w miarę rozwoju bazy danych. Cloud Firestore gwarantuje wysoką wydajność zapytań dzięki użyciu indeksów do wszystkich zapytań. W efekcie wydajność zapytań zależy od rozmiaru zbioru wyników, a nie od liczby elementów w bazie danych.
Mniej zarządzania indeksami, więcej możliwości tworzenia aplikacji
Cloud Firestore obejmuje funkcje, które skracają czas poświęcany na zarządzanie indeksami. Indeksy wymagane do wykonywania najbardziej podstawowych zapytań są tworzone automatycznie. W miarę używania i testowania aplikacji Cloud Firestore pomaga określić i utworzyć dodatkowe indeksy, których potrzebuje Twoja aplikacja.
Typy indeksów
Cloud Firestore używa 2 typów indeksów: pojedynczego pola i złożonego. Oprócz liczby zindeksowanych pól indeksy z pojedynczym polem i złożone różnią się sposobem zarządzania nimi.
Indeksy z jednym polem
Indeks z 1 polem przechowuje posortowane mapowanie wszystkich dokumentów w kolekcji, które zawierają określone pole. Każda pozycja w indeksie z pojedynczym polem rejestruje wartość dokumentu dla określonego pola i lokalizację tego dokumentu w bazie danych. Cloud Firestore używa tych indeksów do wykonywania wielu podstawowych zapytań. Aby zarządzać indeksami z pojedynczymi polami, skonfiguruj ustawienia automatycznego indeksowania i wykluczenia indeksów w bazie danych.
Automatyczne indeksowanie
Domyślnie Cloud Firestore automatycznie przechowuje indeksy z jednym polem dla każdego pola dokumentu i każdego pola podrzędnego w mapie. Cloud Firestore używa następujących domyślnych ustawień indeksów z pojedynczym polem:
Dla każdego pola, które nie jest tablicą lub mapą, Cloud Firestore definiuje 2 indeksy z jednym polem o zakresie kolekcji – jeden w trybie rosnącym, a drugi w trybie malejącym.
Dla każdego pola mapy Cloud Firestore tworzy te elementy:
- Jeden indeks rosnący o zakresie na poziomie zbioru dla każdego pola podrzędnego niebędącego tablicą i niemającego mapy.
- Jeden indeks malejący o zakresie na poziomie zbioru dla każdego pola podrzędnego innego niż pole tablicy lub pola podrzędnego.
- Jeden indeks tablicy-contains w zakresie kolekcji dla każdego pola podrzędnego tablicy.
- Cloud Firestore indeksuje rekursywnie każde podpole mapy.
Dla każdego pola tablicy w dokumencie Cloud Firestore tworzy i zarządza indeksem w zakresie dotyczącym tablicy w zakresie kolekcji.
Indeksy z jednym polem z zakresem grupy kolekcji nie są domyślnie obsługiwane.
Wykluczenie indeksu pojedynczego pola
Możesz wykluczyć pole z ustawień automatycznego indeksowania, tworząc wykluczenie indeksu pojedynczego pola. Wykluczenie z indeksowania zastępuje ustawienia automatycznego indeksu dotyczące całej bazy danych. Wyjątek może umożliwiać korzystanie z indeksu z jednym polem, który w innym przypadku zostałby wyłączony przez ustawienia automatycznego indeksowania, lub wyłączał indeks z pojedynczym polem, który w innym przypadku zostałby włączony przez automatyczne indeksowanie. Informacje o sytuacjach, w których wykluczenia mogą być przydatne, znajdziesz w artykule ze sprawdzonymi metodami indeksowania.
Użyj wartości ścieżki pola *, aby dodać wykluczenia indeksu na poziomie kolekcji do wszystkich pól w grupie kolekcji. Na przykład dla grupy kolekcji comments ustaw ścieżkę pola na *, aby dopasować wszystkie pola w grupie kolekcji comments, i wyłącz indeksowanie wszystkich pól w grupie kolekcji. Potem możesz dodać wykluczenia, aby indeksować tylko pola wymagane przy zapytaniach. Zmniejszenie liczby zindeksowanych pól obniża koszty przechowywania danych i może poprawić wydajność zapisu.
Jeśli utworzysz wykluczenie indeksu pojedynczego pola dla pola mapy, pola podrzędne mapy odziedziczą te ustawienia. W przypadku poszczególnych pól podrzędnych możesz jednak zdefiniować wykluczenia z indeksów obejmujące jedno pole. Jeśli usuniesz wykluczenie dla pola podrzędnego, pole podrzędne odziedziczy ustawienia wykluczenia z pola nadrzędnego (jeśli istnieją) lub ustawienia dotyczące całej bazy danych, jeśli nie istnieją wykluczenia nadrzędne.
Informacje o tym, jak tworzyć wykluczenia indeksów pojedynczych pól i nimi zarządzać, znajdziesz w sekcji Zarządzanie indeksami w Cloud Firestore.
Indeksy złożone
Indeks złożony przechowuje posortowane mapowanie wszystkich dokumentów w kolekcji na podstawie uporządkowanej listy pól do indeksowania.
Cloud Firestore używa indeksów złożonych do obsługi zapytań, których nie obsługują jeszcze indeksy z pojedynczym polem.
Ze względu na dużą liczbę możliwych kombinacji pól Cloud Firestore nie tworzy automatycznie indeksów złożonych tak jak w przypadku indeksów z pojedynczymi polami. Zamiast tego Cloud Firestore pomaga identyfikować i tworzyć wymagane indeksy złożone podczas tworzenia aplikacji.
Za każdym razem, gdy spróbujesz wykonać zapytanie, które nie jest obsługiwane przez indeks, Cloud Firestore zwraca komunikat o błędzie z linkiem, który możesz wykonać, aby utworzyć brakujący indeks.
Indeksy złożone można też definiować i zarządzać nimi ręcznie za pomocą konsoli lub interfejsu wiersza poleceń Firebase. Więcej informacji o tworzeniu indeksów złożonych i zarządzaniu nimi znajdziesz w artykule Zarządzanie indeksami.
Tryby indeksowania i zakresy zapytań
Indeksy z jednym polem i złożone konfiguruje się inaczej, ale oba te tryby wymagają skonfigurowania trybów indeksów i zakresów zapytań dla indeksów.
Tryby indeksowania
Podczas definiowania indeksu wybierasz tryb indeksowania dla każdego zindeksowanego pola. Tryb indeksu każdego pola obsługuje określone klauzule zapytania w tym polu. Do wyboru masz te tryby indeksowania:
| Tryb indeksu | Opis |
|---|---|
| Rosnąco | Obsługuje klauzule zapytań <, <=, ==, >=, >, !=, in i not-in w polu oraz obsługuje sortowanie wyników w kolejności rosnącej na podstawie tej wartości pola. |
| Malejąco | Obsługuje klauzule zapytań <, <=, ==, >=, >, !=, in i not-in w polu oraz obsługuje sortowanie wyników w kolejności malejącej na podstawie tej wartości pola. |
| Tablica zawierająca | Obsługuje klauzule zapytania array-contains i array-contains-any w tym polu. |
| Wektor | Obsługuje klauzule zapytania FindNearest w tym polu. |
Zakresy zapytań
Każdy indeks jest ograniczony do kolekcji lub grupy kolekcji. Jest to tzw. zakres zapytania indeksu:
- Zakres kolekcji
- Cloud Firestore domyślnie tworzy indeksy z zakresem kolekcji. Te indeksy obsługują zapytania, które zwracają wyniki z 1 kolekcji.
- Zakres grupy kolekcji
- Grupa kolekcji zawiera wszystkie kolekcje z tym samym identyfikatorem. Aby uruchomić zapytanie dotyczące grupy kolekcji, które zwróci przefiltrowane lub uporządkowane wyniki z grupy kolekcji, musisz utworzyć odpowiedni indeks z zakresem grupy kolekcji.
Domyślna kolejność i pole __name__
Oprócz sortowania dokumentów według trybów indeksowania określonych dla każdego pola (rosnąco lub malejąco) indeksy stosują końcowe sortowanie według pola __name__ każdego dokumentu. Wartość pola __name__ jest ustawiona na pełna ścieżka do dokumentu. Oznacza to, że dokumenty w zestawie wyników z tymi samymi wartościami pól są sortowane według ścieżki dokumentu.
Domyślnie pole __name__ jest sortowane w tym samym kierunku co ostatnie posortowane pole w definicji indeksu. Przykład:
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| miejscowości | – imię i nazwisko, __name__ |
Kolekcja |
| miejscowości | stan, __name__ |
Kolekcja |
| miejscowości | kraj, populacja: , __name__ |
Kolekcja |
Aby posortować wyniki według innego niż domyślny kierunek __name__, musisz utworzyć ten indeks.
Indeks idealny
Idealny indeks dla zapytania, który umożliwia najefektywniejsze wykonywanie zapytania, jest zdefiniowany dla tych właściwości w takiej kolejności:
- Pola używane w filtrach równości
- Pola używane w kolejności sortowania
- Pola używane w filtrach zakresu i nierówności (które nie zostały uwzględnione w kolejności sortowania)
- Pola używane w agregacjach (które nie zostały jeszcze uwzględnione w kolejności sortowania ani filtrach zakresu i nierówności)
Firestore oblicza wyniki zapytań w ten sposób:
- Identyfikuje indeks odpowiadający zbieraniu danych zapytania, właściwościom filtrów, operatorom filtrów i kolejnościom sortowania.
- Określa pozycję indeksu, od której ma się rozpocząć skanowanie przy użyciu filtrów równości zapytania oraz filtrów zakresu i nierówności w pierwszej kolejności według pola
- Rozpoczyna skanowanie indeksu, zwracając każdy dokument zgodny ze wszystkimi filtrami, aż:
- napotka dokument, który nie spełnia warunków filtra, i potwierdza, że żaden kolejny dokument nigdy nie spełni warunków filtra;
- osiągnie koniec indeksu lub
- zebrano maksymalną liczbę wyników żądanych przez zapytanie
Przykład indeksowania
Dzięki automatycznemu tworzeniu indeksów z jednym polem Cloud Firestore umożliwia aplikacji szybką obsługę najbardziej podstawowych zapytań do bazy danych.
Indeksy z jednym polem umożliwiają wykonywanie prostych zapytań na podstawie wartości pól i komparatorów <, <=, ==, >=, > i in. W przypadku pól tablicy pozwalają one wykonywać zapytania array-contains i array-contains-any.
Aby to zilustrować, spójrz na poniższe przykłady z perspektywy tworzenia indeksu. Ten fragment kodu tworzy kilka dokumentów city w kolekcji cities oraz ustawia pola name, state, country, capital, population i tags dla każdego dokumentu:
Internet
var citiesRef = db.collection("cities");
citiesRef.doc("SF").set({
name: "San Francisco", state: "CA", country: "USA",
capital: false, population: 860000,
regions: ["west_coast", "norcal"] });
citiesRef.doc("LA").set({
name: "Los Angeles", state: "CA", country: "USA",
capital: false, population: 3900000,
regions: ["west_coast", "socal"] });
citiesRef.doc("DC").set({
name: "Washington, D.C.", state: null, country: "USA",
capital: true, population: 680000,
regions: ["east_coast"] });
citiesRef.doc("TOK").set({
name: "Tokyo", state: null, country: "Japan",
capital: true, population: 9000000,
regions: ["kanto", "honshu"] });
citiesRef.doc("BJ").set({
name: "Beijing", state: null, country: "China",
capital: true, population: 21500000,
regions: ["jingjinji", "hebei"] });
Przy założeniu, że Cloud Firestore aktualizuje domyślne ustawienia indeksowania, Cloud Firestore aktualizuje 1 rosnący indeks pojedynczego pola na pole niebędące tablicą, 1 malejący indeks pojedynczego pola dla pola niebędącego tablicą i 1 indeks zawierający 1 pole tablicy. Każdy wiersz w poniższej tabeli odpowiada wpisowi w indeksie z jednym polem:
| Kolekcja | Zindeksowanie pola | Zakres zapytania |
|---|---|---|
| miejscowości | Nazwa zasobu | Kolekcja |
| miejscowości | stan | Kolekcja |
| miejscowości | kraj | Kolekcja |
| miejscowości | Stolica: | Kolekcja |
| miejscowości | populacja | Kolekcja |
| miejscowości | Nazwa zasobu | Kolekcja |
| miejscowości | stan | Kolekcja |
| miejscowości | kraj | Kolekcja |
| miejscowości | Stolica: | Kolekcja |
| miejscowości | populacja | Kolekcja |
| miejscowości | Liczba regionów: array-contains |
Kolekcja |
Zapytania obsługiwane przez indeksy z jednym polem
Korzystając z tych automatycznie utworzonych indeksów z pojedynczym polem, możesz wykonywać proste zapytania, takie jak:
Internet
const stateQuery = citiesRef.where("state", "==", "CA");
const populationQuery = citiesRef.where("population", "<", 100000);
const nameQuery = citiesRef.where("name", ">=", "San Francisco");
Możesz też tworzyć zapytania in i zapytania złożone (==):
Internet
citiesRef.where('country', 'in', ["USA", "Japan", "China"])
// Compound equality queries
citiesRef.where("state", "==", "CO").where("name", "==", "Denver")
citiesRef.where("country", "==", "USA")
.where("capital", "==", false)
.where("state", "==", "CA")
.where("population", "==", 860000)
Jeśli chcesz uruchomić zapytanie złożone, które korzysta z porównania zakresów (<, <=, > lub >=), lub jeśli chcesz posortować dane według innego pola, musisz utworzyć dla tego zapytania indeks złożony.
Indeks array-contains umożliwia wysyłanie zapytań dotyczących pola tablicy regions:
Internet
citiesRef.where("regions", "array-contains", "west_coast")
// array-contains-any and array-contains use the same indexes
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])
Zapytania obsługiwane przez indeksy złożone
Cloud Firestore używa indeksów złożonych do obsługi zapytań złożonych, których nie obsługują indeksy pojedynczych pól. Indeks złożony będzie na przykład potrzebny w przypadku tych zapytań:
Internet
citiesRef.where("country", "==", "USA").orderBy("population", "asc")
citiesRef.where("country", "==", "USA").where("population", "<", 3800000)
citiesRef.where("country", "==", "USA").where("population", ">", 690000)
// in and == clauses use the same index
citiesRef.where("country", "in", ["USA", "Japan", "China"])
.where("population", ">", 690000)
Te zapytania wymagają podanego niżej indeksu złożonego. W przypadku pola country w zapytaniu stosowana jest równość (== lub in), więc możesz w tym polu użyć trybu indeksu rosnącego lub malejącego. Domyślnie klauzule nierówności stosują rosnącą kolejność sortowania na podstawie pola w klauzuli nierówności.
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| miejscowości | Kraj: (lub ), populacja: | Kolekcja |
Aby wykonać te same zapytania, ale z malejącą kolejnością sortowania, potrzebujesz dodatkowego indeksu złożonego dla kolumny population w kierunku malejącym:
Internet
citiesRef.where("country", "==", "USA").orderBy("population", "desc")
citiesRef.where("country", "==", "USA")
.where("population", "<", 3800000)
.orderBy("population", "desc")
citiesRef.where("country", "==", "USA")
.where("population", ">", 690000)
.orderBy("population", "desc")
citiesRef.where("country", "in", ["USA", "Japan", "China"])
.where("population", ">", 690000)
.orderBy("population", "desc")
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| miejscowości | kraj, populacja: | Kolekcja |
| miasta | kraj, liczba ludności | Kolekcja |
Musisz też utworzyć indeks złożony, aby połączyć zapytanie array-contains lub array-contains-any z dodatkowymi klauzulami.
Internet
citiesRef.where("regions", "array-contains", "east_coast")
.where("capital", "==", true)
// array-contains-any and array-contains use the same index
citiesRef.where("regions", "array-contains-any", ["west_coast", "east_coast"])
.where("capital", "==", true)
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| miejscowości | Tagi array-contains, (lub ) wielka litera | Kolekcja |
Zapytania obsługiwane przez indeksy grup kolekcji
Aby zademonstrować indeks z zakresem grupy kolekcji, wyobraź sobie, że dodajesz kolekcję podrzędną landmarks do niektórych dokumentów city:
Internet
var citiesRef = db.collection("cities");
citiesRef.doc("SF").collection("landmarks").doc().set({
name: "Golden Gate Bridge",
category : "bridge" });
citiesRef.doc("SF").collection("landmarks").doc().set({
name: "Golden Gate Park",
category : "park" });
citiesRef.doc("DC").collection("landmarks").doc().set({
name: "National Gallery of Art",
category : "museum" });
citiesRef.doc("DC").collection("landmarks").doc().set({
name: "National Mall",
category : "park" });
Korzystając z poniższego indeksu pojedynczego pola z zakresem kolekcji, możesz wysyłać zapytania do kolekcji landmarks z pojedynczego miasta na podstawie pola category:
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| punkty orientacyjne | Kategoria (lub ) | Kolekcja |
Internet
citiesRef.doc("SF").collection("landmarks").where("category", "==", "park")
citiesRef.doc("SF").collection("landmarks").where("category", "in", ["park", "museum"])
Teraz wyobraź sobie, że chcesz wysyłać zapytania o punkty orientacyjne we wszystkich miastach.
Aby uruchomić to zapytanie w grupie kolekcji zawierającej wszystkie kolekcje landmarks, musisz włączyć indeks pojedynczego pola landmarks z zakresem grupy kolekcji:
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| punkty orientacyjne | Kategoria (lub ) | Grupa kolekcji |
Po włączeniu tego indeksu możesz wysyłać zapytania do grupy kolekcji landmarks:
Internet
var landmarksGroupRef = db.collectionGroup("landmarks");
landmarksGroupRef.where("category", "==", "park")
landmarksGroupRef.where("category", "in", ["park", "museum"])
Aby uruchomić zapytanie o grupę kolekcji, które zwraca przefiltrowane lub uporządkowane wyniki, musisz włączyć odpowiedni indeks z pojedynczym polem lub złożony z zakresem grupy kolekcji. Zapytania dotyczące grup kolekcji, które nie filtrują ani nie porządkują wyników, nie wymagają jednak żadnych dodatkowych definicji indeksów.
Możesz na przykład uruchomić to zapytanie dotyczące grupy kolekcji bez włączania dodatkowego indeksu:
Internet
db.collectionGroup("landmarks").get()
Wpisy indeksu
Skonfigurowane indeksy projektu i struktura dokumentu określają liczbę wpisów w indeksach dokumentu. Wpisy indeksu wliczają się do limitu liczby wpisów indeksu.
Poniższy przykład pokazuje wpisy indeksu dokumentu.
Dokument
/cities/SF
city_name : "San Francisco"
temperatures : {summer: 67, winter: 55}
neighborhoods : ["Mission", "Downtown", "Marina"]
Indeksy jednopolowe
- nazwa_miasta AS
- nazwa_miasta DESC
- temperatury.letnie ASC
- temperatury.lato DESC
- temperatury.zima ASC
- temperatury.zima DESC
- Dzielnice tablica zawiera (ASC i DESC)
Indeksy złożone
- nazwa_miasta ASC, dzielnice ARRAY
- nazwa_miasta DESC, dzielnice ARRAY
Wpisy indeksu
Taka konfiguracja indeksowania powoduje uzyskanie 18 pozycji indeksu dla dokumentu:
| Indeks | Zindeksowane dane |
|---|---|
| Wpisy indeksu pojedynczego pola | |
| nazwa_miasta AS | City_name: "Warszawa" |
| nazwa_miasta DESC | City_name: "Warszawa" |
| temperatury.letnie ASC | temperatura.lato: 67 |
| temperatury.lato DESC | temperatura.lato: 67 |
| temperatury.zima ASC | temperatury.zima: 55 |
| temperatury.zima DESC | temperatury.zima: 55 |
| Tablica dzielnic zawiera ASC | dzielnice: „Misja” |
| Dzielnice – Tablica zawiera DESC | dzielnice: „Misja” |
| Tablica dzielnic zawiera ASC | dzielnice: „centrum” |
| Dzielnice – Tablica zawiera DESC | dzielnice: „centrum” |
| Tablica dzielnic zawiera ASC | dzielnice: „Marina” |
| Dzielnice – Tablica zawiera DESC | dzielnice: „Marina” |
| Wpisy indeksu złożonego | |
| nazwa_miasta ASC, dzielnice ARRAY | City_name: "Warszawa", dzielnice: "Misja" |
| nazwa_miasta ASC, dzielnice ARRAY | City_name: "Warszawa", dzielnice: "centrum" |
| nazwa_miasta ASC, dzielnice ARRAY | City_name: "Warszawa", dzielnice: "Marina" |
| nazwa_miasta DESC, dzielnice ARRAY | City_name: "Warszawa", dzielnice: "Misja" |
| nazwa_miasta DESC, dzielnice ARRAY | City_name: "Warszawa", dzielnice: "centrum" |
| nazwa_miasta DESC, dzielnice ARRAY | City_name: "Warszawa", dzielnice: "Marina" |
Indeksy i ceny
Indeksy są uwzględniane w kosztach miejsca na dane aplikacji. Więcej informacji o sposobie obliczania rozmiaru miejsca na dane indeksów znajdziesz w sekcji Rozmiar wpisu indeksu.
Korzystanie ze scalania indeksu
Mimo że Cloud Firestore używa indeksu dla każdego zapytania, nie potrzeba 1 indeksu na zapytanie. W przypadku zapytań z wieloma klauzulami równości (==) i opcjonalnie z klauzulą orderBy Cloud Firestore może ponownie używać istniejących indeksów. Cloud Firestore może scalić indeksy na potrzeby prostych filtrów równości, aby utworzyć indeksy złożone potrzebne do obsługi zapytań dotyczących większej równości.
Koszty indeksowania można zmniejszyć, określając sytuacje, w których warto skorzystać ze scalenia. Wyobraź sobie na przykład kolekcję restaurants dla aplikacji
do oceniania restauracji:
restauracji
Burgerthyme:
name : "Burger Thyme"
category : "burgers"
city : "San Francisco"
editors_pick : true
star_rating : 4
Teraz wyobraźmy sobie, że ta aplikacja używa zapytań takich jak poniższe. Zwróć uwagę, że aplikacja używa kombinacji klauzul równości dla category, city i editors_pick, zawsze sortując rosnąco według star_rating:
Internet
db.collection("restaurants").where("category", "==", "burgers")
.orderBy("star_rating")
db.collection("restaurants").where("city", "==", "San Francisco")
.orderBy("star_rating")
db.collection("restaurants").where("category", "==", "burgers")
.where("city", "==", "San Francisco")
.orderBy("star_rating")
db.collection("restaurants").where("category", "==", "burgers")
.where("city", "==" "San Francisco")
.where("editors_pick", "==", true )
.orderBy("star_rating")
Możesz utworzyć indeks dla każdego zapytania:
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| restauracje | Kategoria: , liczba gwiazdek: | Kolekcja |
| restauracje | miasto, gwiazdki | Kolekcja |
| restauracje | Kategoria: , miasto: , liczba gwiazdek: | Kolekcja |
| restauracje | Kategoria: , miasto, editor_pick, star_rating | Kolekcja |
Lepszym rozwiązaniem jest zmniejszenie liczby indeksów dzięki możliwości scalania indeksów przez Cloud Firestore na potrzeby klauzul równości:
| Kolekcja | Zindeksowane pola | Zakres zapytania |
|---|---|---|
| restauracje | Kategoria: , liczba gwiazdek: | Kolekcja |
| restauracje | miasto, gwiazdki | Kolekcja |
| restauracje | redaktor_pick, star_rating | Kolekcja |
Ten zbiór indeksów jest nie tylko mniejszy, ale obsługuje też dodatkowe zapytanie:
Internet
db.collection("restaurants").where("editors_pick", "==", true)
.orderBy("star_rating")
Limity indeksowania
Do indeksów obowiązują następujące limity. Informacje o wszystkich limitach znajdziesz w sekcji Limity.
| Limit | Szczegóły |
|---|---|
| Maksymalna liczba indeksów złożonych dla bazy danych |
|
| Maksymalna liczba konfiguracji z jednym polem dla bazy danych |
Konfiguracja na poziomie jednego pola może zawierać wiele konfiguracji tego samego pola. Na przykład wykluczenie indeksowania pojedynczego pola i zasada TTL w tym samym polu są wliczane jako 1 konfiguracja pola i zbliżają się do limitu. |
|
Maksymalna liczba wpisów w indeksie dla każdego dokumentu |
40 000 Liczba wpisów w indeksie to suma następujących wartości dokumentu:
Aby dowiedzieć się, jak Cloud Firestore przekształca dokument i zbiór indeksów w wpisy indeksu, zapoznaj się z tym przykładem liczby wpisów indeksu. |
| Maksymalna liczba pól w indeksie złożonym | 100 |
| Maksymalny rozmiar wpisu w indeksie |
7,5 KiB Aby dowiedzieć się, jak Cloud Firestore oblicza rozmiar wpisu indeksu, zapoznaj się z informacjami o rozmiarze wpisu indeksu. |
| Maksymalna suma rozmiarów wpisów w indeksie dokumentu |
8 MiB Łączny rozmiar dokumentu to suma następujących elementów: |
| Maksymalny rozmiar wartości zindeksowanego pola |
1500 bajtów Wartości pól większe niż 1500 bajtów są obcinane. Zapytania obejmujące obcięte wartości pól mogą zwracać niespójne wyniki. |
Sprawdzone metody indeksowania
W przypadku większości aplikacji do zarządzania indeksami służy automatyczne indeksowanie i linki z komunikatami o błędach. Możesz jednak dodać wykluczenia jednego pola w tych przypadkach:
| Zgłoszenie | Opis |
|---|---|
| Duże pola ciągów | Jeśli masz pole ciągu znaków, które często zawiera wartości długich ciągów, których nie używasz do zapytań, możesz zmniejszyć koszty przechowywania, wykluczając to pole z indeksowania. |
| Duża szybkość zapisu w kolekcji zawierającej dokumenty z wartościami sekwencyjnymi | Jeśli indeksujesz pole, które rośnie lub maleje sekwencyjnie między dokumentami w kolekcji (np. sygnatura czasowa), maksymalna szybkość zapisu w kolekcji wynosi 500 zapisów na sekundę. Jeśli nie wykonujesz zapytań na podstawie pola z wartościami sekwencyjnymi, możesz wykluczyć pole z indeksowania, aby ominąć ten limit. Na przykład w przypadku użycia IoT z dużą częstotliwością zapisu kolekcja zawierająca dokumenty z polem sygnatury czasowej może zbliżyć się do limitu 500 zapisów na sekundę. |
| Pola TTL |
Jeśli używasz zasad TTL (czasu życia), pamiętaj, że pole TTL musi zawierać sygnaturę czasową. Indeksowanie według pól czasu TTL jest domyślnie włączone i może mieć wpływ na wydajność przy wyższym odsetku ruchu. Zalecaną metodą jest dodanie wykluczeń jednego pola do pól TTL. |
| Duże pola tablicowe lub mapowania | Duże pola tablic lub mapy mogą zbliżać się do limitu 40 000 wpisów indeksu na dokument. Jeśli nie wysyłasz zapytań na podstawie dużej tablicy lub pola mapy, wyklucz je z indeksowania. |
Jeśli używasz zapytań z operatorami zakresu i nierówności w wielu polach, zapoznaj się z uwagami na temat indeksowania, które należy wziąć pod uwagę, aby zoptymalizować wydajność i koszty zapytań do Cloud Firestore
Więcej informacji o rozwiązywaniu problemów z indeksowaniem (zachęcanie indeksowania, błędy INVALID_ARGUMENT) znajdziesz na stronie rozwiązywania problemów.