Firestore JOIN കെണി
നിങ്ങൾ ഒരു സാധാരണ Firestore പ്രശ്നം നേരിടുന്നു. നിങ്ങളുടെ Firebase ഫംഗ്ഷൻ ഒരു 'maximum batch size error' കാണിക്കുന്നു. ഒരു ഡാഷ്ബോർഡിനായി ഓർഡറുകളും (orders) കസ്റ്റമർമാരെയും (customers) തമ്മിൽ ബന്ധിപ്പിക്കേണ്ടതുണ്ട് (join). ഇത് പരിഹരിക്കാൻ നിങ്ങൾ സാധാരണയായി ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യാറുണ്ട്. എന്നാൽ ഇപ്പോൾ നിങ്ങളുടെ ഡാറ്റ പഴയതും (stale) പൊരുത്തക്കേടുള്ളതുമായി (inconsistent) മാറുന്നു.
ഇത് പരിഹരിക്കുന്നതിനായി Google Pipelines API പ്രഖ്യാപിച്ചു. ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യാതെ തന്നെ വിവിധ കളക്ഷനുകൾക്കിടയിൽ JOIN ഓപ്പറേഷനുകൾ നടത്താൻ ഇത് അനുവദിക്കുന്നു. ചെറിയ ടെസ്റ്റുകളിൽ വേഗത്തിലുള്ള ക്വറി ടൈം (query time) ലഭിക്കുന്നതായി ചില ഡെവലപ്പർമാർ റിപ്പോർട്ട് ചെയ്യുന്നുണ്ട്.
കനത്ത ലോഡിന് (heavy load) കീഴിൽ ഈ API പരീക്ഷിക്കാൻ ഞാൻ ഒരാഴ്ച ചിലവഴിച്ചു. ഡോക്യുമെന്റേഷനിൽ പറയുന്നില്ലാത്ത കാര്യങ്ങൾ ഇതാ:
ഉയർന്ന ചിലവ് (High Costs) ഓരോ പൈപ്പ്ലൈൻ എക്സിക്യൂഷനും (pipeline execution) ഉൾപ്പെട്ട എല്ലാ കളക്ഷനുകളിൽ നിന്നും ഡാറ്റ വായിക്കുന്നു. രണ്ട് കളക്ഷനുകൾ തമ്മിലുള്ള ഒരു JOIN, രണ്ട് കളക്ഷനുകളിലെയും റീഡുകൾക്കായി (reads) നിങ്ങളിൽ നിന്ന് ചാർജ് ചെയ്യും. 50,000 ഡോക്യുമെന്റുകളുള്ള രണ്ട് കളക്ഷനുകൾ നിങ്ങൾ ജോയിൻ ചെയ്താൽ, നിങ്ങളുടെ ചിലവ് വളരെ കൂടുതലായി വർദ്ധിക്കും. ഇത് ലളിതമായ ഒരു ലീനിയർ കോസ്റ്റ് (linear cost) അല്ല.
പെർഫോമൻസ് പരിധികൾ (Performance Limits) എന്റെ ടെസ്റ്റുകളിൽ, 10,000 ഡോക്യുമെന്റുകൾക്കെതിരെയുള്ള ഒരു പൈപ്പ്ലൈൻ 380ms എടുത്തു. 100,000 ഡോക്യുമെന്റുകൾ പരീക്ഷിച്ചപ്പോൾ, ക്വറി 30 സെക്കൻഡിൽ ടൈം ഔട്ട് (timeout) ആയി. നിങ്ങൾ പ്രശ്നം പരിഹരിക്കുകയല്ല ചെയ്യുന്നത്, മറിച്ച് ഒരു 'batch error'-നെ ഒരു 'timeout error'-ലേക്ക് മാറ്റുക മാത്രമാണ് ചെയ്യുന്നത്.
കോൾഡ് സ്റ്റാർട്ട് പ്രശ്നങ്ങൾ (Cold Start Issues) പൈപ്പ്ലൈനുകൾ ഒരു പ്രത്യേക എക്സിക്യൂഷൻ കോൺടെക്സ്റ്റ് (execution context) സൃഷ്ടിക്കുന്നു. Cloud Functions പോലുള്ള സെർവ്ലെസ് എൻവയോൺമെന്റുകളിൽ (serverless environments), ഇത് 2 മുതൽ 4 സെക്കൻഡ് വരെ കാലതാമസം ഉണ്ടാക്കുന്നു. നിങ്ങളുടെ ആപ്പ് പതുക്കെയാണെന്ന് ഉപയോക്താക്കൾക്ക് തോന്നും.
പ്രോട്ടോടൈപ്പിംഗിനോ (prototyping) അല്ലെങ്കിൽ 5,000-ൽ താഴെ ഡോക്യുമെന്റുകളുള്ള ചെറിയ കളക്ഷനുകൾക്കോ വേണ്ടിയുള്ള ഒരു ടൂൾ മാത്രമാണ് Pipelines API. ഇതൊരു റിലേഷണൽ ഡാറ്റാബേസിനുള്ള (relational database) പകരക്കാരനല്ല. PostgreSQL അല്ലെങ്കിൽ Spanner ലേക്ക് മാറുന്നതിന് പകരം Firebase ഇക്കോസിസ്റ്റത്തിൽ തന്നെ തുടരാൻ നിങ്ങളെ സഹായിക്കാനാണ് Google ഇത് നൽകുന്നത്.
നിങ്ങൾ Pipelines ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, ഈ നിയമങ്ങൾ പാലിക്കുക:
• നിങ്ങളുടെ കളക്ഷൻ വലിപ്പം പരിശോധിക്കുക (Audit). ഒരു കളക്ഷനിൽ 20,000-ൽ കൂടുതൽ ഡോക്യുമെന്റുകൾ ഉണ്ടെങ്കിൽ, ആദ്യം JOIN ചിലവ് കണക്കാക്കുക. • സങ്കീർണ്ണത പരിമിതപ്പെടുത്തുക. മൂന്നോ അതിലധികമോ കളക്ഷനുകൾക്കിടയിലുള്ള ഒരു JOIN മോശമായ സൂചനയാണ്. • റീഡ് ചിലവുകൾ (read costs) ആഴ്ചതോറും ട്രാക്ക് ചെയ്യുക. പൈപ്പ്ലൈൻ റീഡുകൾ നിങ്ങളുടെ ബില്ലിൽ വ്യത്യസ്തമായിട്ടായിരിക്കും കാണപ്പെടുക. • നിങ്ങളുടെ ഡെനോർമലൈസ്ഡ് ഡാറ്റ (denormalized data) നിലനിർത്തുക. Pipelines ഒരു പൂരകമായി (supplement) ഉപയോഗിക്കുക, പൂർണ്ണമായ പകരക്കാരനായിട്ടല്ല. • യഥാർത്ഥ ട്രാഫിക്കോടെ പരീക്ഷിക്കുക. കുറഞ്ഞ ഉപയോഗമുള്ള കളക്ഷനുകളിലെ ബെഞ്ച്മാർക്കുകൾ (benchmarks) പ്രൊഡക്ഷൻ സാഹചര്യങ്ങളെ പ്രതിഫലിപ്പിക്കില്ല.
യഥാർത്ഥമായ ഒരു ആർക്കിടെക്ചറൽ തീരുമാനം (architectural decision) ഒഴിവാക്കാൻ ഒരു താൽക്കാലിക പരിഹാരം (band-aid) ഉപയോഗിക്കരുത്.
നിങ്ങൾ Firestore-ൽ റിലേഷൻഷിപ്പുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു? നിങ്ങൾ ഡെനോർമലൈസേഷൻ (denormalization) ആണോ അതോ ക്ലയന്റ് സൈഡ് ജോയിൻസ് (client-side joins) ആണോ ഉപയോഗിക്കുന്നത്? കമന്റുകളിൽ എന്നോട് പറയൂ.