یہ ڈیٹا بیس جل رہا ہے...

یہ ڈیٹا بیس جل رہا ہے...

مجھے ایک تکنیکی کہانی سنانے دو۔

کئی سال پہلے، میں ایک ایپلیکیشن تیار کر رہا تھا جس میں تعاون کی خصوصیات شامل تھیں۔ یہ ایک صارف دوست تجرباتی اسٹیک تھا جس نے ابتدائی React اور CouchDB کی پوری صلاحیت سے فائدہ اٹھایا۔ اس نے JSON کے ذریعے حقیقی وقت میں ڈیٹا کو سنکرونائز کیا۔ OT. یہ کمپنی کے اندر اندرونی طور پر استعمال ہوتا تھا، لیکن دیگر شعبوں میں اس کا وسیع اطلاق اور صلاحیت واضح تھی۔

اس ٹیکنالوجی کو ممکنہ گاہکوں کو فروخت کرنے کی کوشش کرتے ہوئے، ہمیں ایک غیر متوقع رکاوٹ کا سامنا کرنا پڑا۔ ڈیمو ویڈیو میں، ہماری ٹیکنالوجی بہت اچھی لگ رہی تھی اور کام کرتی تھی، وہاں کوئی مسئلہ نہیں تھا۔ ویڈیو نے بالکل ظاہر کیا کہ یہ کیسے کام کرتا ہے اور کسی بھی چیز کی نقل نہیں کی۔ ہم پروگرام کے استعمال کے لیے ایک حقیقت پسندانہ منظر نامے کے ساتھ آئے اور کوڈ کیا۔

یہ ڈیٹا بیس جل رہا ہے...
اصل میں، یہ مسئلہ بن گیا. ہمارے ڈیمو نے بالکل اسی طرح کام کیا جس طرح ہر کسی نے اپنی ایپلی کیشنز کی نقالی کی۔ خاص طور پر، معلومات کو فوری طور پر A سے B میں منتقل کر دیا گیا، چاہے وہ بڑی میڈیا فائلیں ہوں۔ لاگ ان ہونے کے بعد، ہر صارف نے نئی اندراجات دیکھے۔ ایپلی کیشن کا استعمال کرتے ہوئے، مختلف صارفین ایک ہی پروجیکٹ پر واضح طور پر مل کر کام کر سکتے ہیں، چاہے گاؤں میں کہیں انٹرنیٹ کنکشن میں خلل پڑا ہو۔ افٹر ایفیکٹس میں کسی بھی پروڈکٹ کی ویڈیو کٹ میں یہ واضح طور پر مضمر ہے۔

اگرچہ ہر کوئی جانتا تھا کہ ریفریش بٹن کس چیز کے لیے ہے، لیکن کوئی بھی حقیقت میں یہ نہیں سمجھتا تھا کہ وہ ویب ایپلیکیشنز جو انہوں نے ہم سے بنانے کے لیے کہا ہے وہ عام طور پر ان کی اپنی حدود کے تابع تھے۔ اور یہ کہ اگر ان کی مزید ضرورت نہیں رہی تو صارف کا تجربہ بالکل مختلف ہوگا۔ انہوں نے بنیادی طور پر دیکھا کہ آپ اپنے بات چیت کرنے والوں کے لیے نوٹ چھوڑ کر "چیٹ" کر سکتے ہیں، لہذا وہ حیران ہوئے کہ یہ کیسے مختلف ہے، مثال کے طور پر، سلیک۔ افف!

روزمرہ کی مطابقت پذیری کا ڈیزائن

اگر آپ کو سافٹ ویئر کی تیاری کا تجربہ ہے، تو یہ یاد رکھنا اعصاب شکن ہونا چاہیے کہ زیادہ تر لوگ صرف انٹرفیس کی تصویر نہیں دیکھ سکتے اور یہ نہیں سمجھ سکتے کہ اس کے ساتھ بات چیت کرتے وقت یہ کیا کرے گا۔ پروگرام کے اندر کیا ہوتا ہے اس کا ذکر نہیں کرنا۔ جان لو کہ کر سکتے ہیں ہو جانا زیادہ تر یہ جاننے کا نتیجہ ہے کہ کیا نہیں ہو سکتا اور کیا نہیں ہونا چاہیے۔ اس کی ضرورت ہے۔ ذہنی ماڈل نہ صرف یہ کہ سافٹ ویئر کیا کرتا ہے، بلکہ یہ بھی کہ اس کے انفرادی حصے کس طرح مربوط اور ایک دوسرے کے ساتھ بات چیت کرتے ہیں۔

اس کی ایک بہترین مثال ایک صارف کو گھورنا ہے۔ اسپنر.gifسوچ رہا ہوں کہ کام آخر کب مکمل ہوگا۔ ڈویلپر نے محسوس کیا ہوگا کہ عمل شاید پھنس گیا تھا اور یہ کہ gif کبھی بھی اسکرین سے غائب نہیں ہوگا۔ یہ حرکت پذیری کسی کام کے عمل کو نقل کرتی ہے، لیکن اس کا تعلق اس کی حالت سے نہیں ہے۔ ایسے معاملات میں، کچھ تکنیکی ماہرین صارف کی الجھن کی حد تک حیران رہ کر آنکھیں گھمانا پسند کرتے ہیں۔ تاہم، غور کریں کہ ان میں سے کتنے گھومنے والی گھڑی کی طرف اشارہ کرتے ہیں اور کہتے ہیں کہ یہ واقعی ساکن ہے؟

یہ ڈیٹا بیس جل رہا ہے...
یہ حقیقی وقت کی قدر کا جوہر ہے۔ ان دنوں، ریئل ٹائم ڈیٹا بیس اب بھی بہت کم استعمال ہوتے ہیں اور بہت سے لوگ انہیں شک کی نگاہ سے دیکھتے ہیں۔ ان میں سے زیادہ تر ڈیٹا بیس NoSQL طرز کی طرف بہت زیادہ جھکاؤ رکھتے ہیں، یہی وجہ ہے کہ وہ عام طور پر مونگو پر مبنی حل استعمال کرتے ہیں، جنہیں بہترین طریقے سے بھلا دیا جاتا ہے۔ تاہم، میرے لیے اس کا مطلب ہے CouchDB کے ساتھ کام کرنے کے لیے آرام دہ ہونا، اور ساتھ ہی ایسے ڈھانچے کو ڈیزائن کرنا سیکھنا جو صرف کچھ بیوروکریٹ ڈیٹا سے بھر سکتے ہیں۔ مجھے لگتا ہے کہ میں اپنا وقت بہتر طریقے سے استعمال کر رہا ہوں۔

لیکن اس پوسٹ کا اصل موضوع وہی ہے جو میں آج استعمال کر رہا ہوں۔ انتخاب سے نہیں، بلکہ لاتعلق اور اندھا دھند لاگو کارپوریٹ پالیسیوں کی وجہ سے۔ اس لیے میں گوگل ریئل ٹائم ڈیٹا بیس پروڈکٹس کا ایک مکمل طور پر منصفانہ اور غیر جانبدارانہ موازنہ فراہم کروں گا۔

یہ ڈیٹا بیس جل رہا ہے...
دونوں کے ناموں میں آگ کا لفظ ہے۔ ایک بات مجھے شوق سے یاد ہے۔ میرے لیے دوسری چیز آگ کی مختلف قسم ہے۔ مجھے ان کے نام بتانے میں کوئی جلدی نہیں ہے، کیونکہ ایک بار جب میں کروں گا، تو ہم پہلی بڑی پریشانی میں پڑ جائیں گے: نام۔

پہلے والا کہا جاتا ہے۔ فائر بیس ریئل ٹائم ڈیٹا بیس، اور دوسرا۔ فائر بیس کلاؤڈ فائر اسٹور. یہ دونوں کی مصنوعات ہیں۔ فائر بیس سویٹ گوگل ان کے APIs کو بالترتیب کہا جاتا ہے۔ firebase.database(…) и firebase.firestore(…).

یہ ہوا کیونکہ ریئل ٹائم ڈیٹا بیس - یہ صرف اصل ہے فائر بیس 2014 میں گوگل کے ذریعہ اس کی خریداری سے پہلے۔ پھر گوگل نے ایک متوازی پروڈکٹ کے طور پر تخلیق کرنے کا فیصلہ کیا۔ کاپی Firebase بڑی ڈیٹا کمپنی پر مبنی ہے، اور اسے کلاؤڈ کے ساتھ Firestore کہتے ہیں۔ مجھے امید ہے کہ آپ ابھی تک کنفیوز نہیں ہوئے ہیں۔ اگر آپ اب بھی الجھن میں ہیں تو پریشان نہ ہوں، میں نے خود مضمون کے اس حصے کو دس بار دوبارہ لکھا۔

کیونکہ آپ کو اشارہ کرنے کی ضرورت ہے۔ فائر بیس Firebase سوال میں، اور فائر اسٹور Firebase کے بارے میں ایک سوال میں، کم از کم آپ کو چند سال پہلے اسٹیک اوور فلو پر سمجھنے کے لیے۔

اگر سافٹ ویئر کے نام دینے کے بدترین تجربے کے لیے کوئی ایوارڈ تھا، تو یہ یقینی طور پر دعویداروں میں سے ایک ہوگا۔ ان ناموں کے درمیان ہیمنگ کا فاصلہ اتنا کم ہے کہ یہ تجربہ کار انجینئروں کو بھی الجھا دیتا ہے جن کی انگلیاں ایک نام ٹائپ کرتی ہیں جبکہ ان کے سر دوسرے کے بارے میں سوچ رہے ہوتے ہیں۔ یہ نیک نیتی کے منصوبے ہیں جو بری طرح ناکام ہو جاتے ہیں۔ انہوں نے اس پیشین گوئی کو پورا کیا کہ ڈیٹا بیس کو آگ لگ جائے گی۔ اور میں بالکل بھی مذاق نہیں کر رہا ہوں۔ اس نام کی اسکیم کے ساتھ آنے والے شخص نے خون، پسینہ اور آنسو بہائے۔

یہ ڈیٹا بیس جل رہا ہے...

پیرک فتح

کوئی سوچے گا کہ فائر اسٹور ہے۔ متبادل Firebase، اس کی اگلی نسل کی اولاد، لیکن یہ گمراہ کن ہوگا۔ Firestore کے Firebase کے لیے مناسب متبادل ہونے کی ضمانت نہیں ہے۔ ایسا لگتا ہے کہ کسی نے اس میں سے ہر دلچسپ چیز کو کاٹ دیا، اور باقی میں سے بیشتر کو مختلف طریقوں سے الجھایا۔

تاہم، دونوں مصنوعات پر ایک سرسری نظر آپ کو الجھن میں ڈال سکتی ہے: ایسا لگتا ہے کہ وہ ایک ہی کام کرتے ہیں، بنیادی طور پر ایک ہی APIs کے ذریعے اور یہاں تک کہ ایک ہی ڈیٹا بیس سیشن میں۔ اختلافات ٹھیک ٹھیک ہیں اور صرف وسیع دستاویزات کے محتاط تقابلی مطالعہ سے ظاہر ہوتے ہیں۔ یا جب آپ کوڈ کو پورٹ کرنے کی کوشش کر رہے ہوں جو Firebase پر بالکل کام کرتا ہو تاکہ یہ Firestore کے ساتھ کام کرے۔ تب بھی آپ کو پتہ چلتا ہے کہ جیسے ہی آپ حقیقی وقت میں ماؤس کے ساتھ ڈریگ اور ڈراپ کرنے کی کوشش کرتے ہیں ڈیٹا بیس انٹرفیس روشن ہوجاتا ہے۔ میں دہراتا ہوں، میں مذاق نہیں کر رہا ہوں۔

Firebase کلائنٹ اس لحاظ سے شائستہ ہے کہ یہ تبدیلیوں کو بفر کرتا ہے اور خود بخود اپ ڈیٹس کی دوبارہ کوشش کرتا ہے جو آخری تحریری عمل کو ترجیح دیتے ہیں۔ تاہم، Firestore کے پاس فی دستاویز فی صارف فی سیکنڈ 1 رائٹ آپریشن کی حد ہے، اور یہ حد سرور کے ذریعے نافذ کی جاتی ہے۔ اس کے ساتھ کام کرتے وقت، یہ آپ پر منحصر ہے کہ آپ اس کے ارد گرد کوئی راستہ تلاش کریں اور اپ ڈیٹ کی شرح کو محدود کریں، یہاں تک کہ جب آپ صرف اپنی درخواست بنانے کی کوشش کر رہے ہوں۔ یعنی، Firestore ایک حقیقی وقت کا ڈیٹا بیس ہے جس میں ریئل ٹائم کلائنٹ نہیں ہے، جو API کا استعمال کرتے ہوئے ایک کے طور پر ڈھونگ کرتا ہے۔

یہاں ہم Firestore کے raison d'être کی پہلی نشانیاں دیکھنا شروع کرتے ہیں۔ میں غلط ہو سکتا ہوں، لیکن مجھے شبہ ہے کہ گوگل کی انتظامیہ میں کسی اعلیٰ شخص نے خریداری کے بعد Firebase کی طرف دیکھا اور صرف اتنا کہا، "نہیں، اوہ میرے خدا، نہیں۔ یہ ناقابل قبول ہے۔ صرف میری قیادت میں نہیں۔"

یہ ڈیٹا بیس جل رہا ہے...
وہ اپنے حجرے سے نمودار ہوا اور اعلان کیا:

"ایک بڑی JSON دستاویز؟ نہیں. آپ ڈیٹا کو الگ الگ دستاویزات میں تقسیم کریں گے، جن میں سے ہر ایک کا سائز 1 میگا بائٹ سے زیادہ نہیں ہوگا۔

ایسا لگتا ہے کہ اس طرح کی حد کسی بھی کافی حوصلہ افزائی والے صارف کی بنیاد کے ساتھ پہلے تصادم میں زندہ نہیں رہے گی۔ آپ جانتے ہیں کہ یہ ہے۔ کام پر، مثال کے طور پر، ہمارے پاس ڈیڑھ ہزار سے زیادہ پیشکشیں ہیں، اور یہ مکمل طور پر نارمل ہے۔

اس حد کے ساتھ، آپ اس حقیقت کو قبول کرنے پر مجبور ہو جائیں گے کہ ڈیٹا بیس میں موجود ایک "دستاویز" کسی ایسی چیز سے مشابہت نہیں رکھتی جسے صارف کسی دستاویز کا نام دے سکتا ہے۔

"اروں کی صفیں جو بار بار دوسرے عناصر پر مشتمل ہوسکتی ہیں؟ نہیں. صفوں میں صرف مقررہ لمبائی والی اشیاء یا اعداد شامل ہوں گے، جیسا کہ خدا کا ارادہ ہے۔"

لہذا اگر آپ GeoJSON کو اپنے Firestore میں ڈالنے کی امید کر رہے تھے، تو آپ کو معلوم ہوگا کہ یہ ممکن نہیں ہے۔ غیر جہتی کوئی بھی چیز قابل قبول نہیں ہے۔ مجھے امید ہے کہ آپ کو JSON کے اندر Base64 اور/یا JSON پسند آئے گا۔

"JSON HTTP، کمانڈ لائن ٹولز یا ایڈمن پینل کے ذریعے درآمد اور برآمد کریں؟ نہیں. آپ صرف Google Cloud Storage میں ڈیٹا برآمد اور درآمد کر سکیں گے۔ میرے خیال میں اب اسی کو کہتے ہیں۔ اور جب میں "آپ" کہتا ہوں تو میں صرف ان لوگوں سے مخاطب ہوں جن کے پاس پروجیکٹ اونر کی اسناد ہیں۔ باقی سب جا کر ٹکٹ بنا سکتے ہیں۔"

جیسا کہ آپ دیکھ سکتے ہیں، FireBase ڈیٹا ماڈل کی وضاحت کرنا آسان ہے۔ اس میں ایک بہت بڑی JSON دستاویز ہے جو JSON کیز کو URL کے راستوں کے ساتھ منسلک کرتی ہے۔ اگر آپ کے ساتھ لکھیں۔ HTTP PUT в / FireBase درج ذیل ہے:

{
  "hello": "world"
}

The 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 سے ملتا جلتا ہے، لیکن کچھ اہم طریقوں سے مختلف ہے۔ میں نے پہلے ہی صفوں میں صفوں کی کمی کا ذکر کیا ہے۔ ذیلی مجموعوں کا ماڈل ان کے لیے فرسٹ کلاس تصورات ہونا ہے، جو JSON دستاویز سے الگ ہے جو ان پر مشتمل ہے۔ چونکہ اس کے لیے کوئی ریڈی میڈ سیریلائزیشن نہیں ہے، اس لیے ڈیٹا کو بازیافت کرنے اور لکھنے کے لیے ایک خصوصی کوڈ پاتھ کی ضرورت ہے۔ اپنے اپنے مجموعوں پر کارروائی کرنے کے لیے، آپ کو اپنے اسکرپٹ اور ٹولز لکھنے کی ضرورت ہے۔ ایڈمن پینل آپ کو ایک وقت میں صرف ایک فیلڈ میں چھوٹی تبدیلیاں کرنے کی اجازت دیتا ہے، اور اس میں درآمد/برآمد کی صلاحیتیں نہیں ہیں۔

انہوں نے ایک حقیقی وقت کا NoSQL ڈیٹا بیس لیا اور اسے آٹو جوائن اور ایک علیحدہ غیر JSON کالم کے ساتھ ایک سست نان ایس کیو ایل میں تبدیل کردیا۔ GraftQL کی طرح کچھ.

یہ ڈیٹا بیس جل رہا ہے...

گرم جاوا

اگر فائر اسٹور کو زیادہ قابل اعتماد اور توسیع پذیر سمجھا جاتا تھا، تو ستم ظریفی یہ ہے کہ اوسط ڈویلپر فائر بیس کو باکس سے باہر منتخب کرنے سے کم قابل اعتماد حل کے ساتھ ختم ہوگا۔ بدمزاج ڈیٹا بیس ایڈمنسٹریٹر کو جس قسم کے سافٹ ویئر کی ضرورت ہوتی ہے اس کے لیے کوشش اور صلاحیت کی سطح کی ضرورت ہوتی ہے جو کہ اس جگہ کے لیے غیر حقیقی ہے جس پر پروڈکٹ کو اچھا سمجھا جاتا ہے۔ یہ اسی طرح ہے کہ کس طرح HTML5 کینوس فلیش کا متبادل نہیں ہے اگر کوئی ڈویلپمنٹ ٹولز اور پلیئر نہ ہوں۔ مزید برآں، Firestore ڈیٹا کی پاکیزگی اور جراثیم سے پاک توثیق کی خواہش میں مبتلا ہے جو کہ اوسط کاروباری صارف کے طریقہ کار سے مطابقت نہیں رکھتا۔ کام کرنا پسند ہے؟: اس کے لیے ہر چیز اختیاری ہے، کیونکہ آخر تک ہر چیز ایک مسودہ ہے۔

FireBase کا بنیادی نقصان یہ ہے کہ کلائنٹ کو اس کے وقت سے کئی سال پہلے بنایا گیا تھا، اس سے پہلے کہ زیادہ تر ویب ڈویلپرز کو غیر متغیر ہونے کے بارے میں علم ہو۔ اس کی وجہ سے، FireBase فرض کرتا ہے کہ آپ ڈیٹا کو تبدیل کر دیں گے اور اس لیے صارف کی طرف سے فراہم کردہ تبدیلی کا فائدہ نہیں اٹھاتا ہے۔ مزید برآں، یہ اسنیپ شاٹس میں موجود ڈیٹا کو دوبارہ استعمال نہیں کرتا جو یہ صارف کو دیتا ہے، جس کی وجہ سے فرق زیادہ مشکل ہو جاتا ہے۔ بڑی دستاویزات کے لیے، اس کا تغیر پذیر فرق پر مبنی لین دین کا طریقہ کار محض ناکافی ہے۔ دوستو، ہمارے پاس پہلے ہی موجود ہے۔ WeakMap جاوا اسکرپٹ میں۔ یہ آرام دہ ہے۔

اگر آپ اعداد و شمار کو مطلوبہ شکل دیتے ہیں اور درختوں کو بہت زیادہ نہیں بناتے ہیں، تو اس مسئلے کو دور کیا جا سکتا ہے. لیکن میں متجسس ہوں کہ اگر فائر بیس بہت زیادہ دلچسپ ہو گا اگر ڈویلپرز نے واقعی ایک اچھا کلائنٹ API جاری کیا جس میں ڈیٹا بیس کے ڈیزائن کے بارے میں کچھ سنجیدہ عملی مشورے کے ساتھ غیر متغیر کا استعمال کیا گیا ہو۔ اس کے بجائے، وہ اسے ٹھیک کرنے کی کوشش کرتے نظر آئے جو ٹوٹا نہیں تھا، اور اس نے اسے مزید خراب کر دیا۔

میں فائر اسٹور کی تخلیق کے پیچھے تمام منطق نہیں جانتا ہوں۔ بلیک باکس کے اندر پیدا ہونے والے محرکات کے بارے میں قیاس آرائی کرنا بھی تفریح ​​کا حصہ ہے۔ دو انتہائی مماثل لیکن لاجواب ڈیٹا بیس کا یہ جوڑ بہت کم ہے۔ یہ ایسا ہی ہے جیسے کسی نے سوچا: "Firebase صرف ایک فنکشن ہے جسے ہم گوگل کلاؤڈ میں نقل کر سکتے ہیں"، لیکن ابھی تک حقیقی دنیا کی ضروریات کی نشاندہی کرنے یا ان تمام ضروریات کو پورا کرنے والے مفید حل تخلیق کرنے کا تصور دریافت نہیں کیا ہے۔ "ڈویلپرز کو اس کے بارے میں سوچنے دیں۔ بس UI کو خوبصورت بنائیں... کیا آپ مزید آگ لگا سکتے ہیں؟"

میں ڈیٹا ڈھانچے کے بارے میں کچھ چیزیں سمجھتا ہوں۔ میں یقینی طور پر "ایک بڑے JSON درخت میں سب کچھ" تصور کو ڈیٹا بیس سے بڑے پیمانے پر ڈھانچے کے کسی بھی احساس کو ختم کرنے کی کوشش کے طور پر دیکھتا ہوں۔ کسی بھی مشکوک ڈیٹا سٹرکچر فریکٹل سے نمٹنے کے لیے سافٹ ویئر کی توقع محض پاگل پن ہے۔ مجھے یہ تصور کرنے کی بھی ضرورت نہیں ہے کہ چیزیں کتنی بری ہو سکتی ہیں، میں نے سخت کوڈ آڈٹ کیے ہیں اور میں نے ایسی چیزیں دیکھی ہیں جن کا تم لوگوں نے کبھی خواب بھی نہیں دیکھا تھا۔. لیکن میں یہ بھی جانتا ہوں کہ اچھے ڈھانچے کیسی نظر آتی ہیں، ان کا استعمال کیسے کریں и یہ کیوں کیا جانا چاہئے. میں ایک ایسی دنیا کا تصور کر سکتا ہوں جہاں Firestore منطقی لگے گا اور اسے بنانے والے لوگ سوچیں گے کہ انہوں نے اچھا کام کیا ہے۔ لیکن ہم اس دنیا میں نہیں رہتے۔

فائر بیس کی استفسار کی حمایت کسی بھی معیار کے لحاظ سے ناقص ہے اور عملی طور پر غیر موجود ہے۔ اس میں یقینی طور پر بہتری یا کم از کم نظر ثانی کی ضرورت ہے۔ لیکن فائر اسٹور زیادہ بہتر نہیں ہے کیونکہ یہ سادہ ایس کیو ایل میں پائے جانے والے ایک ہی جہتی اشاریہ جات تک محدود ہے۔ اگر آپ کو ایسے سوالات کی ضرورت ہے جو لوگ افراتفری والے ڈیٹا پر چلتے ہیں، تو آپ کو فل ٹیکسٹ سرچ، ملٹی رینج فلٹرز، اور حسب ضرورت صارف کی وضاحت کردہ ترتیب کی ضرورت ہے۔ قریب سے معائنہ کرنے پر، سادہ ایس کیو ایل کے افعال اپنے طور پر بہت محدود ہیں۔ مزید برآں، صرف SQL سوالات جو لوگ پیداوار میں چلا سکتے ہیں وہ تیز سوالات ہیں۔ آپ کو سوچے سمجھے ڈیٹا ڈھانچے کے ساتھ حسب ضرورت انڈیکسنگ حل کی ضرورت ہوگی۔ باقی ہر چیز کے لیے، کم از کم انکریمنٹل میپ-ریڈیوس یا کچھ ایسا ہی ہونا چاہیے۔

اگر آپ اس بارے میں معلومات کے لیے Google Docs کو تلاش کرتے ہیں، تو امید ہے کہ آپ کو BigTable اور BigQuery جیسی کسی چیز کی طرف اشارہ کیا جائے گا۔ تاہم، یہ تمام حل اتنے گھنے کارپوریٹ سیلز جرگن کے ساتھ ہیں کہ آپ جلدی سے پیچھے ہٹ جائیں گے اور کچھ اور تلاش کرنا شروع کر دیں گے۔

آخری چیز جو آپ حقیقی وقت کے ڈیٹا بیس کے ساتھ چاہتے ہیں وہ ہے جو انتظامی تنخواہ کے پیمانے پر لوگوں کے ذریعہ اور ان کے لیے بنائی گئی ہے۔

(*) یہ ایک لطیفہ ہے، ایسی کوئی بات نہیں ہے۔ 100% JSON ہم آہنگ.

ایڈورٹائزنگ کے حقوق پر

تلاش وی ڈی ایس۔ ڈیبگنگ پروجیکٹس کے لیے، ترقی اور ہوسٹنگ کے لیے ایک سرور؟ آپ یقینی طور پر ہمارے کلائنٹ ہیں 🙂 مختلف کنفیگریشنز کے سرورز کے لیے روزانہ کی قیمتوں کا تعین، اینٹی DDoS اور ونڈوز لائسنس پہلے سے ہی قیمت میں شامل ہیں۔

یہ ڈیٹا بیس جل رہا ہے...

ماخذ: www.habr.com

نیا تبصرہ شامل کریں