The Firestore JOIN Trap
Stajesz przed powszechnym problemem w Firestore. Twoja funkcja Firebase zgłasza błąd maksymalnego rozmiaru partii (maximum batch size error). Musisz połączyć zamówienia i klientów na potrzeby pulpitu nawigacyjnego. Zazwyczaj, aby to naprawić, duplikujesz dane. Jednak teraz Twoje dane są nieaktualne i niespójne.
Google ogłosiło Pipelines API, aby rozwiązać ten problem. Pozwala ono na operacje JOIN między kolekcjami bez duplikowania danych. Niektórzy programiści raportują szybki czas zapytań w małych testach.
Spędziłem tydzień, testując to API pod dużym obciążeniem. Oto czego nie mówi Ci dokumentacja.
Wysokie koszty Każde wykonanie potoku (pipeline) odczytuje dane ze wszystkich zaangażowanych kolekcji. JOIN między dwiema kolekcjami nalicza opłaty za odczyty w obu z nich. Jeśli połączysz dwie kolekcje po 50 000 dokumentów, koszty będą rosły w niekorzystny sposób. To nie jest prosty koszt liniowy.
Limity wydajności W moich testach potok dla 10 000 dokumentów zajmował 380 ms. Gdy przetestowałem 100 000 dokumentów, zapytanie przekroczyło limit czasu (timeout) po 30 sekundach. Nie rozwiązujesz problemu – po prostu zamieniasz błąd partii na błąd przekroczenia czasu oczekiwania.
Problemy z "zimnym startem" (Cold Start) Pipelines tworzą oddzielny kontekst wykonania. W środowiskach serverless, takich jak Cloud Functions, dodaje to od 2 do 4 sekund opóźnienia. Twoi użytkownicy uznają, że Twoja aplikacja działa wolno.
Pipelines API to narzędzie do prototypowania lub pracy z małymi kolekcjami liczącymi poniżej 5 000 dokumentów. Nie jest to zamiennik dla relacyjnej bazy danych. Google udostępnia to rozwiązanie, aby pomóc Ci pozostać w ekosystemie Firebase zamiast przechodzić do PostgreSQL lub Spanner.
Jeśli używasz Pipelines, przestrzegaj tych zasad:
• Przeanalizuj rozmiar swojej kolekcji. Jeśli kolekcja przekracza 20 000 dokumentów, najpierw oblicz koszt operacji JOIN. • Ogranicz złożoność. JOIN obejmujący trzy lub więcej kolekcji to zły znak. • Monitoruj koszty odczytu co tydzień. Odczyty z Pipelines pojawiają się na rachunku w inny sposób. • Zachowaj swoje zdenormalizowane dane. Używaj Pipelines jako uzupełnienia, a nie całkowitego zamiennika. • Testuj przy rzeczywistym ruchu. Benchmarki na mało aktywnych kolekcjach nie odzwierciedlają rzeczywistości produkcyjnej.
Nie używaj plastra, aby uniknąć podjęcia realnej decyzji architektonicznej.
Jak radzisz sobie z relacjami w Firestore? Korzystasz z denormalizacji czy z JOIN-ów po stronie klienta? Daj mi znać w komentarzach.