W tym wpisie porównam bazy danych dostępne na platformę Firebase. Obecnie do dyspozycji mamy dwie bazy danych: Realtime Database oraz Cloud Firestore. We wcześniejszych wpisach tego cyklu przedstawiałem sposób w jaki możemy je wykorzystać:
Pierwsza z nich oferowana była od początku istnienia omawianej platformy. Cloud Firestore to nowa baza danych, która została opublikowana 31 stycznia 2019 roku.
Realtime Database (RTDB) jest wydajną bazą o niewielkim opóźnieniu, pozwalająca na synchronizowanie stanu w czasie rzeczywistym. Cloud Firestore (CF) to najnowsza baza danych czerpiąca z dobrodziejstw RTDB, dzięki czemu jest bardziej intuicyjna, a także posiada szybsze, wzbogacone zapytania.
Warto zaznaczyć, że zarówno RTDB oraz CF to NoSQL’owe bazy danych. W przypadku RTDB struktura to w rzeczywistości obiekt JSON. Dzięki temu można w łatwy sposób przechowywać proste dane np. dane numeryczne, znakowe, logiczne. Trudniejsze do zorganizowania są skomplikowane, hierarchiczne dane. CF przechowuje dane w postaci dokumentów, które swoją strukturą przypominają obiekty JSONowe. Baza ta pozwala na łatwiejsze przechowywanie hierarchicznych danych za pomocą kolekcji. Dane w Cloud Firestore podlegają mniejszemu spłaszczeniu w porównaniu do Realtime Database. Oznacza to, że CF umożliwia przechowywanie bardziej złożonych danych, np. czas zapisywany jest za pomocą klasy Timestamp wchodzącej w skład biblioteki Firestore.
Dostęp offline
Omawiane bazy umożliwiają przechowywanie danych offline. W przypadku RTDB tę opcję możemy wykorzystać jedynie w aplikacjach przeznaczonych na urządzenia mobilne: iOS oraz Android. CF daje nam dodatkową możliwość przechowywanie danych offline w aplikacjach webowych.
Aktywność
Baza danych RTDB informuje nas o tym czy dany użytkownik jest aktualnie obecny w aplikacji. Zapewnia także aktualizację za każdym razem, kiedy stan połączenia zostanie zmieniony. CF nie oferuje możliwości śledzenia stanu połączenia, jednakże istnieje możliwość synchronizacji stanu połączenia poprzez wykorzystanie RTDB.
Zapytania
Pobieranie, sortowanie oraz filtrowanie danych odbywa się za pomocą zapytań. W przypadku RTDB występują głębokie zapytania z ograniczoną funkcjonalnością sortowania i filtrowania. RTDB umożliwia tworzenie zapytań sortujących lub filtrujących, ale nigdy jednocześnie sortujących i filtrujących. Jak już wspomniałem wcześniej tworzone zapytania są głębokie, oznacza to, że w wyniku zwracane są wszystkie poddrzewa. Zapytania nie wymagają indeksów, jednak wydajność zapytań spada wraz ze wzrostem wielkości bazy danych. W CF tworzone są indeksowane zapytania, które mogą jednocześnie filtrować oraz sortować dane. W przypadku tej bazy, zapytania są płytkie, co oznacza, że zwracają pojedyncze dokumenty lub grupy dokumentów. Jednak nigdy nie zwracają kolekcji znajdujących się w dokumencie. Jak wspomniałem wcześniej, zapytania w CF są indeksowane, wydajność jest zależna od wielkości rezultatu, a nie wielkości całej bazy.
Zapisy i transakcje
W RTDB korzysta się z podstawowych operacji zapisu i transakcji. Zapis dokonywany jest za pomocą metod set i update. Transakcje są atomowe w określonym poddrzewie danych. Baza CF zapewnia zaawansowane operacje zapisu i odczytu danych. Posiada również zaawansowane transakcje, takie jak operatory tablicowe i numeryczne. Warto również dodać, że transakcje mogą atomowo odczytywać i zapisywać dane w dowolnej części bazy.
Niezawodność i wydajność
Realtime Database jest ograniczona do strefy dostępności w jednym regionie. Nie następuje automatyczne skalowanie. Dzięki temu osiąga się bardzo niskie opóźnienia. To idealna opcja dla aplikacji wymagających częstej synchronizacji stanu. CF to rozwiązanie wykorzystujące automatyczne skalowanie na wiele regionów. Dzięki temu rozwiązaniu zapewniona zostaje globalna skalowalność oraz niezawodność. Oznacza to, że dane przechowywane są w wielu miejscach.
Skalowalność
Baza danych RTDB w celu osiągnięcia skalowalności wymaga dzielenia na segmenty. Twórcy zalecają, aby dzielić bazę danych na wiele w przypadku, kiedy nawiązywanych jest ponad 200 000 jednoczesnych połączeń oraz wykonywanych 1 000 zapisów na sekundę. RTDB nie posiada lokalnych limitów zapisu. W CF skalowanie odbywa się automatycznie. Na chwilę obecną limit skalowania wynosi około 1 miliona jednoczesnych połączeń oraz 10 000 zapisów na sekundę. W planach jest zwiększenie tego limitu. W tej bazie występują ograniczenia szybkości zapisu do dokumentów lub indeksów.
Bezpieczeństwo
W RTDB do tworzenia reguł bezpieczeństwa wykorzystuje się kaskadowy język reguł. Język ten oddziela autoryzację od sprawdzania poprawności danych. Walidacja danych odbywa się za pomocą reguł sprawdzania poprawności. W przypadku CF do tworzenia zabezpieczeń danych wykorzystywane są reguły niekaskadowe. Reguły te łączą autoryzację i sprawdzanie poprawności danych, dzięki temu możemy odczytywać i zapisywać dane tylko w przypadku, gdy przesłane zapytanie jest autoryzowane i zawiera poprawne dane. Reguły mogą stać się kaskadowymi w przypadku użycia symbolu wieloznacznego („*”). Użytkownik, który nie ma dostępu do określonych przez reguły danych, otrzyma informacje o niepowodzeniu zapytania.
Płatności
Omawiane bazy danych są dostępne we wszystkich typach kont. W Realtime Database opłaty dotyczą tylko przepustowości i pamięci. W Cloud Firestore opłaty związane są głównie z operacjami wykonywanymi na bazie danych, np. odczyt, zapis, usuwanie.
Podsumowanie
Twórcy Firebase zalecają korzystać z CF w przypadku nowych projektów, ponieważ ta baza oferuję dodatkową funkcjonalność, wydajność i skalowalność. Jej infrastruktura jest zaprojektowana do obsługi bardziej zaawansowanych funkcji, które w przyszłości będą się pojawiały. Twórcy przewidują pojawienie się nowych typów zapytań, mniej zawodnych reguł bezpieczeństwa oraz ulepszeń wydajności.
Jeżeli podoba Ci się to co robię na blogu, wesprzyj mnie obserwując moje profile społecznościowe Fanpage, Twitter oraz Instagram. Dzięki temu nie ominie Cie żaden wpis.
robię portal z ogłoszeniami o prace. struktura danych wydaje się bardzo prosta. nie potrzebuję też wspierać offfline i skalować na cały świat. w zasadzie to nawet nie potrzebuję realtime ale nie chcę się bawić w backend. czy w takim przypadku lepsze nie będzie RTDB? CF to pewnie więcej hajsu dla google 🙂
Bardzo fajny wpis, widziałam ostatnio podobne artykuły i ten się wyróżnia na tle innych oraz jest wart uwagi. Konkretnie objaśniony temat. Bardzo przyjemnie się go czyta. Czekam na takich więcej 🙂