De Firestore JOIN-valstrik
Je loopt tegen een veelvoorkomend Firestore-probleem aan. Je Firebase-functie geeft een foutmelding over de maximale batchgrootte. Je moet orders en klanten samenvoegen (joinen) voor een dashboard. Meestal dupliceer je gegevens om dit op te lossen. Maar nu zijn je gegevens verouderd en inconsistent.
Google heeft de Pipelines API aangekondigd om dit op te lossen. Het maakt JOIN-operaties tussen collecties mogelijk zonder gegevens te dupliceren. Sommige ontwikkelaars melden snelle querytijden in kleine tests.
Ik heb een week lang deze API getest onder zware belasting. Dit is wat de documentatie je niet vertelt.
Hoge kosten Elke pipeline-executie leest uit alle betrokken collecties. Een JOIN tussen twee collecties brengt kosten in rekening voor reads in beide collecties. Als je twee collecties van 50.000 documenten samenvoegt, schalen je kosten slecht. Het is geen eenvoudige lineaire kost.
Prestatiebeperkingen In mijn tests duurde een pipeline voor 10.000 documenten 380 ms. Toen ik 100.000 documenten testte, liep de query vast na 30 seconden. Je lost het probleem niet op. Je verandert alleen een batchfout in een timeoutfout.
Cold Start-problemen Pipelines creëren een aparte executiecontext. In serverless-omgevingen zoals Cloud Functions zorgt dit voor een vertraging van 2 tot 4 seconden. Je gebruikers zullen denken dat je app traag is.
De Pipelines API is een hulpmiddel voor prototyping of kleine collecties van minder dan 5.000 documenten. Het is geen vervanging voor een relationele database. Google biedt dit aan om je te helpen binnen het Firebase-ecosysteem te blijven in plaats van over te stappen naar PostgreSQL of Spanner.
Als je Pipelines gebruikt, volg dan deze regels:
• Controleer de grootte van je collectie. Als een collectie meer dan 20.000 documenten bevat, bereken dan eerst de JOIN-kosten. • Beperk de complexiteit. Een JOIN over drie of meer collecties is een slecht teken. • Houd de read-kosten wekelijks bij. Pipeline-reads verschijnen anders op je factuur. • Behoud je gedenormaliseerde gegevens. Gebruik Pipelines als aanvulling, niet als volledige vervanging. • Test met echt verkeer. Benchmarks op rustige collecties weerspiegelen de realiteit van de productieomgeving niet.
Gebruik geen pleister om een echte architecturale beslissing te vermijden.
Hoe ga jij om met relaties in Firestore? Gebruik je denormalisatie of client-side joins? Laat het me weten in de reacties.