W tym dokumencie znajdziesz wskazówki dotyczące skalowania aplikacji bezserwerowych ponad tysiące operacji na sekundę lub setek tysięcy w tym samym czasie. Ten dokument zawiera zaawansowane tematy pomocne aby dokładnie zrozumieć system. Jeśli dopiero zaczynasz przygodę z Cloud Firestore – zamiast tego zobacz krótki przewodnik.
Cloud Firestore oraz pakiety SDK Firebase na komórki i strony internetowe zapewniają zaawansowany model do tworzenia bezserwerowych aplikacji, w których kod po stronie klienta uzyskuje w bazie danych. Pakiety SDK umożliwiają klientom nasłuchiwanie aktualizacji danych w czasie rzeczywistym. Ty mogą używać aktualizacji w czasie rzeczywistym do tworzenia elastycznych aplikacji, które nie wymagają serwera i infrastrukturze. O ile to bardzo łatwe, co pozwoli Ci zrozumieć ograniczenia w systemach tworzących Cloud Firestore aby bezserwerowa aplikacja była skalowana i działała dobrze w miarę wzrostu natężenia ruchu.
W poniższych sekcjach znajdziesz porady dotyczące skalowania aplikacji.
Wybierz lokalizację bazy danych blisko użytkowników
Poniższy diagram przedstawia architekturę aplikacji działającej w czasie rzeczywistym:
Gdy aplikacja uruchomiona na urządzeniu użytkownika (w przeglądarce lub na urządzeniu mobilnym) tworzy połączenie
połączenia z Cloud Firestore, jest ono kierowane do
Serwer frontendu Cloud Firestore
region, w którym znajduje się baza danych. Przykład:
jeśli baza danych znajduje się w regionie us-east1, połączenie będzie również kierowane do
Frontend Cloud Firestore także w: us-east1. Te połączenia są
długoterminowe i otwarte, dopóki ich nie zamkniesz przez aplikację.
frontend odczytuje dane z bazowych systemów pamięci Cloud Firestore.
Odległość między fizyczną lokalizacją użytkownika a Cloud Firestore lokalizacja bazy danych wpływa na opóźnienie użytkownika. Na przykład plik użytkownik w Indiach, którego aplikacja łączy się z bazą danych w regionie Google Cloud w Ameryce Północnej. działanie aplikacji może być wolniejsze, a aplikacja mniej płynna niż w przypadku które znajdowały się bliżej, np. w Indiach lub w innej części Azji.
Projektowanie z myślą o niezawodności
Te tematy zwiększają niezawodność aplikacji lub wpływają na nią:
Włącz tryb offline
Pakiety SDK Firebase zapewniają trwałość danych offline. Jeśli aplikacja na urządzeniu użytkownika nie może połączyć się z Cloud Firestore, można nadal z niej korzystać, korzystając z danych w lokalnej pamięci podręcznej. Dzięki temu dane nawet w sytuacji, gdy połączenie z internetem jest niestabilne, możesz całkowicie utracić dostęp na kilka godzin lub dni. Więcej informacji: w trybie offline – przeczytaj artykuł Włączanie danych offline.
Informacje o automatycznych ponownych próbach
Pakiety SDK Firebase zajmują się ponawianiem operacji i przywracaniem zerwane połączenia. Pomaga to obejść przejściowe błędy spowodowane przez ponowne uruchomienie serwerów lub problemy z siecią między klientem a w bazie danych.
Wybieranie lokalizacji w wielu regionach lub w wielu regionach
Wybierając między regionem a kierowaniem, należy pamiętać o kilku kompromisach. znajdujących się w wielu regionach. Główna różnica dotyczy sposobu replikacji danych. Ten zwiększa gwarancję dostępności aplikacji. Instancja z wieloma regionami zapewnia większą niezawodność wyświetlania i trwałość danych, ale kompromis to koszty.
Omówienie systemu zapytań w czasie rzeczywistym
Zapytania w czasie rzeczywistym (nazywane też detektorami zrzutów) pozwalają aplikacji nasłuchiwać zmian w bazie danych i otrzymywać powiadomienia o krótkim czasie oczekiwania, gdy dane zmian. Aplikacja może uzyskać ten sam wynik, okresowo odpytując bazę danych pod kątem ale często jest to wolniejsze, droższe i wymaga więcej kodu. Dla: jak konfigurować i używać zapytań w czasie rzeczywistym: Aktualizacje w czasie rzeczywistym W poniższych sekcjach szczegółowo opisać działanie detektorów zrzutów i opisać niektóre ze sprawdzonymi metodami skalowania zapytań w czasie rzeczywistym przy zachowaniu wydajności.
Wyobraź sobie 2 użytkowników, którzy łączą się z Cloud Firestore za pomocą wiadomości za pomocą jednego z mobilnych pakietów SDK.
Klient A zapisuje w bazie danych, aby dodawać i aktualizować dokumenty w kolekcji
pod tytułem chatroom:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
Klient B nasłuchuje aktualizacji w tej samej kolekcji za pomocą detektora zrzutów. Klient B otrzymuje natychmiastowe powiadomienie za każdym razem, gdy ktoś utworzy nową wiadomość. Poniższy diagram przedstawia architekturę detektora zrzutów:
Poniższa sekwencja zdarzeń ma miejsce, gdy Klient B połączy zrzut dysku detektor bazy danych:
- Klient B otwiera połączenie z Cloud Firestore i rejestruje
słuchacza, nawiązując połączenie z numerem
onSnapshot(collection("chatroom"))do pakiet SDK Firebase. Ten odbiornik może być aktywny przez wiele godzin. - Frontend Cloud Firestore wysyła zapytania do bazowego systemu pamięci masowej aby wczytać zbiór danych. Wczytuje on cały zbiór wyników dokumenty. Nazywamy to zapytaniem ankietowym. System oceniane jest w ramach Reguły zabezpieczeń Firebase do sprawdź, czy użytkownik ma dostęp do tych danych. Jeśli użytkownik jest autoryzowany, zwraca dane użytkownikowi.
- Zapytanie Klienta B przechodzi do trybu nasłuchiwania. Rejestrator się rejestruje z modułem obsługi subskrypcji i czeka na aktualizacje danych.
- Klient A wysyła teraz operację zapisu, aby zmodyfikować dokument.
- Baza danych zatwierdza zmianę w dokumencie systemu pamięci masowej.
- Transakcyjnie system zatwierdza tę samą aktualizację dla wewnętrznego dziennik zmian. Dziennik zmian określa rygorystyczną kolejność zmian, i tak się dzieje.
- Historia zmian powoduje, że zaktualizowane dane trafiają do puli subskrypcji. modułów obsługi.
- Uruchomi się mechanizm dopasowania odwrotnego zapytania, by sprawdzić, czy zaktualizowany dokument pasuje obecnie zarejestrowanych detektorów zrzutu. W tym przykładzie dokument pasuje do detektora zrzutów klienta B. Jak sama nazwa wskazuje, funkcję dopasowywania odwrotnego zapytania, jak w przypadku normalnego zapytania do bazy danych, ale wykonywane w odwrotnej kolejności. Zamiast przeszukiwać dokumenty w poszukiwaniu tych, które pasują do zapytania, usługa ta sprawnie przeszukuje w celu znalezienia tych, które pasują do dokumentu przychodzącego. Po znalezieniu dopasowania system przekaże odpowiedni dokument detektorom zrzutu. Następnie system ocenia reguły zabezpieczeń Firebase tej bazy danych. , aby mieć pewność, że tylko autoryzowani użytkownicy otrzymają dane.
- system przekaże aktualizację dokumentu do pakietu SDK na urządzeniu klienta B oraz
uruchomi się wywołanie zwrotne
onSnapshot. Jeśli włączona jest trwała lokalna, pakiet SDK spowoduje zastosowanie aktualizacji również do lokalnej pamięci podręcznej.
Kluczowa część skalowalności Cloud Firestore zależy od rozpowszechnienia do modułów obsługi subskrypcji i serwerów frontendu. pozwala na skuteczne rozpowszechnienie pojedynczej zmiany danych w milionach zapytań w czasie rzeczywistym i połączenia z użytkownikami. Przez uruchomienie wielu replik wszystkich tych komponenty w wielu strefach (lub wielu regionach w przypadku wielu regionów, wdrożenia), Cloud Firestore uzyskuje wysoką dostępność i skalowalność.
Warto zauważyć, że wszystkie operacje odczytu wykonywane z mobilnych i internetowych pakietów SDK z użyciem powyższego modelu. Wykonują zapytanie odpytywania, a potem tryb nasłuchiwania w celu zachowania gwarancji spójności. Dotyczy to również słuchaczy słuchaczy w czasie rzeczywistym, wywołania pobierania dokumentu oraz zapytania jednorazowe. Są to na przykład singielki, pobierania dokumentów i zapytań jednorazowych w postaci detektorów krótkotrwałych zrzutów, z podobnymi ograniczeniami w zakresie wydajności.
Stosowanie sprawdzonych metod skalowania zapytań w czasie rzeczywistym
Zastosuj poniższe sprawdzone metody, aby projektować skalowalne zapytania w czasie rzeczywistym.
Informacje o dużym ruchu zapisu w systemie
Ta sekcja pomaga zrozumieć, jak system reaguje na rosnący liczby żądań zapisu.
logi zmian Cloud Firestore, które generują zapytania w czasie rzeczywistym. automatycznie skalują się w poziomie w miarę wzrostu natężenia ruchu związanego z zapisem. Jako że szybkość zapisu dla bazy danych rośnie ponad możliwa do obsłużenia pojedynczy serwer, jest dzielone między wiele serwerów, a przetwarzanie zapytań rozpoczyna się wykorzystują dane z kilku modułów obsługi subskrypcji, a nie z jednego. Z poziomu z perspektywy klienta i pakietu SDK, że wszystko jest przejrzyste i nie trzeba podejmować żadnych działań. z aplikacji, gdy następuje podział. Poniższy diagram pokazuje, skala zapytań w czasie rzeczywistym:
Automatyczne skalowanie pozwala zwiększyć ruch zapisu bez ograniczeń, ale gdy natężenie ruchu się zwiększy, reakcja systemu może trochę potrwać. Postępuj zgodnie z zaleceniami dotyczącymi reguły 5–5–5, aby uniknąć tworzenia obszaru roboczego zapisu. Key Visualizer to przydatne narzędzie do analizowania obszarów interaktywnych zapisu.
Wiele aplikacji cechuje się przewidywalnym wzrostem organicznym, a Cloud Firestore bez stosowania środków ostrożności. Zadania wsadowe, takie jak importowanie dużych może jednak zbyt szybko przyspieszyć zapisy. Podczas projektowania aplikacji nie opuszczaj tego, skąd pochodzi ruch związany z zapisem.
Jak działają zapisy i odczyty
System zapytań w czasie rzeczywistym można traktować jak potok łączący zapis operacji na czytnikach. Po utworzeniu, zaktualizowaniu lub usunięciu dokumentu zmiana zostanie przeniesiona z systemu pamięci masowej do obecnie zarejestrowanego słuchaczom. Struktura historii zmian w Cloud Firestore gwarantuje silny efekt co oznacza, że aplikacja nie będzie nigdy otrzymywać aktualizacje, które są niezgodne z datą zatwierdzenia danych przez bazę danych zmian. Ułatwia to tworzenie aplikacji przez usunięcie przypadki skrajne związane ze spójnością danych.
Ten połączony potok oznacza, że operacja zapisu powodująca hotspoty lub rywalizacji o blokady mogą negatywnie wpływać na operacje odczytu. Gdy operacje zapisu nie powiodą się lub dochodzi do ograniczenia, odczyt może czekania na spójne dane z historii zmian. Jeśli stanie się to w aplikacji, możesz zauważyć zarówno powolne operacje zapisu, jak i skorelowane powolne odpowiedzi razy dla zapytań. Unikanie takich obszarów to klucz do uniknięcia .
Przechowuj dokumenty i zapisuj niewielkie operacje
Gdy tworzysz aplikacje z detektorami zrzutów, zwykle chcesz, aby użytkownicy o zmianach danych. Aby osiągnąć ten cel, staraj się unikać drobnych rzeczy. może przesyłać do systemu niewielkie dokumenty z dziesiątkami pól, szybko. Większe dokumenty z setkami pól i dużymi danymi wymagają więcej czasu do przetwarzania.
Podobnie faworyzuj krótkie i szybkie operacje zatwierdzania i zapisu, aby zminimalizować opóźnienie. Duże wsady mogą zapewnić większą przepustowość z punktu widzenia autora ale może wydłużyć czas powiadomienia detektorów zrzutów. Często jest to sprzeczne z intuicją w porównaniu z innymi systemami baz danych, możesz używać grupowania, aby zwiększyć wydajność.
Używaj wydajnych detektorów
Wraz ze wzrostem szybkości zapisu bazy danych Cloud Firestore dzieli przetwarzanie danych na kilka serwerów. Algorytm fragmentacji Cloud Firestore próbuje współlokować dane z tę samą kolekcję lub grupę kolekcji na tym samym serwerze historii zmian. system próbuje zmaksymalizować możliwą przepustowość zapisu, zachowując liczbę jak najmniej liczby serwerów zaangażowanych w przetwarzanie zapytania.
Pewne wzorce mogą jednak nadal prowadzić do nieoptymalnego działania funkcji migawki. słuchaczom. Jeśli na przykład aplikacja przechowuje większość danych w jednym może być konieczne nawiązanie połączenia z wieloma serwerami, potrzebnych danych. Dzieje się tak nawet po zastosowaniu filtra zapytania. Łączenie do wielu serwerów zwiększa ryzyko wolniejszych odpowiedzi.
Aby uniknąć tych wolniejszych odpowiedzi, zaprojektuj schemat i aplikację tak, aby system może obsługiwać detektory bez konieczności przechodzenia do wielu różnych serwerów. Może to zadziałać najlepiej jest podzielić dane na mniejsze zbiory o niższych szybkościach zapisu.
Przypomina to analizowanie zapytań dotyczących skuteczności w relacyjnej bazie danych, która wymaga pełnego skanowania tabel. W relacji bazy danych, zapytanie wymagające pełnego skanowania tabeli jest odpowiednikiem detektor zrzutów, który ogląda kolekcję o wysokim prawdopodobieństwie rezygnacji. Może działać wolniej niż zapytanie, które baza danych może udostępniać przy użyciu bardziej szczegółowego indeksu. Zapytanie o bardziej szczegółowym indeksie jest jak detektor zrzutów, który obserwuje do pojedynczego dokumentu lub kolekcji, które rzadziej się zmieniają. Należy wczytać przetestować aplikację, aby jak najlepiej zrozumieć zachowanie i potrzeby danego przypadku użycia.
Szybkie odpytywanie
Inną kluczową częścią elastycznych zapytań w czasie rzeczywistym jest zapewnienie, odpytywanie w celu wczytywania danych jest szybkie i wydajne. Przy pierwszym połączeniu z nowym detektorem zrzutu musi on wczytać cały zestaw wyników i wysyłanie go na urządzenie użytkownika. Powolne zapytania tworzą aplikację mniej elastycznie. Obejmuje to na przykład zapytania, które spróbuj odczytać wiele dokumentów lub zapytań, które nie korzystają z odpowiednich indeksów.
Słuchacz może też wrócić ze stanu słuchania do stanu sondowania w pewnych okolicznościach. Dzieje się to automatycznie i jest przejrzyste dla Pakiety SDK i aplikację. Te warunki mogą aktywować stan odpytywania:
- System równoważy historię zmian z powodu zmian obciążenia.
- Hotspoty powodują nieudane lub opóźnione zapisy w bazie danych.
- Tymczasowe ponowne uruchomienie serwera ma tymczasowo wpływ na detektory.
Jeśli zapytania odpytywania są wystarczająco szybkie, stan sondowania staje się przezroczysty użytkownikom aplikacji.
Wspieranie długoterminowych słuchaczy
Otwarcie słuchaczy i utrzymanie ich uwagi jest często oszczędny sposób na stworzenie aplikacji korzystającej z Cloud Firestore. W przypadku użycia funkcji Cloud Firestore, opłaty są naliczane za dokumenty zwracane do aplikacji a nie utrzymywania otwartego połączenia. Długotrwały odczyt detektora zrzutów tylko dane potrzebne do obsługi zapytania przez cały okres jego istnienia. Ten obejmuje początkową operację odpytywania, po której następują powiadomienia, gdy dane naprawdę się zmienia. Zapytania jednorazowe umożliwiają natomiast ponowne odczytanie danych, nie uległy zmianie od ostatniego wykonania zapytania przez aplikację.
W przypadkach, gdy aplikacja musi zużywać dużą ilość danych, detektory zrzutów może być nieodpowiedni. Jeśli na przykład Twój przypadek użycia generuje wiele dokumentów na sekundę przy wykorzystaniu połączenia przez dłuższy czas, lepiej wybrać zapytania jednorazowe z mniejszą częstotliwością.
Co dalej
- Dowiedz się, jak używać detektorów zrzutów.
- Przeczytaj więcej sprawdzonych metod.