Skuteczność Firebase Realtime Databasew aplikacji można poprawić na kilka sposobów. Aby dowiedzieć się, jak zoptymalizować skuteczność Realtime Database, gromadzić dane za pomocą różnych narzędzi do monitorowania Realtime Database, a następnie odpowiednio modyfikować aplikację lub Realtime Database.
Sprawdzanie skuteczności Realtime Database
Dane o skuteczności Realtime Database możesz zbierać za pomocą kilku różnych narzędzi, w zależności od potrzebnego poziomu szczegółowości:
- Przegląd ogólny: użyj narzędzia do profilowania, aby wyświetlić listę niezaindeksowanych zapytań i przegląd operacji odczytu/zapisu w czasie rzeczywistym.
- Szacowany obciążony czas użytkowania: aby wyświetlić obciążony czas użytkowania i ogólne dane o skuteczności, skorzystaj z danych o użytkowaniu dostępnych w Firebase konsoli.
- Szczegółowy podgląd: kliknij Cloud Monitoring, aby uzyskać bardziej szczegółowy wgląd w to, jak baza danych radzi sobie w ciągu czasu.
Zwiększanie wydajności na podstawie danych
Po zebraniu danych zapoznaj się z podanymi niżej sprawdzonymi metodami i strategiami, które pomogą Ci poprawić skuteczność w określonej dziedzinie.
Omówienie strategii poprawiania skuteczności | ||
---|---|---|
Dane | Opis | Sprawdzone metody |
Obciążenie/wykorzystanie | Zoptymalizuj wykorzystanie pojemności bazy danych na potrzeby przetwarzania żądań w danym momencie (co jest widoczne w metrykach **Load** lub **io/database_load**). |
Zoptymalizuj strukturę danych Podziel dane na wiele baz danych Zwiększ wydajność odbiorców Ogranicz liczbę pobrań za pomocą reguł opartych na zapytaniach Optymalizuj połączenia |
Aktywne połączenia | Zrównoważyć liczbę jednoczesnych aktywnych połączeń z bazą danych, aby nie przekroczyć limitu 200 tys. połączeń. |
Dzielenie danych na kilka baz danych Zmniejsz liczbę nowych połączeń |
Przepustowość wychodząca | Jeśli pobieranie z Twojej bazy danych wydaje się być wyższe niż powinno, możesz zwiększyć wydajność operacji odczytu i zmniejszyć obciążenie związane z szyfrowaniem. |
Optymalizowanie połączeń Optymalizowanie struktury danych Ograniczanie pobierania za pomocą reguł opartych na zapytaniach Ponowne używanie sesji SSL Zwiększanie efektywności odbiorcy Ograniczanie dostępu do danych |
Pamięć | Upewnij się, że nie przechowujesz nieużywanych danych, lub zrównowaważ przechowywane dane w innych bazach danych lub usługach Firebase, aby nie przekraczać limitu. |
Czyszczenie nieużywanych danych Optymalizacja struktury danych Dzielenie danych na wiele baz danych Użycie Cloud Storage for Firebase |
Optymalizacja połączeń
Wciąż wymagają połączenia, nawet jeśli jest ono krótkotrwałe.GET
PUT
Te częste, krótkotrwałe połączenia mogą w istocie znacznie zwiększyć koszty połączenia, obciążenie bazy danych i przepustowość wychodzącą w porównaniu z aktywnymi połączeniami z bazą danych w czasie rzeczywistym.
W miarę możliwości używaj natywnych pakietów SDK na platformę aplikacji zamiast interfejsu REST API. Pakiety SDK utrzymują otwarte połączenia, co zmniejsza koszty szyfrowania SSL i obciążenie bazy danych, które może się kumulować w przypadku interfejsu API REST.
Jeśli używasz interfejsu API REST, rozważ użycie protokołu HTTP keep-alive, aby utrzymać połączenie otwarte, lub zdarzeń wysyłanych przez serwer, które może zmniejszyć koszty związane z protokołem SSL.
dzielić dane na fragmenty w wielu bazach danych,
Dzielenie danych na wiele instancji Realtime Database, czyli dzielenie bazy danych na fragmenty, przynosi 3 korzyści:
- Zwiększ łączną liczbę jednoczesnych aktywnych połączeń dozwolonych w aplikacji, dzieląc je na instancje bazy danych.
- równoważyć obciążenie w przypadku instancji baz danych;
- Jeśli masz niezależne grupy użytkowników, które potrzebują dostępu tylko do oddzielnych zbiorów danych, użyj różnych instancji bazy danych, aby zwiększyć przepustowość i zmniejszyć opóźnienie.
Jeśli korzystasz z abonamentu Blaze, możesz utworzyć wiele instancji bazy danych w tym samym projekcie Firebase, korzystając z powszechnej metody uwierzytelniania użytkowników w przypadku wszystkich instancji bazy danych.
Dowiedz się więcej o tym, jak i kiedy dzielić dane.
Tworzenie wydajnych struktur danych
Funkcja Realtime Database pobiera dane z węzłów podrzędnych ścieżki, a także z samej ścieżki, dlatego warto zadbać o to, aby struktura danych była jak najbardziej płaska. Dzięki temu możesz selektywnie pobierać potrzebne dane, nie pobierając niepotrzebnych danych na klientów.
Zwróć szczególną uwagę na zapisywanie i usuwanie danych podczas strukturyzowania danych. Na przykład ścieżki z tysiącami elementów mogą być kosztowne do usunięcia. Dzielenie ich na ścieżki z wieloma poddrzewami i mniejszą liczbą liści na węzeł może przyspieszyć usuwanie.
Dodatkowo każdy zapis może zajmować 0, 1% łącznego wykorzystania bazy danych.
Uporządkuj dane w taki sposób, aby umożliwić zapis zbiorczy w ramach pojedynczej operacji jako aktualizacje wielościeżkowe za pomocą metod update()
w SDK lub RESTful PATCH
.
Aby zoptymalizować strukturę danych i zwiększyć wydajność, stosuj sprawdzone metody dotyczące struktur danych.
Zapobieganie nieautoryzowanemu dostępowi
Zapobiegaj nieautoryzowanym operacjom w bazie danych za pomocą Realtime Database Security Rules. Dzięki regułom możesz np. uniknąć sytuacji, w której złośliwy użytkownik wielokrotnie pobiera całą Twoją bazę danych.
Dowiedz się więcej o korzystaniu z reguł Bazy danych czasu rzeczywistego Firebase.
Ograniczanie pobierania za pomocą reguł opartych na zapytaniach
Realtime Database Security Rules ograniczają dostęp do danych w bazie danych, ale mogą też służyć do ograniczania danych zwracanych przez operacje odczytu. Gdy używasz reguł opartych na zapytaniach, zdefiniowanych za pomocą wyrażeń query.
, takich jak query.limitToFirst
, zapytania zwracają tylko dane określone przez regułę.
Na przykład ta reguła ogranicza dostęp do odczytu tylko do pierwszych 1000 wyników zapytania, uporządkowanych według priorytetu:
messages: {
".read": "query.orderByKey &&
query.limitToFirst <= 1000"
}
// Example query:
db.ref("messages").limitToFirst(1000)
.orderByKey("value")
Dowiedz się więcej o Realtime Database Security Rules.
Zapytania indeksowania
Indeksowanie danych zmniejsza łączną przepustowość, której używasz do każdego zapytania w aplikacji.
Ponowne używanie sesji SSL
Zmniejsz koszty związane z szyfrowaniem SSL w przypadku wznowionych połączeń, wydając bilety sesji TLS. Jest to szczególnie przydatne, jeśli potrzebujesz częstych, bezpiecznych połączeń z bazą danych.
Zwiększanie skuteczności słuchaczy
Umieszczaj odbiorców jak najdalej na ścieżce, aby ograniczyć ilość danych, które są synchronizowane. Słuchacze powinni znajdować się w pobliżu danych, które chcesz im udostępnić. Nie nasłuchuj w katalogu głównym bazy danych, ponieważ spowoduje to pobieranie całej bazy danych.
Dodaj zapytania, aby ograniczyć dane zwracane przez operacje nasłuchiwania, i użyj odbiorców, którzy pobierają tylko aktualizacje danych, np. on()
zamiast once()
. Zarezerwuj .once()
na działania, które naprawdę nie wymagają aktualizacji danych.
Aby uzyskać najlepszą wydajność, sortuj zapytania za pomocą funkcji orderByKey()
, o ile to możliwe. Sortowanie za pomocą funkcji orderByChild()
może być 6–8 razy wolniejsze, a sortowanie za pomocą funkcji orderByValue()
może być bardzo powolne w przypadku dużych zbiorów danych, ponieważ wymaga odczytu całej lokalizacji z poziomu warstwy trwałości.
Pamiętaj też, aby dodawać słuchaczy dynamicznie i usuwać ich, gdy nie są już potrzebni.
Czyszczenie nieużywanych danych
okresowo usuwaj z bazy danych nieużywane lub zduplikowane dane; Możesz tworzyć kopie zapasowe, aby ręcznie sprawdzić dane, lub okresowo tworzyć ich kopie zapasowe w worku Google Cloud Storage. Zastanów się też nad hostowaniem przechowywanych danych za pomocą Cloud Storage for Firebase.
Przesyłanie skalowanego kodu, który można aktualizować
Aplikacje wbudowane w urządzenia IoT powinny zawierać skalowalny kod, który można łatwo aktualizować. Dokładnie przetestuj przypadki użycia, uwzględniając scenariusze, w których baza użytkowników może gwałtownie rosnąć, oraz uwzględnij możliwość wdrażania aktualizacji kodu. Uważnie przemyśl, jakie poważne zmiany możesz wprowadzić w przyszłości, jeśli na przykład zdecydujesz się na podział danych.