The Firestore JOIN Trap
మీరు ఒక సాధారణ Firestore సమస్యను ఎదుర్కొంటున్నారు. మీ Firebase function గరిష్ట బ్యాచ్ సైజ్ (maximum batch size) ఎర్రర్ను చూపుతుంది. ఒక డాష్బోర్డ్ కోసం మీకు ఆర్డర్లు (orders) మరియు కస్టమర్లను (customers) జాయిన్ చేయాల్సి ఉంటుంది. దీనిని పరిష్కరించడానికి మీరు సాధారణంగా డేటాను డూప్లికేట్ చేస్తారు. కానీ ఇప్పుడు మీ డేటా పాతదిగా (stale) మరియు అసమగ్రంగా (inconsistent) మారుతోంది.
దీనిని పరిష్కరించడానికి Google Pipelines APIని ప్రకటించింది. ఇది డేటాను డూప్లికేట్ చేయకుండానే వివిధ కలెక్షన్ల (collections) మధ్య JOIN ఆపరేషన్లను అనుమతిస్తుంది. కొన్ని డెవలపర్లు చిన్న పరీక్షల్లో వేగవంతమైన క్వెరీ సమయాలను (query times) గమనించారు.
నేను ఒక వారం పాటు భారీ లోడ్ (heavy load) కింద ఈ APIని పరీక్షించాను. డాక్యుమెంటేషన్ మీకు చెప్పని విషయాలు ఇక్కడ ఉన్నాయి.
High Costs ప్రతి పైప్లైన్ ఎగ్జిక్యూషన్ (pipeline execution) సంబంధిత అన్ని కలెక్షన్ల నుండి డేటాను చదువుతుంది. రెండు కలెక్షన్ల మధ్య JOIN చేసినప్పుడు, రెండింటిలోని రీడ్స్ (reads) కి కూడా మీరు బిల్లు చెల్లించాల్సి ఉంటుంది. మీరు 50,000 డాక్యుమెంట్లు ఉన్న రెండు కలెక్షన్లను జాయిన్ చేస్తే, మీ ఖర్చులు విపరీతంగా పెరుగుతాయి. ఇది కేవలం సరళమైన లీనియర్ ఖర్చు కాదు.
Performance Limits నా పరీక్షల్లో, 10,000 డాక్యుమెంట్లపై పైప్లైన్ 380ms సమయం తీసుకుంది. నేను 100,000 డాక్యుమెంట్లను పరీక్షించినప్పుడు, క్వెరీ 30 సెకన్ల వద్ద టైమ్ అవుట్ (timed out) అయింది. మీరు సమస్యను పరిష్కరించడం లేదు. మీరు కేవలం బ్యాచ్ ఎర్రర్ను టైమ్ అవుట్ ఎర్రర్గా మారుస్తున్నారు.
Cold Start Issues పైప్లైన్లు ఒక ప్రత్యేక ఎగ్జిక్యూషన్ కాంటెక్స్ట్ను (execution context) సృష్టిస్తాయి. Cloud Functions వంటి సర్వర్లెస్ ఎన్విరాన్మెంట్లలో (serverless environments), ఇది 2 నుండి 4 సెకన్ల ఆలస్యాన్ని కలిగిస్తుంది. మీ యాప్ నెమ్మదిగా ఉందని మీ వినియోగదారులు అనుకుంటారు.
Pipelines API అనేది ప్రోటోటైపింగ్ కోసం లేదా 5,000 డాక్యుమెంట్ల కంటే తక్కువ ఉన్న చిన్న కలెక్షన్ల కోసం ఉపయోగపడే సాధనం. ఇది రిలేషనల్ డేటాబేస్కు (relational database) ప్రత్యామ్నాయం కాదు. మీరు PostgreSQL లేదా Spannerకి మారకుండా, Firebase ఎకోసిస్టమ్లోనే కొనసాగడానికి సహాయపడటానికి Google దీనిని అందిస్తోంది.
మీరు Pipelines ఉపయోగిస్తే, ఈ నియమాలను పాటించండి:
• మీ కలెక్షన్ పరిమాణాన్ని తనిఖీ చేయండి (Audit). ఒక కలెక్షన్ 20,000 డాక్యుమెంట్ల కంటే ఎక్కువ ఉంటే, ముందుగా JOIN ఖర్చును లెక్కించండి. • సంక్లిష్టతను పరిమితం చేయండి. మూడు లేదా అంతకంటే ఎక్కువ కలెక్షన్ల మధ్య JOIN చేయడం మంచి సంకేతం కాదు. • రీడ్ ఖర్చులను వారానికోసారి ట్రాక్ చేయండి. మీ బిల్లులో పైప్లైన్ రీడ్స్ భిన్నంగా కనిపిస్తాయి. • మీ డీనార్మలైజ్డ్ డేటాను (denormalized data) అలాగే ఉంచండి. Pipelinesను ఒక అనుబంధంగా (supplement) ఉపయోగించండి, పూర్తిగా ప్రత్యామ్నాయంగా కాదు. • నిజమైన ట్రాఫిక్తో పరీక్షించండి. తక్కువ ట్రాఫిక్ ఉన్న కలెక్షన్లపై చేసే బెంచ్మార్క్లు (benchmarks) ప్రొడక్షన్ రియాలిటీని ప్రతిబింబించవు.
నిజమైన ఆర్కిటెక్చరల్ నిర్ణయాన్ని (architectural decision) తప్పించుకోవడానికి తాత్కాలిక పరిష్కారాలను (band-aid) వాడకండి.
మీరు Firestoreలో రిలేషన్షిప్లను (relationships) ఎలా నిర్వహిస్తారు? మీరు డీనార్మలైజేషన్ (denormalization) ఉపయోగిస్తారా లేదా క్లయింట్-సైడ్ జాయిన్స్ (client-side joins) ఉపయోగిస్తారా? కామెంట్లలో నాకు చెప్పండి.