The Firestore JOIN کا جال
آپ کو Firestore کے ایک عام مسئلے کا سامنا ہے۔ آپ کا Firebase فنکشن 'maximum batch size error' دے رہا ہے۔ آپ کو ڈیش بورڈ کے لیے orders اور customers کو جوڑنے (join کرنے) کی ضرورت ہے۔ اس مسئلے کو حل کرنے کے لیے آپ عام طور پر ڈیٹا کو ڈپلیکیٹ کر دیتے ہیں۔ لیکن اب آپ کا ڈیٹا پرانا (stale) اور غیر مستقل (inconsistent) ہو چکا ہے۔
گوگل نے اسے حل کرنے کے لیے Pipelines API کا اعلان کیا ہے۔ یہ ڈیٹا کو ڈپلیکیٹ کیے بغیر مختلف collections کے درمیان JOIN آپریشنز کی اجازت دیتا ہے۔ کچھ ڈویلپرز نے چھوٹے پیمانے کے ٹیسٹ میں تیز کوئری ٹائمز (query times) کی اطلاع دی ہے۔
میں نے بھاری لوڈ (heavy load) کے تحت اس API کی ایک ہفتہ تک جانچ پڑتال کی۔ یہاں وہ باتیں ہیں جو دستاویزات (documentation) آپ کو نہیں بتاتیں۔
زیادہ اخراجات ہر pipeline execution تمام متعلقہ collections سے ڈیٹا پڑھتی ہے۔ دو collections کے درمیان JOIN کرنے پر آپ کو دونوں میں ہونے والی reads کے پیسے دینے پڑتے ہیں۔ اگر آپ 50,000 دستاویزات والے دو collections کو جوڑتے ہیں، تو آپ کے اخراجات بہت تیزی سے بڑھیں گے۔ یہ کوئی سادہ لینیئر (linear) خرچہ نہیں ہے۔
کارکردگی کی حدود میرے ٹیسٹ میں، 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 کا متبادل نہیں ہے۔ گوگل یہ اس لیے فراہم کرتا ہے تاکہ آپ PostgreSQL یا Spanner پر منتقل ہونے کے بجائے Firebase ecosystem میں ہی رہ سکیں۔
اگر آپ Pipelines استعمال کرتے ہیں، تو ان اصولوں پر عمل کریں:
• اپنے collection کے سائز کا جائزہ لیں۔ اگر کوئی collection 20,000 دستاویزات سے تجاوز کر جائے، تو پہلے JOIN کے اخراجات کا حساب لگائیں۔ • پیچیدگی کو محدود رکھیں۔ تین یا اس سے زیادہ collections کے درمیان JOIN کرنا ایک برا اشارہ ہے۔ • ہفتہ وار read اخراجات کا حساب رکھیں۔ Pipeline reads آپ کے بل میں مختلف طریقے سے ظاہر ہوتی ہیں۔ • اپنا denormalized ڈیٹا برقرار رکھیں۔ Pipelines کو ایک اضافی سہولت کے طور پر استعمال کریں، مکمل متبادل کے طور پر نہیں۔ • حقیقی ٹریفک کے ساتھ ٹیسٹ کریں۔ کم ٹریفک والے collections پر کیے گئے benchmarks پروڈکشن کی حقیقت کی عکاسی نہیں کرتے۔
کسی حقیقی آرکیٹیکچرل فیصلے سے بچنے کے لیے عارضی حل (band-aid) کا استعمال نہ کریں۔
آپ Firestore میں relationships کو کیسے ہینڈل کرتے ہیں؟ کیا آپ denormalization استعمال کرتے ہیں یا client-side joins؟ مجھے کمنٹس میں بتائیں۔