W aplikacji możesz używać zarówno Firebase Realtime Database, jak i Cloud Firestore, a także korzystać z zalet obu tych rozwiązań bazy danych, aby dostosować je do swoich potrzeb. Możesz na przykład skorzystać z obsługi funkcji obecności w Realtime Database, o której mowa w artykule Tworzenie obecności w Cloud Firestore.
Dowiedz się więcej o różnicach między bazami danych.
Przenoszę dane na: Cloud Firestore
Jeśli chcesz przenieść niektóre dane z usługi Realtime Database do usługi Cloud Firestore, rozważ wykonanie opisanego poniżej. Każda baza danych ma unikalne potrzeby i rozważania strukturalne, dlatego nie ma automatycznej ścieżki migracji. Zamiast tego możesz wykonać te czynności:
Zmapuj strukturę danych i reguły zabezpieczeń z poziomu Realtime Database na Cloud Firestore. Zarówno Realtime Database, jak i Cloud Firestore korzystają z usługi uwierzytelniania Firebase, więc nie musisz zmieniać uwierzytelniania użytkowników w aplikacji. Jednak reguły zabezpieczeń i model danych są inne, dlatego przed rozpoczęciem przenoszenia danych do Cloud Firehose należy dokładnie wziąć pod uwagę te różnice.
Przenoszenie danych historycznych. Podczas konfigurowania nowej struktury danych w Cloud Firestore możesz mapować i przenosić istniejące dane z instancji Realtime Database do nowej instancji Cloud Firestore. Jeśli jednak w aplikacji używasz obu baz danych, nie musisz przenosić danych historycznych z Realtime Database.
Odzwierciedlać nowe dane w Firestore w czasie rzeczywistym. Użyj funkcji Cloud Functions, aby zapisywać nowe dane w nowej bazie danych Cloud Firestore, gdy są one dodawane do bazy Realtime Database.
Ustaw bazę danych Cloud Firestore jako bazę danych docelową przenoszonych danych. Po przeniesieniu części danych użyj bazy danych Cloud Firestore jako bazy danych podstawowej i zmniejsz użycie bazy danych Realtime Database na potrzeby przeniesionych danych. Zastanów się nad wersjami swojej aplikacji, które nadal są powiązane z usługą Realtime Database, i o tym, jak zamierzasz dalej je obsługiwać.
Uwzględnij koszty płatności za Realtime Database i Cloud Firestore.
Mapowanie danych
Dane w Realtime Database są uporządkowane w jednym drzewie, natomiast Cloud Firestore obsługuje bardziej wyraźne hierarchie danych za pomocą dokumentów, kolekcji i podkolekcji. Jeśli przenosisz część danych z Realtime Database na Cloud Firestore, możesz rozważyć zastosowanie innej architektury danych.
Najważniejsze różnice, które należy wziąć pod uwagę
Jeśli przenosisz dane z dotychczasowego drzewa Realtime Database do dokumentów i kolekcji Cloud Firestore, pamiętaj o tych głównych różnicach między bazami danych, które mogą mieć wpływ na sposób strukturowania danych w Cloud Firestore:
- Zapytania płytkie zapewniają większą elastyczność w hierarchicznych strukturach danych.
- Złożone zapytania zapewniają większą szczegółowość i zmniejszają potrzebę powielania danych.
- Kursory zapytań zapewniają bardziej niezawodną stronę po stronie.
- Transakcje nie wymagają już wspólnego pierwiastka dla wszystkich danych i są skuteczniejsze.
- Koszty rozliczeń różnią się w przypadku Realtime Database i Cloud Firestore. W wielu przypadkach Cloud Firestore może być droższa niż Realtime Database, szczególnie jeśli korzystasz z wielu małych operacji. Rozważ zmniejszenie liczby operacji w bazie danych i uniknięcie niepotrzebnych zapisów. Dowiedz się więcej o różnicach w płatnościach między Realtime Database a Cloud Firestore.
Sprawdzone metody w akcji
Poniższy przykład odzwierciedla niektóre kwestie, które należy wziąć pod uwagę podczas przenoszenia danych między bazami danych. Możesz korzystać z czytania płytkiego i ulepszonych funkcji zapytań, aby uzyskiwać bardziej naturalne struktury danych niż w przypadku Realtime Database.
Weź pod uwagę aplikację z przewodnikami po miastach, która pomaga użytkownikom znajdować znane zabytki w miastach na całym świecie. Ponieważ Realtime Database nie obsługuje lektury płytkiej, być może trzeba było ustrukturyzować dane w 2 węzłach najwyższego poziomu w ten sposób:
// /cities/$CITY_KEY
{
name: "New York",
population: 8000000,
capital: False
}
// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
name: "Empire State Building",
category: "Architecture"
}
Cloud Firestore ma płytkie odczyty, więc zapytanie o dokumenty w kolekcji nie pobiera danych z podkolekcji. W związku z tym informacje o miejscach docelowych możesz przechowywać w podzbiorze:
// /cities/$CITY_ID
{
name: "New York",
population: 8000000,
capital: False,
landmarks: [... subcollection ...]
}
Maksymalny rozmiar dokumentu to 1 MB, co jest kolejnym powodem, dla którego punkty orientacyjne należy przechowywać jako podkolekcją. Dzięki temu każdy dokument miasta będzie miał niewielki rozmiar, a nie będzie trzeba dzielić dokumentów za pomocą zagnieżdżonych list.
Zaawansowane możliwości wykonywania zapytań w usłudze Cloud Firestore eliminują potrzebę dublowania danych w przypadku typowych wzorców dostępu. Wyobraź sobie na przykład ekran w aplikacji zwiedzanie miasta, na którym wyświetlane są wszystkie stolice uporządkowane według liczby ludności.
W systemie Realtime Database najskuteczniejszym sposobem osiągnięcia tego celu jest utworzenie osobnej listy stolic, która duplikuje dane z listy cities
w taki sposób:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
W narzędziu Cloud Firestore możesz wysłać w ramach jednego zapytania listę stolic o kolejności ludności:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
Dowiedz się więcej o modelu danych Cloud Firestore i zapoznaj się z naszymi rozwiązaniami, aby dowiedzieć się więcej o tworzeniu struktury bazy danych Cloud Firestore.
Zabezpieczanie danych
Niezależnie od tego, czy używasz Cloud Firestore Security Rules na Androida, klienta Chrome czy aplikacji internetowych, albo do obsługi serwerów Identity Access Management (IAM), pamiętaj o zabezpieczeniu swoich danych zarówno w usługach Cloud Firestore, jak i Realtime Database. Uwierzytelnianie użytkowników jest obsługiwane przez uwierzytelnianie w obu bazach danych, więc nie musisz zmieniać implementacji uwierzytelniania, gdy zaczniesz używać usługi Cloud Firestore.
Najważniejsze różnice, które należy wziąć pod uwagę
- Pakiety SDK na urządzenia mobilne i do przeglądarek korzystają z funkcji Cloud Firestore Security Rules, a pakiety SDK na serwery używają usługi zarządzania tożsamościami i dostępem (IAM) do ochrony danych.
- Cloud Firestore Security Rules nie są kaskadowe, chyba że użyjesz symbolu wieloznacznego. Dokumenty i kolekcje nie dziedziczą reguł w inny sposób.
- Nie musisz już sprawdzać danych osobno (jak w Realtime Database).
- Cloud Firestore przed wykonaniem zapytania sprawdza reguły, aby upewnić się, że użytkownik ma odpowiedni dostęp do wszystkich danych zwróconych przez zapytanie.
Przenieś dane historyczne do usługi Cloud Firestore
Po zmapowaniu struktur danych i zabezpieczeń na modele danych i zabezpieczeń Cloud Firestore możesz zacząć dodawać dane. Jeśli planujesz wysyłać zapytania o dane historyczne po przeniesieniu aplikacji z Realtime Database do Cloud Firestore, dodaj do nowej bazy danych Cloud Firestore wyeksportowane stare dane. Jeśli planujesz użyć w aplikacji zarówno elementu Realtime Database, jak i elementu Cloud Firestore, możesz pominąć ten krok.
Aby uniknąć zastąpienia nowych danych starymi, najpierw dodaj dane historyczne. Jeśli nowe dane dodajesz jednocześnie do obu baz danych, jak opisano w następnym kroku, pamiętaj, aby nadać pierwszeństwo nowym danym dodanym do tabeli Cloud Firestore przez funkcję Cloud Functions.
Aby przenieść dane historyczne do Cloud Firestore, wykonaj te czynności:
- Wyeksportuj dane z Realtime Database lub użyj ostatniej kopii zapasowej.
- W konsoli Firebase otwórz sekcję Realtime Database.
- Na karcie Dane wybierz węzeł poziomu katalogu bazy danych, a potem w menu kliknij Eksportuj JSON.
Utwórz nową bazę danych w Cloud Firestore i dodaj do niej dane.
Podczas przenoszenia niektórych danych do Cloud Firestore rozważ zastosowanie tych strategii:
- Napisać niestandardowy skrypt, który przeniesie Twoje dane za Ciebie. Nie możemy zaoferować szablonu dla tego skryptu, ponieważ każda baza danych ma własne potrzeby. Cloud Firestore Eksperci na kanale Slack lub na Stack Overflow mogą przejrzeć Twój skrypt lub udzielić wskazówek.
- Użyj pakietów SDK serwera (Node.js, Java, Python lub Go), aby zapisywać dane bezpośrednio w Cloud Firestore. Instrukcje konfigurowania pakietów SDK serwera znajdziesz w artykule Pierwsze kroki.
- Aby przyspieszyć migracje dużych ilości danych, używaj zapisów zbiorczych i wysyłaj do 500 operacji w jednym żądaniu sieciowym.
- Aby nie przekraczać Cloud Firestore limitów szybkości, ogranicz operacje do 500 operacji zapisu na sekundę w przypadku każdej kolekcji.
Dodaj nowe dane do: Cloud Firestore
Aby zachować zgodność między bazami danych, dodawaj nowe dane do obu baz w czasie rzeczywistym. Użyj Cloud Functions, aby wywołać zapis do Cloud Firestore coraz, gdy klient zapisuje do Realtime Database. Upewnij się, że Cloud Firestore przypisuje pierwszeństwo nowym danym pochodzącym z Cloud Functions nad zapisami, które wykonujesz podczas migracji danych historycznych.
Utwórz funkcję, która zapisuje nowe dane lub dane zmienione w tablicy Cloud Firestore za każdym razem, gdy klient zapisuje dane w tablicy Realtime Database. Dowiedz się więcej o Realtime Database w Cloud Functions.
Ustaw bazę danych Cloud Firestore jako bazę danych docelową dla przenoszonych danych.
Jeśli zdecydujesz się użyć bazy danych Cloud Firestore jako głównej bazy danych dla niektórych danych, uwzględnij wszystkie skonfigurowane funkcje lustrzanego odbicia danych i sprawdź bazę danych Cloud Firestore Security Rules.
Jeśli używasz metody Cloud Functions do zachowania spójności między bazami danych, sprawdź, czy nie duplikujesz w pętli operacji zapisu w obu bazach danych. Przełącz funkcję na zapisywanie w pojedynczej bazie danych lub całkowicie ją usuń i zacznij wycofywać funkcję zapisu przeniesionych danych w aplikacjach nadal powiązanych z Realtime Database. Sposób, w jaki to zrobisz w przypadku swojej aplikacji, zależy od Twoich konkretnych potrzeb i użytkowników.
Sprawdź, czy dane są odpowiednio zabezpieczone. Sprawdź konfigurację Cloud Firestore Security Rules lub uprawnień.