هي ڊيٽابيس باهه تي آهي ...

اچو ته هڪ ٽيڪنيڪل ڪهاڻي ٻڌايان.

ڪيترائي سال اڳ، مان هڪ ايپليڪيشن ٺاهي رهيو هوس جنهن ۾ تعاون جي خاصيتن سان ٺهيل هئي. اهو هڪ صارف دوست تجرباتي اسٽيڪ هو جنهن شروعاتي رد عمل ۽ CouchDB جي مڪمل صلاحيت مان فائدو ورتو. اهو JSON ذريعي حقيقي وقت ۾ ڊيٽا کي هم وقت سازي ڪري ٿو OT. اهو ڪمپني اندر اندر استعمال ڪيو ويو، پر ٻين علائقن ۾ ان جي وسيع قابل اطلاق ۽ صلاحيت واضح هئي.

هن ٽيڪنالاجي کي امڪاني گراهڪن کي وڪڻڻ جي ڪوشش ڪندي، اسان هڪ غير متوقع رڪاوٽ جو سامنا ڪيو. ڊيمو ويڊيو ۾، اسان جي ٽيڪنالاجي ڏٺو ۽ ڪم ڪيو وڏو، اتي ڪو مسئلو ناهي. وڊيو ڏيکاريو ته اهو ڪيئن ڪم ڪري ٿو ۽ ڪجھ به نقل نه ڪيو. اسان پروگرام استعمال ڪرڻ لاءِ هڪ حقيقي منظر نامي سان گڏ آيا ۽ ڪوڊ ڪيو.


حقيقت ۾، اهو مسئلو بڻجي ويو. اسان جي ڊيمو بلڪل ڪم ڪيو جيئن هرڪو پنهنجي ايپليڪيشنن کي نقل ڪيو. خاص طور تي، معلومات کي فوري طور تي A کان B تائين منتقل ڪيو ويو، جيتوڻيڪ اها وڏي ميڊيا فائلون هئي. لاگ اِن ٿيڻ کان پوءِ، هر يوزر نئين داخلائون ڏٺيون. ايپليڪيشن کي استعمال ڪندي، مختلف صارفين ساڳئي منصوبن تي واضح طور تي گڏجي ڪم ڪري سگھن ٿا، جيتوڻيڪ ڳوٺ ۾ ڪٿي انٽرنيٽ ڪنيڪشن جي وقفي جي صورت ۾. اهو اثر بعد ۾ ڪنهن به پراڊڪٽ وڊيو ڪٽ ۾ شامل آهي.

جيتوڻيڪ سڀني کي خبر هئي ته ريفريش بٽڻ ڇا لاءِ آهي، ڪنهن به واقعي اهو نه سمجهيو ته اهي ويب ايپليڪيشنون جيڪي انهن اسان کي ٺاهڻ لاءِ چيو اهي عام طور تي انهن جي پنهنجي حدن جي تابع هئا. ۽ جيڪڏهن اهي وڌيڪ گهربل نه آهن، صارف جو تجربو مڪمل طور تي مختلف هوندو. انهن گهڻو ڪري اهو محسوس ڪيو ته اهي انهن ماڻهن لاءِ نوٽس ڇڏڻ سان ”چيٽ“ ڪري سگهن ٿا جن سان اهي ڳالهائي رهيا هئا، تنهن ڪري اهي حيران ٿي ويا ته اهو ڪيئن مختلف آهي، مثال طور، Slack. اڙي!

روزمره جي هم وقت سازي جي ڊيزائن

جيڪڏهن توهان وٽ سافٽ ويئر ڊولپمينٽ ۾ تجربو آهي، اهو ياد رکڻ لاء اعصاب خراب ٿيڻ گهرجي ته گهڻا ماڻهو صرف هڪ انٽرفيس جي تصوير کي نه ڏسي سگهندا آهن ۽ سمجهي سگهندا آهن ته اهو ڇا ڪندو جڏهن ان سان لهه وچڙ ۾. اهو ذڪر نه ڪرڻ گهرجي ته پروگرام جي اندر ڇا ٿئي ٿو. اها ڄاڻ ڪري سگهي ٿو گهڻو ڪري اهو ڄاڻڻ جو نتيجو آهي ته ڇا نه ٿو ٿئي ۽ ڇا نه ٿيڻ گهرجي. هن جي ضرورت آهي ذهني ماڊل نه رڳو سافٽ ويئر ڇا ڪندو آهي، پر اهو پڻ ته ڪيئن ان جا انفرادي حصا هڪ ٻئي سان هم آهنگ ۽ رابطي ۾ آهن.

ھن جو ھڪڙو مثالي مثال ھڪڙو صارف آھي جيڪو ھڪڙو گھمندو آھي اسپنر.gifسوچيم ته آخر ڪم ڪڏهن پورو ٿيندو. ڊولپر اهو محسوس ڪري ها ته اهو عمل شايد پڪو ڪيو ويو هو ۽ اهو GIF ڪڏهن به اسڪرين مان غائب نه ٿيندو. هي حرکت پذير هڪ نوڪري جي عمل کي ترتيب ڏئي ٿو، پر ان جي رياست سان لاڳاپيل ناهي. اهڙين حالتن ۾، ڪجهه ٽيڪنيڪيون پنهنجون اکيون ڦرڻ پسند ڪن ٿيون، صارفين جي مونجهاري جي حد تائين حيران ٿي ويا آهن. بهرحال، ڏسو ته انهن مان ڪيترا گھمندڙ گھڙي ڏانهن اشارو ڪن ٿا ۽ چون ٿا ته اهو اصل ۾ اسٽيشنري آهي؟

هي اصل وقت جي قيمت جو جوهر آهي. اهي ڏينهن، حقيقي وقت ڊيٽابيس اڃا تائين تمام گهٽ استعمال ڪيا ويا آهن ۽ ڪيترائي ماڻهو انهن کي شڪ سان ڏسندا آهن. انهن مان گھڻا ڊيٽابيس NoSQL طرز تي تمام گھڻو جھڪندا آھن، اھو ئي سبب آھي جو اھي عام طور تي مونگو تي ٻڌل حل استعمال ڪندا آھن، جيڪي بھترين وساري ويا آھن. تنهن هوندي، مون لاء هن جو مطلب آهي CouchDB سان ڪم ڪرڻ ۾ آرام سان، انهي سان گڏ تعميرات کي ڊزائين ڪرڻ جي سکيا جيڪا صرف ڪجهه بيوروڪريٽ ڊيٽا سان ڀري سگهي ٿي. مان سمجهان ٿو ته مان پنهنجو وقت بهتر استعمال ڪري رهيو آهيان.

پر هن پوسٽ جو اصل موضوع اهو آهي جيڪو مان اڄ استعمال ڪري رهيو آهيان. چونڊ ذريعي نه، پر لاتعلقي ۽ انڌا لاڳو ٿيل ڪارپوريٽ پاليسين جي ڪري. تنهن ڪري مان مهيا ڪندس مڪمل طور تي منصفانه ۽ غيرجانبدار مقابلو ٻن ويجهن سان لاڳاپيل گوگل جي حقيقي وقت ڊيٽابيس پروڊڪٽس.

ٻنهي جي نالن ۾ لفظ فائر آهي. هڪڙي ڳالهه مون کي دل سان ياد آهي. ٻي شيءِ منهنجي لاءِ هڪ مختلف قسم جي باهه آهي. مون کي انهن جا نالا ٻڌائڻ جي ڪا به جلدي ناهي، ڇاڪاڻ ته هڪ دفعو آئون ڪريان ٿو، اسان پهرين وڏي مسئلي ۾ هلنداسين: نالا.

پهرين نالو جو نالو فائربيس ريئل ٽائيم ڊيٽابيس، ۽ ٻيو - Firebase Cloud Firestore. انهن ٻنهي مان پيداوار آهن فائر بيس سوٽ گوگل. انهن جي APIs کي ترتيب سان سڏيو ويندو آهي firebase.database(…) и firebase.firestore(…).

اهو ٿيو ڇاڪاڻ ته حقيقي وقت ڊيٽابيس - اهو صرف اصل آهي باهه 2014 ۾ گوگل طرفان ان جي خريداري کان اڳ. پوءِ گوگل هڪ متوازي پراڊڪٽ طور ٺاهڻ جو فيصلو ڪيو ڪاپي Firebase وڏي ڊيٽا ڪمپني جي بنياد تي، ۽ ان کي سڏيو Firestore هڪ بادل سان. مون کي اميد آهي ته توهان اڃا تائين پريشان نه آهيو. جيڪڏھن توھان اڃا تائين پريشان آھيو، پريشان نه ڪريو، مون پاڻ مضمون جي ھن حصي کي ڏھ ڀيرا لکيو آھي.

ڇو ته توهان کي اشارو ڪرڻو پوندو باهه فائر بيس سوال ۾، ۽ پسٽ فائر فائر بيس بابت هڪ سوال ۾، گهٽ ۾ گهٽ توهان کي سمجهڻ لاءِ ڪجهه سال اڳ اسٽيڪ اوور فلو تي.

جيڪڏهن بدترين سافٽ ويئر جي نالي جي تجربي لاءِ ڪو انعام هو، ته اهو ضرور هڪ اميدوار هوندو. انهن نالن جي وچ ۾ هيمنگ جو فاصلو ايترو ننڍو آهي جو اهو تجربيڪار انجنيئرن کي به پريشان ڪري ٿو، جن جون آڱريون هڪ نالو ٽائيپ ڪنديون آهن، جڏهن ته انهن جا مٿو ٻئي بابت سوچي رهيا آهن. اهي نيڪ نيتيءَ وارا منصوبا آهن جيڪي بُري طرح ناڪام ٿين ٿا. انهن پيشنگوئي کي پورو ڪيو ته ڊيٽابيس کي باهه لڳندي. ۽ مان بلڪل مذاق نه ڪري رهيو آهيان. جنهن ماڻهوءَ به هن نالي جي اسڪيم ٺاهي، تنهن جو رت، پگهر ۽ ڳوڙها وهي آيا.

پيرن جي فتح

هڪ سوچيو ته Firestore آهي متبادل فائر بيس، ان جي ايندڙ نسل جو اولاد، پر اھو گمراھ ٿيندو. فائر اسٽور فائر بيس لاءِ مناسب متبادل هجڻ جي ضمانت نه آهي. اهو ڏسڻ ۾ اچي ٿو ته ڪنهن ماڻهو ان مان دلچسپ هر شيء کي ڪٽي ڇڏيو، ۽ باقي گهڻو ڪري مختلف طريقن سان پريشان ڪيو.

بهرحال، ٻن پراڊڪٽس تي هڪ تڪڙي نظر شايد توهان کي پريشان ڪري سگهي ٿي: اهي ساڳيو ڪم ڪرڻ لڳي ٿو، بنيادي طور تي ساڳئي APIs ذريعي ۽ ساڳئي ڊيٽابيس سيشن ۾. اختلاف ذيلي آهن ۽ صرف وسيع دستاويزن جي محتاط تقابلي مطالعي سان ظاهر ڪيا ويا آهن. يا جڏهن توهان ڪوشش ڪري رهيا آهيو پورٽ ڪوڊ جيڪو مڪمل طور تي ڪم ڪري ٿو Firebase تي ته جيئن اهو Firestore سان ڪم ڪري. تنهن هوندي به توهان اهو ڳوليندا آهيو ته ڊيٽابيس انٽرفيس روشن ٿي ويندو آهي جيئن ئي توهان اصل وقت ۾ مائوس سان ڇڪڻ ۽ ڇڏڻ جي ڪوشش ڪندا آهيو. مان ورجائي ٿو، مان مذاق نه ڪري رهيو آهيان.

فائر بيس ڪلائنٽ ان لحاظ کان شائستہ آهي ته اهو تبديلين کي بفر ڪري ٿو ۽ خودڪار طريقي سان تازه ڪاريون ٻيهر آزمائي ٿو جيڪي آخري لکڻ جي عمل کي اوليت ڏين ٿا. بهرحال، Firestore وٽ 1 لکت آپريشن جي حد آهي في دستاويز في صارف في سيڪنڊ، ۽ اها حد سرور طرفان لاڳو ڪئي وئي آهي. جڏهن ان سان ڪم ڪري رهيا آهيو، اهو توهان تي آهي ته ان جي چوڌاري هڪ رستو ڳولڻ ۽ هڪ تازه ڪاري جي شرح جي حد کي لاڳو ڪرڻ، جيتوڻيڪ جڏهن توهان صرف پنهنجي ايپليڪيشن ٺاهڻ جي ڪوشش ڪري رهيا آهيو. اهو آهي، Firestore هڪ حقيقي وقت ڊيٽابيس آهي حقيقي وقت جي ڪلائنٽ کان سواء، جيڪو هڪ API استعمال ڪندي هڪ طور تي masquerades.

هتي اسان کي ڏسڻ شروع ڪريون ٿا فائر اسٽور جي ريزن ڊي جي پهرين نشانيون. مان غلط ٿي سگهي ٿو، پر مون کي شڪ آهي ته گوگل جي انتظاميا ۾ ڪنهن اعليٰ شخص خريداري کان پوءِ فائر بيس کي ڏٺو ۽ صرف ايترو چيو، ”نه، او منهنجا خدا، نه. هي ناقابل قبول آهي. بس منهنجي قيادت هيٺ نه آهي."

هو پنهنجي ڪمري مان ظاهر ٿيو ۽ اعلان ڪيو:

"هڪ وڏو JSON دستاويز؟ نه. توهان ڊيٽا کي الڳ الڳ دستاويزن ۾ ورهائيندا، جن مان هر هڪ جي ماپ ۾ 1 ميگا بائيٽ کان وڌيڪ نه هوندي.

اهو لڳي ٿو ته اهڙي حد تائين ڪنهن به ڪافي حوصلا افزائي صارف جي بنياد سان پهرين مقابلي کان بچي نه سگهندي. توهان کي خبر آهي ته اهو آهي. ڪم تي، مثال طور، اسان وٽ هڪ اڌ هزار کان وڌيڪ پيشيونٽيون آهن، ۽ اهو مڪمل طور تي عام آهي.

هن حد سان، توهان کي ان حقيقت کي قبول ڪرڻ تي مجبور ڪيو ويندو ته ڊيٽابيس ۾ هڪ "دستاويز" ڪنهن به شئي سان مشابهت نه رکندو، جنهن کي صارف هڪ دستاويز سڏيندو.

”اريءَ جون صفون جيڪي بار بار ٻين عنصرن تي مشتمل هجن؟ نه. صفن ۾ صرف مقرر ڊگھائي شين يا انگن تي مشتمل هوندو، جيئن خدا جو ارادو آهي.

تنهن ڪري جيڪڏهن توهان جيو جيسن کي پنهنجي فائر اسٽور ۾ رکڻ جي اميد هئي، توهان کي معلوم ٿيندو ته اهو ممڪن ناهي. ڪا به شيءِ غير هڪ طرفي قبول نه آهي. مون کي اميد آهي ته توهان کي پسند ڪريو Base64 ۽/يا JSON اندر JSON.

"JSON درآمد ۽ برآمد HTTP ذريعي، ڪمانڊ لائن اوزار يا منتظم پينل؟ نه. توهان صرف گوگل ڪلائوڊ اسٽوريج ۾ ڊيٽا برآمد ۽ درآمد ڪرڻ جي قابل هوندا. اھو اھو آھي جيڪو ھاڻي سڏيو ويندو آھي، مان سمجهان ٿو. ۽ جڏهن مان چوان ٿو ”توهان،“ مان صرف انهن کي مخاطب ڪري رهيو آهيان جن وٽ پروجيڪٽ مالڪ جي سندون آهن. باقي هرڪو وڃي سگهي ٿو ۽ ٽڪيٽ ٺاهي سگهي ٿو.

جئين توهان ڏسي سگهو ٿا، فائر بيس ڊيٽا ماڊل بيان ڪرڻ آسان آهي. اهو هڪ وڏو JSON دستاويز تي مشتمل آهي جيڪو JSON ڪيز کي URL جي رستن سان ڳنڍي ٿو. جيڪڏهن توهان سان لکو HTTP PUT в / FireBase ھيٺ ڏنل آھي:

{
  "hello": "world"
}

سنڌ GET /hello واپس ڪندو "world". بنيادي طور تي اهو ڪم ڪري ٿو جيئن توهان توقع ڪئي هئي. FireBase شين جو مجموعو /my-collection/:id JSON لغت جي برابر {"my-collection": {...}} روٽ ۾، جنهن جو مواد موجود آهي /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

اهو ڪم ٺيڪ آهي جيڪڏهن هر داخل ٿيڻ ۾ هڪ ٽڪرائي آزاد ID آهي، جنهن لاء سسٽم هڪ معياري حل آهي.

ٻين لفظن ۾، ڊيٽابيس 100٪ JSON(*) مطابقت رکندڙ آهي ۽ HTTP سان گڏ ڪم ڪري ٿو، جهڙوڪ CouchDB. پر بنيادي طور تي توهان ان کي استعمال ڪريو حقيقي وقت جي API ذريعي جيڪو خلاصي ويب ساکٽ، اختيار، ۽ سبسڪرپشن. منتظم پينل ۾ ٻئي صلاحيتون آهن، ٻنهي کي حقيقي وقت جي ايڊيٽنگ ۽ JSON درآمد/برآمد جي اجازت ڏئي ٿي. جيڪڏهن توهان پنهنجي ڪوڊ ۾ اهو ئي ڪريو ٿا، توهان حيران ٿي ويندا ته ڪيترو خاص ڪوڊ ضايع ٿيندو جڏهن توهان محسوس ڪيو ته پيچ ۽ فرق JSON حل ڪري ٿو 90٪ معمولي ڪمن جو مستقل حالت کي سنڀالڻ جي.

Firestore ڊيٽا ماڊل JSON سان ملندڙ جلندڙ آهي، پر ڪجهه نازڪ طريقن سان مختلف آهي. مون اڳ ۾ ئي arrays اندر arrays جي کوٽ جو ذڪر ڪيو آهي. ذيلي مجموعن جو نمونو انھن لاءِ آھي فرسٽ ڪلاس تصورن لاءِ، JSON دستاويزن کان الڳ آھي جنھن ۾ اھي شامل آھن. جيئن ته ان لاءِ تيار ڪيل سيريلائيزيشن نه آهي، ڊيٽا کي ٻيهر حاصل ڪرڻ ۽ لکڻ لاءِ هڪ خاص ڪوڊ جو رستو گهربل آهي. توهان جي پنهنجي مجموعن کي پروسيس ڪرڻ لاء، توهان کي پنهنجي لکت ۽ اوزار لکڻ جي ضرورت آهي. منتظم پينل صرف توهان کي ننڍيون تبديليون ڪرڻ جي اجازت ڏئي ٿو هڪ وقت ۾ هڪ فيلڊ، ۽ نه آهي درآمد/برآمد صلاحيتون.

انهن هڪ حقيقي وقت جو NoSQL ڊيٽابيس ورتو ۽ ان کي آٽو-جوائن ۽ هڪ الڳ غير JSON ڪالمن سان سست غير SQL ۾ تبديل ڪيو. GraftQL وانگر ڪجهه.

گرم جاوا

جيڪڏهن فائر اسٽور کي وڌيڪ قابل اعتماد ۽ اسپيبلبل هجڻ گهرجي ها، ته پوءِ ستم ظريفي اها آهي ته اوسط ڊولپر باڪس مان فائر بيس چونڊڻ کان گهٽ قابل اعتماد حل سان ختم ڪندو. سافٽ ويئر جو قسم جنهن جي ضرورت آهي Grumpy ڊيٽابيس ايڊمنسٽريٽر کي ضرورت آهي هڪ سطح جي ڪوشش ۽ قابليت جي قابليت جيڪا صرف ان جڳهه لاءِ غير حقيقي آهي جنهن کي پراڊڪٽ سٺو هجڻ گهرجي. اهو ساڳيو آهي ته ڪيئن HTML5 ڪينواس فليش لاءِ متبادل نه آهي جيڪڏهن ڪو به ڊولپمينٽ اوزار ۽ پليئر نه هجي. ان کان علاوه، Firestore ڊيٽا جي پاڪائي ۽ جراثيم جي تصديق جي خواهش ۾ ڀريل آهي، جيڪو صرف انهي سان ترتيب نٿو ڏئي ته ڪيئن اوسط ڪاروبار صارف ڪم ڪرڻ پسند ڪندو آهي: هن لاءِ سڀ ڪجهه اختياري آهي، ڇاڪاڻ ته آخر تائين هر شيءِ هڪ مسودو آهي.

فائر بيس جو بنيادي نقصان اهو آهي ته ڪلائنٽ ان جي وقت کان ڪيترائي سال اڳ ٺاهي وئي هئي، ان کان اڳ اڪثر ويب ڊولپرز کي اڻڄاتل بابت ڄاڻ هئي. انهي جي ڪري، فائر بيس فرض ڪري ٿو ته توهان ڊيٽا کي تبديل ڪندا ۽ تنهن ڪري صارف جي مهيا ڪيل غير موثريت جو فائدو نه وٺندو. اضافي طور تي، اهو سنيپ شاٽ ۾ ڊيٽا کي ٻيهر استعمال نه ڪندو آهي اهو صارف ڏانهن گذري ٿو، جيڪو اختلاف کي وڌيڪ ڏکيو بڻائي ٿو. وڏين دستاويزن لاءِ، ان جي مٽاسٽا واري فرق تي ٻڌل ٽرانزيڪشن ميڪانيزم بلڪل نا مناسب آهي. دوست، اسان وٽ اڳ ۾ ئي آهي WeakMap JavaScript ۾. اهو آرامده آهي.

جيڪڏهن توهان ڊيٽا کي گهربل شڪل ڏيو ۽ وڻن کي تمام وڏو نه ٺاهيو، پوء اهو مسئلو ختم ٿي سگهي ٿو. پر مان تجسس آهيان جيڪڏهن فائر بيس تمام گهڻو دلچسپ هوندو جيڪڏهن ڊولپرز هڪ واقعي سٺو ڪلائنٽ API جاري ڪيو جنهن کي استعمال ڪيو عدم استحڪام سان گڏ ڊيٽابيس ڊيزائن تي ڪجهه سنجيده عملي مشوري سان. ان جي بدران، انهن کي درست ڪرڻ جي ڪوشش ڪئي وئي جيڪا ٽوڙي نه هئي، ۽ انهي کي وڌيڪ خراب ڪيو.

مون کي خبر ناهي ته فائر اسٽور جي تخليق جي پويان سڀ منطق. بليڪ باڪس جي اندر پيدا ٿيندڙ مقصدن بابت قياس ڪرڻ به مزو جو حصو آهي. ٻن انتهائي ملندڙ جلندڙ پر لاتعداد ڊيٽابيس جو هي ميلاپ بلڪل ناياب آهي. اهو آهي جيئن ڪنهن سوچيو: "فائر بيس صرف هڪ فنڪشن آهي جنهن کي اسين گوگل ڪلائوڊ ۾ نقل ڪري سگهون ٿا"، پر اڃا تائين دريافت نه ڪيو آهي حقيقي دنيا جي گهرجن کي سڃاڻڻ يا مفيد حل ٺاهڻ جو تصور جيڪي انهن سڀني ضرورتن کي پورا ڪن ٿا. "ڊولپرز کي ان بابت سوچڻ ڏيو. بس UI کي خوبصورت بڻايو... ڇا توهان وڌيڪ باهه شامل ڪري سگهو ٿا؟

مان ڊيٽا جي جوڙجڪ بابت ڪجھ شيون سمجھان ٿو. مان پڪ سان ڏسان ٿو "هڪ وڏي JSON وڻ ۾ سڀ ڪجهه" تصور کي ڊيٽابيس مان وڏي پيماني تي ساخت جي ڪنهن به احساس کي ختم ڪرڻ جي ڪوشش جي طور تي. ڪنهن به مشڪوڪ ڊيٽا جي ڍانچي کي فرڪٽل سان منهن ڏيڻ لاءِ سافٽ ويئر جي توقع صرف چريو آهي. مون کي اهو تصور ڪرڻ جي ضرورت ناهي ته شيون ڪيتريون خراب ٿي سگهن ٿيون، مون سخت ڪوڊ آڊٽ ڪيا آهن ۽ مون اهي شيون ڏٺيون جن جو توهان ماڻهن ڪڏهن به خواب نه ڏٺو هو. پر مان اهو به ڄاڻان ٿو ته ڪهڙيون سٺيون اڏاوتون نظر اچن ٿيون، ان کي ڪيئن استعمال ڪجي и اهو ڇو ٿيڻ گهرجي. مان تصور ڪري سگهان ٿو هڪ دنيا جتي Firestore منطقي لڳي ها ۽ جيڪي ماڻهو ان کي ٺاهين ها اهو سمجهن ها ته انهن سٺو ڪم ڪيو. پر اسان هن دنيا ۾ نه رهندا آهيون.

فائر بيس جي سوال جي مدد ڪنهن به معيار جي لحاظ کان ناقص آهي ۽ عملي طور تي غير موجود آهي. اهو ضرور سڌارو يا گهٽ ۾ گهٽ نظرثاني جي ضرورت آهي. پر Firestore وڌيڪ بهتر نه آهي ڇو ته اهو ساڳيو هڪ طرفي انڊيڪس تائين محدود آهي جيڪو سادي SQL ۾ ملي ٿو. جيڪڏهن توهان کي سوالن جي ضرورت آهي ته ماڻهو افراتفري واري ڊيٽا تي هلن ٿا، توهان کي مڪمل متن جي ڳولا، ملٽي رينج فلٽر، ۽ ڪسٽم صارف جي ترتيب ڏنل ترتيب جي ضرورت آهي. ويجهي معائني تي، سادي SQL جا ڪم پاڻ تي تمام محدود آهن. اضافي طور تي، صرف SQL سوال جيڪي ماڻهو هلائي سگهن ٿا پيداوار ۾ تيز سوال آهن. توهان کي سمارٽ ڊيٽا جي جوڙجڪ سان گڏ ڪسٽم انڊيڪسنگ حل جي ضرورت پوندي. باقي هر شيءِ لاءِ، گهٽ ۾ گهٽ هجڻ گهرجي وڌ ۾ وڌ نقشو-گهٽائڻ يا ٻيو ڪجهه.

جيڪڏھن توھان ان بابت معلومات لاءِ Google Docs ۾ ڳولھيو ٿا، توھان کي اميد آھي ته توھان کي ڪنھن شيءِ جي طرف اشارو ڪيو ويندو جھڙوڪ BigTable ۽ BigQuery. جڏهن ته، اهي سڀئي حل تمام گھڻي ڪارپوريٽ سيلز جارگن سان گڏ آهن ته توهان جلدي واپس ڦيرايو ۽ ٻيو ڪجهه ڳولڻ شروع ڪيو.

آخري شيء جيڪا توهان چاهيو ٿا حقيقي وقت جي ڊيٽابيس سان جيڪا ڪجهه ٺاهي وئي آهي ۽ ماڻهن لاءِ انتظاميا جي پگهار اسڪيل تي.

(*) هي هڪ مذاق آهي، اهڙي ڪا به شيء ناهي 100٪ JSON مطابقت.

اشتهارن جي حقن تي

ڳولڻ VDS ڊيبگنگ منصوبن لاءِ، ترقي ۽ ميزباني لاءِ سرور؟ توھان ضرور آھيو اسان جو ڪلائنٽ

جو ذريعو: www.habr.com