Omówienie Firestore w trybie natywnym

Firestore w trybie natywnym obejmuje 2 zestawy operacji: operacje podstawowe i operacje w potokach.

Operacje Firestore Core zapewniają standardowe funkcje tworzenia, odczytu, aktualizacji i usuwania dokumentów (CRUD), a także wbudowaną obsługę zapytań nasłuchujących w czasie rzeczywistym i trwałości offline. Istotną różnicą operacyjną w tej wersji jest to, że indeksy są opcjonalne i nie są automatycznie tworzone dla pojedynczych pól. Umożliwia to wykonywanie zapytań bez wstępnej konfiguracji indeksu, ale zapytania nieindeksowane będą domyślnie skanować całą kolekcję. W miarę powiększania się zbioru danych może to prowadzić do wydłużenia czasu oczekiwania i wzrostu kosztów.

Operacje potoku Firestore to główna funkcja wersji Firestore Enterprise, oparta na zaawansowanym mechanizmie zapytań, która znacznie rozszerza zakres możliwych zapytań. Operacje potoku wykorzystują elastyczną składnię zapytań i odrębną metodę indeksowania, w której indeksy są opcjonalne i nie są tworzone automatycznie, co umożliwia zaawansowane operacje pobierania danych na potrzeby aplikacji.

Funkcje operacji Firestore Core

Operacje podstawowe umożliwiają standardowe operacje CRUD i zapytania nasłuchujące w czasie rzeczywistym. Jednak gdy używasz tych operacji w wersji Enterprise, podstawowe działanie dotyczące indeksowania i rozliczeń znacznie się różni od wersji Standard.

Funkcje i ciągłość działania

Podstawowe operacje zachowują znaną składnię łańcucha metod (np. .where(), .orderBy()) używaną w wersji Standard. Te operacje obsługują zapytania nasłuchujące w czasie rzeczywistym i trwałość offline w przypadku klientów mobilnych i internetowych. Zalecamy używanie tych operacji w przypadku standardowych zadań transakcyjnych, prostych operacji wyszukiwania i migracji istniejącego kodu aplikacji.

Indeksowanie niestandardowe

W przeciwieństwie do wersji Standard operacje Core w wersji Enterprise nie tworzą automatycznie indeksów jednopolowych. Indeksy są opcjonalne i nie są wymagane do wykonania zapytania. Jeśli brakuje określonego indeksu, zapytanie wykonuje pełne skanowanie kolekcji. Chociaż zapytania nieindeksowane umożliwiają szybkie prototypowanie, mogą działać wolniej i kosztować więcej w miarę wzrostu zbioru danych. Deweloperzy muszą ręcznie tworzyć indeksy, aby zoptymalizować wydajność zapytań i zmniejszyć zużycie jednostek odczytu.

Model rozliczeniowy (oparty na jednostkach)

Opłaty za jednostki odczytu są naliczane w transzach po 4 KB, a nie według liczby dokumentów. Niezindeksowane zapytanie skanujące dużą kolekcję będzie zużywać jednostki odczytu na podstawie łącznej liczby bajtów przeskanowanych we wszystkich dokumentach. Opłaty za jednostki zapisu są naliczane w transzach po 1 KB. Zapisywanie dokumentu zużywa jednostki na dane oraz dodatkowe jednostki na każdy zaktualizowany wpis indeksu. W przeciwieństwie do wersji Standard, która wymusza automatyczne indeksowanie pojedynczych pól, możesz teraz wybrać konkretne pola do indeksowania, aby zoptymalizować koszty i wydajność zapisu.

Funkcje operacji potoku Firestore

Wersja Firestore Enterprise z operacjami potokowymi korzysta z zaawansowanego mechanizmu zapytań, który eliminuje wiele ograniczeń wersji Firestore Standard. Operacje potoku zapewniają setki dodatkowych funkcji zapytań. Operacje potoku mają te możliwości:

Składnia kompozycyjna oparta na etapach

Zapytania dotyczące potoku są tworzone przez zdefiniowanie serii sekwencyjnych etapów, które są wykonywane w określonej kolejności. Umożliwia to wykonywanie złożonych operacji, takich jak filtrowanie wyniku agregacji, co wcześniej nie było możliwe.

Poniższy przykład pokazuje zapytanie potoku, które znajduje liczbę unikalnych identyfikatorów produktów wyświetlonych w ostatnim miesiącu:

guard let cutoffDate = Calendar.current.date(byAdding: .month, value: -1, to: Date()) else {
  return
}
let snapshot = try await db.pipeline()
  .collection("productViews")
  .where(Field("viewedAt").greaterThan(cutoffDate.timeIntervalSince1970))
  .aggregate([Field("productId").countDistinct().as("uniqueProductViews")])
  .execute()

Rozszerzone możliwości

Zapytanie potoku wprowadza wiele nowych funkcji, takich jak:

  • Agregacje: obsługa nowych funkcji agregacji (takich jak sum(...), min(...) i count_distinct(...)) w połączeniu z dowolnymi polami grupowania.
  • Złączenia relacyjne: wykonuj złączenia po stronie serwera w kolekcjach i podkolekcjach za pomocą skorelowanych podzapytań.
  • Złożone filtrowanie: obsługa setek dodatkowych funkcji do wyrażania dowolnie złożonych instrukcji where(...), w tym regex_match(...), add(...) i str_contains(...), bez rygorystycznych wymagań dotyczących indeksów.
  • Częściowe odczyty / projekcje: pobieraj dynamiczne podzbiory dokumentów za pomocą etapów select(...), remove_fields(...) i wielu innych etapów manipulowania dokumentami.

Więcej informacji o tych możliwościach znajdziesz w artykule Wykonywanie zapytań na danych za pomocą operacji potoku.

Obsługa w czasie rzeczywistym i offline

Aby korzystać z funkcji czasu rzeczywistego i trybu offline, deweloperzy mogą używać podstawowych operacji Firestore w Firestore Enterprise.

Integracja klienta i narzędzi

Wersja Enterprise zawiera specjalne funkcje do interakcji z zapytaniami potoku i zarządzania nimi:

  • Wyjaśnianie i profilowanie zapytań: możesz użyć wyników wyjaśniania zapytań, aby dowiedzieć się, ile jednostek odczytu lub zapisu zużywa zapytanie, i przeanalizować jego wykonanie.
  • Statystyki zapytań: wersja Enterprise obsługuje statystyki zapytań, które pomagają określić, gdzie można utworzyć indeksy, aby zwiększyć wydajność i obniżyć koszty. Statystyki zapytań zapewniają wgląd w najpopularniejsze zapytania uruchamiane w bazie danych i ich charakterystykę wydajności.
  • Nowe typy indeksów: w wersji Enterprise możesz tworzyć specjalistyczne indeksy, w tym indeksy rozproszone, nierozproszone i unikalne. Obsługuje też tworzenie i edytowanie indeksów wyszukiwania wektorowego w bazach danych Enterprise.

Różnice między Firestore Standard a Firestore Enterprise

Główna różnica operacyjna między operacjami podstawowymi a operacjami potoku polega na zarządzaniu indeksowaniem, co bezpośrednio wpływa na wydajność i koszty.

Wersja Standard – podstawowe operacje Wersja Enterprise – operacje podstawowe i operacje na potokach
Wymagania dotyczące indeksowania Indeksy są wymagane w przypadku zapytań.

Indeksy dla poszczególnych pól są tworzone automatycznie, natomiast bardziej złożone zapytania opierają się na indeksach złożonych lub indeksach grup kolekcji, które należy skonfigurować ręcznie.

Indeksy nie są wymagane, więc są opcjonalne w przypadku zapytań.

Indeksy definiujesz w miarę potrzeb. Wersja Enterprise obsługuje też szerszy zakres typów indeksów, w tym indeksy nierozproszone/rozproszone i unikalne.

Indeksowane pola Jeśli nie ma jeszcze dodatkowego pola __name__, jest ono automatycznie dołączane do indeksowanych pól. __name__ nie jest automatycznie dołączany do indeksowanych pól. Jeśli jest to ważne dla Twojej aplikacji, musisz wyraźnie określić __name__ w indeksowanych polach.
Normalizacja kolejności sortowania Klauzula order by zapytania jest normalizowana przez dołączenie na końcu pól nierówności i pola __name__ (jeśli jeszcze nie występują). Gwarantuje to unikalne, deterministyczne uporządkowanie wyników niezależnie od tego, jakie inne pola znajdują się w klauzuli order by. Brak normalizacji kolejności sortowania. Kolejność sortowania, np. sort a ASC, gwarantuje tylko, że wyniki są sortowane według pola a. Cloud Firestore będzie używać istniejących indeksów, aby zwracać wyniki w najbardziej efektywnej kolejności. Dlatego jeśli a nie jest unikalne w zbiorze wyników, kolejność wyników może się różnić w zależności od konfiguracji indeksu, strategii wykonywania itp. Aby zagwarantować unikalną, deterministyczną kolejność wyników, musisz dodać do kolejności sortowania unikalne pole, takie jak __name__.
Wyniki Zapytania indeksowane: wydajność i koszty skalują się wraz z rozmiarem zbioru wyników.

Zapytania nieindeksowane: wydajność i koszty skalują się wraz z rozmiarem zbioru danych.

Zapytania indeksowane: wydajność i koszty skalują się wraz z rozmiarem zbioru wyników.

Zalecamy korzystanie z narzędzi Wyjaśnienie zapytania i Statystyki zapytań, aby tworzyć indeksy oraz zwiększać wydajność i obniżać koszty zapytań.

Wpływ na koszty przechowywania Indeksy automatyczne i złożone powodują dodatkowe obciążenie pamięci. Oszczędzasz na kosztach miejsca na dane, ponieważ indeksy nie są tworzone automatycznie dla każdego pola.
Baza kosztu Opłata jest naliczana za każdą operację odczytu, zapisu i usunięcia dokumentu. Opłaty są naliczane za jednostkę odczytu (transze 4 KB) i jednostkę zapisu (transze 1 KB). Zapisywanie wpisów indeksu zużywa jednostki zapisu.

Dowiedz się więcej o nowych cenach na podstawie kilku przykładów.

Reguły zabezpieczeń Reguły zabezpieczeń chronią kolekcje, weryfikując uprawnienia do odczytu i zapisu. Reguły zabezpieczeń chronią kolekcje, weryfikując uprawnienia do odczytu i zapisu. Dowiedz się, jak modelować dane, aby obsługiwać zapytania dotyczące potoku, w przewodniku Model danych.