Firestore JOIN Trap
તમે Firestore ની એક સામાન્ય સમસ્યાનો સામનો કરી રહ્યા છો. તમારી Firebase function માં maximum batch size error આવે છે. તમારે ડેશબોર્ડ માટે orders અને customers ને join કરવાની જરૂર છે. આને ઠીક કરવા માટે તમે સામાન્ય રીતે ડેટા ડુપ્લીકેટ કરો છો. પરંતુ હવે તમારો ડેટા જૂનો (stale) અને અસંગત (inconsistent) બની જાય છે.
Google એ આ સમસ્યાના ઉકેલ માટે Pipelines API ની જાહેરાત કરી છે. તે ડેટા ડુપ્લીકેટ કર્યા વિના વિવિધ collections વચ્ચે JOIN ઓપરેશન્સ કરવાની મંજૂરી આપે છે. કેટલાક ડેવલપર્સ નાના ટેસ્ટમાં ઝડપી ક્વેરી સમયના રિપોર્ટ આપે છે.
મેં ભારે લોડ હેઠળ આ API નું પરીક્ષણ કરવામાં એક અઠવાડિયું વિતાવ્યું છે. દસ્તાવેજો (documentation) તમને જે નથી કહેતા તે અહીં છે.
ઊંચો ખર્ચ (High Costs) દરેક pipeline execution સામેલ તમામ collections માંથી ડેટા વાંચે છે. બે collections વચ્ચેના JOIN માટે તમને બંનેમાં થતા reads માટે બિલ આપવામાં આવે છે. જો તમે 50,000 ડોક્યુમેન્ટ્સ ધરાવતા બે collections ને join કરો છો, તો તમારો ખર્ચ ખૂબ વધી શકે છે. તે કોઈ સાદો રેખીય (linear) ખર્ચ નથી.
પર્ફોર્મન્સ મર્યાદાઓ (Performance Limits) મારા ટેસ્ટમાં, 10,000 ડોક્યુમેન્ટ્સ સામેના pipeline ને 380ms લાગ્યા. જ્યારે મેં 100,000 ડોક્યુમેન્ટ્સનું ટેસ્ટિંગ કર્યું, ત્યારે ક્વેરી 30 સેકન્ડમાં timeout થઈ ગઈ. તમે સમસ્યા હલ નથી કરી રહ્યા, તમે ફક્ત batch error ને timeout error માં બદલી રહ્યા છો.
Cold Start સમસ્યાઓ Pipelines એક અલગ execution context બનાવે છે. Cloud Functions જેવા serverless વાતાવરણમાં, આનાથી 2 થી 4 સેકન્ડનો વિલંબ થાય છે. તમારા વપરાશકર્તાઓને લાગશે કે તમારું એપ ધીમું છે.
Pipelines API એ પ્રોટોટાઇપિંગ અથવા 5,000 ડોક્યુમેન્ટ્સથી ઓછા ધરાવતા નાના collections માટેનું સાધન છે. તે relational database નો વિકલ્પ નથી. Google આ એટલા માટે આપે છે જેથી તમે PostgreSQL અથવા Spanner પર જવાને બદલે Firebase ecosystem માં જ રહી શકો.
જો તમે Pipelines નો ઉપયોગ કરો છો, તો આ નિયમોનું પાલન કરો:
• તમારા collection ના કદનું ઓડિટ કરો. જો કોઈ collection 20,000 ડોક્યુમેન્ટ્સથી વધી જાય, તો પહેલા JOIN ખર્ચની ગણતરી કરો. • જટિલતા મર્યાદિત કરો. ત્રણ કે તેથી વધુ collections વચ્ચેનું JOIN ખરાબ સંકેત છે. • દર અઠવાડિયે read ખર્ચને ટ્રેક કરો. તમારા બિલમાં Pipeline reads અલગ રીતે દેખાય છે. • તમારો denormalized ડેટા રાખો. Pipelines નો ઉપયોગ પૂરક તરીકે કરો, સંપૂર્ણ વિકલ્પ તરીકે નહીં. • વાસ્તવિક ટ્રાફિક સાથે ટેસ્ટ કરો. શાંત (quiet) collections પરના benchmarks પ્રોડક્શનની વાસ્તવિકતા દર્શાવતા નથી.
વાસ્તવિક આર્કિટેક્ચરલ નિર્ણય ટાળવા માટે કામચલાઉ ઉપાય (band-aid) નો ઉપયોગ કરશો નહીં.
તમે Firestore માં સંબંધો (relationships) કેવી રીતે હેન્ડલ કરો છો? શું તમે denormalization અથવા client-side joins નો ઉપયોગ કરો છો? મને કોમેન્ટ્સમાં જણાવો.