La trappola delle JOIN in Firestore
Ti scontri con un problema comune di Firestore. La tua funzione Firebase restituisce un errore relativo alla dimensione massima del batch. Hai bisogno di unire (join) ordini e clienti per una dashboard. Di solito duplichi i dati per risolvere il problema, ma ora i tuoi dati sono obsoleti e incoerenti.
Google ha annunciato la Pipelines API per risolvere questo problema. Consente operazioni di JOIN tra diverse collection senza duplicare i dati. Alcuni sviluppatori riportano tempi di query rapidi in test su piccola scala.
Ho trascorso una settimana a testare questa API sotto carico pesante. Ecco cosa non ti dice la documentazione.
Costi elevati Ogni esecuzione di una pipeline effettua letture da tutte le collection coinvolte. Una JOIN tra due collection ti addebita le letture in entrambe. Se esegui una JOIN tra due collection da 50.000 documenti, i costi non scalano bene. Non si tratta di un semplice costo lineare.
Limiti di performance Nei miei test, una pipeline su 10.000 documenti ha impiegato 380ms. Quando ho testato 100.000 documenti, la query è andata in timeout dopo 30 secondi. Non stai risolvendo il problema; stai solo trasformando un errore di batch in un errore di timeout.
Problemi di Cold Start Le pipeline creano un contesto di esecuzione separato. In ambienti serverless come Cloud Functions, questo aggiunge da 2 a 4 secondi di ritardo. Gli utenti penseranno che la tua app sia lenta.
La Pipelines API è uno strumento per la prototipazione o per piccole collection inferiori a 5.000 documenti. Non è un sostituto di un database relazionale. Google la fornisce per aiutarti a rimanere nell'ecosistema Firebase invece di passare a PostgreSQL o Spanner.
Se utilizzi le Pipelines, segui queste regole:
• Analizza la dimensione della tua collection. Se una collection supera i 20.000 documenti, calcola prima il costo della JOIN. • Limita la complessità. Una JOIN tra tre o più collection è un cattivo segno. • Monitora i costi di lettura settimanalmente. Le letture delle pipeline appaiono in modo diverso nella tua fattura. • Mantieni i tuoi dati denormalizzati. Usa le Pipelines come supplemento, non come sostituto totale. • Testa con traffico reale. I benchmark su collection poco attive non riflettono la realtà della produzione.
Non usare un cerotto per evitare una vera decisione architettonica.
Come gestisci le relazioni in Firestore? Usi la denormalizzazione o le JOIN lato client? Fammi sapere nei commenti.