بیک اینڈ ڈویلپر یہ کیسے سمجھتا ہے کہ ایس کیو ایل استفسار "پروڈ" پر اچھی طرح کام کرے گا؟ بڑی یا تیزی سے بڑھتی ہوئی کمپنیوں میں، ہر کسی کو "پروڈکٹ" تک رسائی حاصل نہیں ہوتی۔ اور رسائی کے ساتھ، تمام درخواستوں کو بغیر کسی تکلیف کے چیک نہیں کیا جا سکتا، اور ڈیٹا بیس کی کاپی بنانے میں اکثر گھنٹے لگ جاتے ہیں۔ ان مسائل کو حل کرنے کے لیے، ہم نے ایک مصنوعی DBA - جو بنایا۔ یہ پہلے ہی کئی کمپنیوں میں کامیابی کے ساتھ لاگو ہو چکا ہے اور ایک درجن سے زیادہ ڈویلپرز کی مدد کرتا ہے۔
ویڈیو:
سب کو سلام! میرا نام اناتولی سٹینسلر ہے۔ میں ایک کمپنی میں کام کرتا ہوں۔ . ہم ڈیولپرز، DBAs اور QAs سے Postgres کے کام سے منسلک تاخیر کو دور کر کے ترقیاتی عمل کو تیز کرنے کے لیے پرعزم ہیں۔
ہمارے پاس بہت اچھے کلائنٹس ہیں اور آج کی رپورٹ کا کچھ حصہ ان معاملات کے لیے وقف کیا جائے گا جو ہم ان کے ساتھ کام کرتے ہوئے ملے تھے۔ میں اس بارے میں بات کروں گا کہ ہم نے ان کی کافی سنگین مسائل کو حل کرنے میں کس طرح مدد کی۔
جب ہم پیچیدہ زیادہ بوجھ والی ہجرت کو ترقی اور کر رہے ہوتے ہیں، تو ہم اپنے آپ سے یہ سوال پوچھتے ہیں: "کیا یہ ہجرت ختم ہو جائے گی؟"۔ ہم جائزہ کا استعمال کرتے ہیں، ہم زیادہ تجربہ کار ساتھیوں، DBA ماہرین کے علم کا استعمال کرتے ہیں۔ اور وہ بتا سکتے ہیں کہ یہ اڑ جائے گا یا نہیں۔
لیکن شاید یہ بہتر ہو گا کہ ہم خود اسے مکمل سائز کی کاپیوں پر آزما سکیں۔ اور آج ہم صرف اس بارے میں بات کریں گے کہ ٹیسٹنگ کے لیے اب کون سے طریقے ہیں اور اسے کس طرح بہتر اور کن ٹولز سے کیا جا سکتا ہے۔ ہم اس طرح کے طریقوں کے فوائد اور نقصانات کے بارے میں بھی بات کریں گے، اور ہم یہاں کیا ٹھیک کر سکتے ہیں۔
کس نے کبھی براہ راست پروڈ پر اشاریہ جات بنائے ہیں یا کوئی تبدیلی کی ہے؟ کافی تھوڑا سا. اور یہ کس کے لیے اس حقیقت کا باعث بنا کہ ڈیٹا ضائع ہو گیا تھا یا وقتی وقت نہیں تھا؟ پھر آپ کو اس درد کا علم ہے۔ خدا کا شکر ہے کہ بیک اپ موجود ہیں۔
پہلا نقطہ نظر پروڈ میں جانچ کر رہا ہے۔ یا، جب کوئی ڈویلپر مقامی مشین پر بیٹھتا ہے، تو اس کے پاس ٹیسٹ ڈیٹا ہوتا ہے، کسی قسم کا محدود انتخاب ہوتا ہے۔ اور ہم پروڈکشن کے لیے رول آؤٹ کرتے ہیں، اور ہمیں یہ صورتحال ملتی ہے۔
یہ درد ہے، یہ مہنگا ہے. یہ نہ کرنا شاید بہتر ہے۔
اور ایسا کرنے کا بہترین طریقہ کیا ہے؟
آئیے اسٹیجنگ لیں اور وہاں پروڈ کا کچھ حصہ منتخب کریں۔ یا بہترین طور پر، آئیے ایک حقیقی پیداوار لیں، تمام ڈیٹا۔ اور مقامی طور پر اسے تیار کرنے کے بعد، ہم اس کے علاوہ اسٹیجنگ کی بھی جانچ کریں گے۔
یہ ہمیں کچھ خرابیوں کو دور کرنے کی اجازت دے گا، یعنی انہیں پروڈکشن پر ہونے سے روکے گا۔
مسائل کیا ہیں؟
- مسئلہ یہ ہے کہ ہم اس سٹیجنگ کو ساتھیوں کے ساتھ شیئر کرتے ہیں۔ اور اکثر ایسا ہوتا ہے کہ آپ کسی قسم کی تبدیلی کرتے ہیں، بام - اور کوئی ڈیٹا نہیں ہے، کام ختم ہو رہا ہے۔ اسٹیجنگ ملٹی ٹیرا بائٹ تھی۔ اور اس کے دوبارہ اٹھنے کے لیے آپ کو طویل انتظار کرنا پڑے گا۔ اور ہم کل اسے حتمی شکل دینے کا فیصلہ کرتے ہیں۔ بس، ہماری ترقی ہے۔
- اور، یقینا، ہمارے وہاں بہت سے ساتھی کام کر رہے ہیں، بہت سی ٹیمیں ہیں۔ اور اسے دستی طور پر کرنا ہوگا۔ اور یہ تکلیف دہ ہے۔
اور یہ کہنے کے قابل ہے کہ ہمارے پاس صرف ایک کوشش ہے، ایک شاٹ، اگر ہم ڈیٹا بیس میں کچھ تبدیلیاں کرنا چاہتے ہیں، ڈیٹا کو چھوئیں، ڈھانچہ تبدیل کریں۔ اور اگر کچھ غلط ہوا ہے، اگر ہجرت میں کوئی خرابی ہوئی ہے، تو ہم جلدی سے پیچھے نہیں ہٹیں گے۔
یہ پچھلے نقطہ نظر سے بہتر ہے، لیکن اب بھی ایک اعلی امکان ہے کہ کسی قسم کی خرابی پیداوار میں جائے گی۔
ہمیں ہر ڈویلپر کو ٹیسٹ بینچ، ایک مکمل سائز کی کاپی دینے سے کیا روکتا ہے؟ میرے خیال میں یہ واضح ہے کہ راستے میں کیا آتا ہے۔
کس کے پاس ٹیرا بائٹ سے بڑا ڈیٹا بیس ہے؟ آدھے سے زیادہ کمرہ۔
اور یہ واضح ہے کہ ہر ڈویلپر کے لیے مشینیں رکھنا، جب اتنی بڑی پیداوار ہو، بہت مہنگی ہوتی ہے، اور اس کے علاوہ، اس میں کافی وقت لگتا ہے۔
ہمارے پاس ایسے کلائنٹس ہیں جنہوں نے محسوس کیا ہے کہ تمام تبدیلیوں کو مکمل سائز کی کاپیوں پر جانچنا بہت ضروری ہے، لیکن ان کا ڈیٹا بیس ایک ٹیرا بائٹ سے کم ہے، اور ہر ڈویلپر کے لیے ٹیسٹ بینچ رکھنے کے لیے وسائل نہیں ہیں۔ لہذا، انہیں مقامی طور پر ڈمپ کو اپنی مشین میں ڈاؤن لوڈ کرنا ہوگا اور اس طرح ٹیسٹ کرنا ہوگا۔ اس میں بہت وقت لگتا ہے۔
یہاں تک کہ اگر آپ اسے انفراسٹرکچر کے اندر کرتے ہیں، تو فی گھنٹہ ایک ٹیرا بائٹ ڈیٹا ڈاؤن لوڈ کرنا پہلے ہی بہت اچھا ہے۔ لیکن وہ منطقی ڈمپ استعمال کرتے ہیں، وہ بادل سے مقامی طور پر ڈاؤن لوڈ کرتے ہیں۔ ان کے لیے رفتار تقریباً 200 گیگا بائٹس فی گھنٹہ ہے۔ اور منطقی ڈمپ سے گھومنے، اشاریہ جات کو رول کرنے وغیرہ میں ابھی بھی وقت لگتا ہے۔
لیکن وہ اس نقطہ نظر کو استعمال کرتے ہیں کیونکہ یہ انہیں مصنوعات کو قابل اعتماد رکھنے کی اجازت دیتا ہے۔
ہم یہاں کیا کر سکتے ہیں؟ آئیے ٹیسٹ بینچ سستے بنائیں اور ہر ڈویلپر کو ان کا اپنا ٹیسٹ بینچ دیں۔
اور یہ ممکن ہے۔
اور اس نقطہ نظر میں، جب ہم ہر ڈویلپر کے لیے پتلے کلون بناتے ہیں، تو ہم اسے ایک مشین پر شیئر کر سکتے ہیں۔ مثال کے طور پر، اگر آپ کے پاس 10TB ڈیٹا بیس ہے اور آپ اسے 10 ڈویلپرز کو دینا چاہتے ہیں، تو آپ کے پاس XNUMX x XNUMXTB ڈیٹا بیس ہونے کی ضرورت نہیں ہے۔ آپ کو ایک مشین استعمال کرنے والے ہر ڈویلپر کے لیے پتلی الگ تھلگ کاپیاں بنانے کے لیے صرف ایک مشین کی ضرورت ہے۔ میں آپ کو تھوڑی دیر بعد بتاؤں گا کہ یہ کیسے کام کرتا ہے۔
حقیقی مثال:
-
ڈی بی - 4,5 ٹیرا بائٹس۔
-
ہم 30 سیکنڈ میں آزاد کاپیاں حاصل کر سکتے ہیں۔
آپ کو ٹیسٹ اسٹینڈ کا انتظار کرنے کی ضرورت نہیں ہے اور اس پر انحصار کرنا ہوگا کہ یہ کتنا بڑا ہے۔ آپ اسے سیکنڈوں میں حاصل کر سکتے ہیں۔ یہ مکمل طور پر الگ تھلگ ماحول ہوگا، لیکن جو آپس میں ڈیٹا بانٹتے ہیں۔
یہ بہت اچھا ہے. یہاں ہم جادو اور ایک متوازی کائنات کے بارے میں بات کر رہے ہیں۔
ہمارے معاملے میں، یہ OpenZFS سسٹم کا استعمال کرتے ہوئے کام کرتا ہے۔
اوپن زیڈ ایف ایس ایک کاپی آن رائٹ فائل سسٹم ہے جو باکس سے باہر سنیپ شاٹس اور کلون کو سپورٹ کرتا ہے۔ یہ قابل اعتماد اور توسیع پذیر ہے۔ وہ انتظام کرنے میں بہت آسان ہے۔ اسے لفظی طور پر دو ٹیموں میں تعینات کیا جا سکتا ہے۔
اس کے علاوہ اور بھی اختیارات ہیں۔
-
LVM ،
-
ذخیرہ (مثال کے طور پر، خالص ذخیرہ)۔
میں جس ڈیٹا بیس لیب کی بات کر رہا ہوں وہ ماڈیولر ہے۔ ان اختیارات کا استعمال کرتے ہوئے لاگو کیا جا سکتا ہے. لیکن ابھی کے لیے، ہم نے OpenZFS پر توجہ مرکوز کی ہے، کیونکہ خاص طور پر LVM کے ساتھ مسائل تھے۔
یہ کیسے کام کرتا ہے؟ ہر بار جب ہم ڈیٹا کو تبدیل کرتے ہیں تو اسے اوور رائٹ کرنے کے بجائے، ہم اسے صرف یہ نشان زد کرکے محفوظ کرتے ہیں کہ یہ نیا ڈیٹا وقت کے ایک نئے نقطہ، ایک نئے اسنیپ شاٹ سے ہے۔
اور مستقبل میں، جب ہم رول بیک کرنا چاہتے ہیں یا ہم کسی پرانے ورژن سے نیا کلون بنانا چاہتے ہیں، تو ہم صرف یہ کہتے ہیں: "ٹھیک ہے، ہمیں ڈیٹا کے یہ بلاکس دیں جو اس طرح نشان زد ہیں۔"
اور یہ صارف ایسے ڈیٹا سیٹ کے ساتھ کام کرے گا۔ وہ دھیرے دھیرے ان کو تبدیل کرے گا، اپنے اسنیپ شاٹس بنائے گا۔
اور ہم برانچ کریں گے۔ ہمارے معاملے میں ہر ڈویلپر کو اپنا کلون رکھنے کا موقع ملے گا جس میں وہ ترمیم کرتا ہے، اور جو ڈیٹا شیئر کیا جائے گا وہ سب کے درمیان شیئر کیا جائے گا۔
گھر میں اس طرح کے نظام کو تعینات کرنے کے لئے، آپ کو دو مسائل کو حل کرنے کی ضرورت ہے:
-
پہلا ڈیٹا کا ذریعہ ہے، جہاں سے آپ اسے لیں گے۔ آپ پیداوار کے ساتھ نقل ترتیب دے سکتے ہیں۔ آپ پہلے سے ہی وہ بیک اپ استعمال کر سکتے ہیں جو آپ نے کنفیگر کیے ہیں، مجھے امید ہے۔ WAL-E، WAL-G یا برمن۔ اور یہاں تک کہ اگر آپ کسی قسم کا کلاؤڈ حل جیسے RDS یا Cloud SQL استعمال کر رہے ہیں، تب بھی آپ منطقی ڈمپ استعمال کر سکتے ہیں۔ لیکن ہم پھر بھی آپ کو بیک اپ استعمال کرنے کا مشورہ دیتے ہیں، کیونکہ اس نقطہ نظر سے آپ فائلوں کی جسمانی ساخت کو بھی برقرار رکھیں گے، جو آپ کو ان میٹرکس کے قریب تر ہونے کی اجازت دے گا جو آپ کو پروڈکشن میں نظر آئیں گے تاکہ وہ موجود مسائل کو پکڑ سکیں۔
-
دوسرا وہ جگہ ہے جہاں آپ ڈیٹا بیس لیب کی میزبانی کرنا چاہتے ہیں۔ یہ کلاؤڈ ہوسکتا ہے، یہ آن پریمیس ہوسکتا ہے۔ یہاں یہ بتانا ضروری ہے کہ ZFS ڈیٹا کمپریشن کو سپورٹ کرتا ہے۔ اور یہ بہت اچھی طرح سے کرتا ہے۔
تصور کریں کہ ایسے ہر کلون کے لیے، ان کارروائیوں پر منحصر ہے جو ہم بیس کے ساتھ کرتے ہیں، کسی نہ کسی قسم کی دیو بڑھے گی۔ اس کے لیے دیو کو بھی جگہ درکار ہوگی۔ لیکن اس حقیقت کی وجہ سے کہ ہم نے 4,5 ٹیرا بائٹس کی بنیاد لی ہے، ZFS اسے 3,5 ٹیرا بائٹس تک سکیڑ دے گا۔ یہ ترتیبات کے لحاظ سے مختلف ہو سکتا ہے۔ اور ہمارے پاس ابھی بھی دیو کی گنجائش ہے۔
اس طرح کا نظام مختلف معاملات کے لیے استعمال کیا جا سکتا ہے۔
-
یہ ڈویلپرز ہیں، استفسار کی توثیق کے لیے DBAs، اصلاح کے لیے۔
-
اس کا استعمال QA ٹیسٹنگ میں کسی خاص منتقلی کی جانچ کرنے کے لیے کیا جا سکتا ہے اس سے پہلے کہ ہم اسے پروڈکشن کے لیے رول آؤٹ کریں۔ اور ہم حقیقی ڈیٹا کے ساتھ QA کے لیے خصوصی ماحول بھی بڑھا سکتے ہیں، جہاں وہ نئی فعالیت کی جانچ کر سکتے ہیں۔ اور اس میں انتظار کے گھنٹوں کی بجائے سیکنڈ لگیں گے، اور شاید کچھ دوسرے معاملات میں دن لگیں گے جہاں پتلی کاپیاں استعمال نہیں کی جاتی ہیں۔
-
اور ایک اور کیس۔ اگر کمپنی کے پاس تجزیاتی نظام قائم نہیں ہے، تو ہم پروڈکٹ کی بنیاد کا ایک پتلا کلون الگ کر سکتے ہیں اور اسے طویل سوالات یا خصوصی اشاریہ جات کو دے سکتے ہیں جو تجزیات میں استعمال ہو سکتے ہیں۔
اس نقطہ نظر کے ساتھ:
-
"پروڈ" پر غلطیوں کا کم امکان، کیونکہ ہم نے فل سائز ڈیٹا پر تمام تبدیلیوں کا تجربہ کیا۔
-
ہمارے پاس جانچ کا کلچر ہے، کیونکہ اب آپ کو اپنے موقف کے لیے گھنٹوں انتظار نہیں کرنا پڑے گا۔
-
اور ٹیسٹوں کے درمیان کوئی رکاوٹ، کوئی انتظار نہیں ہے۔ آپ واقعی جا کر چیک کر سکتے ہیں۔ اور یہ اس طرح بہتر ہوگا جب ہم ترقی کو تیز کریں گے۔
-
کم ری فیکٹرنگ ہوگی۔ کم کیڑے پیداوار میں ختم ہوں گے۔ ہم بعد میں ان کو کم ری ایکٹر کریں گے۔
-
ہم ناقابل واپسی تبدیلیوں کو ریورس کر سکتے ہیں۔ یہ معیاری طریقہ نہیں ہے۔
- یہ فائدہ مند ہے کیونکہ ہم ٹیسٹ بینچوں کے وسائل بانٹتے ہیں۔
پہلے ہی اچھا ہے، لیکن اور کیا تیز ہو سکتا ہے؟
اس طرح کے نظام کی بدولت، ہم اس طرح کی جانچ میں داخل ہونے کی حد کو بہت کم کر سکتے ہیں۔
اب ایک شیطانی دائرہ ہے، جب ایک ڈویلپر کو، حقیقی پورے سائز کے ڈیٹا تک رسائی حاصل کرنے کے لیے، ایک ماہر بننا چاہیے۔ ایسی رسائی کے ساتھ اس پر بھروسہ کیا جانا چاہئے۔
لیکن اگر یہ نہ ہو تو کیسے بڑھیں؟ لیکن کیا ہوگا اگر آپ کے پاس ٹیسٹ ڈیٹا کا ایک بہت ہی چھوٹا سیٹ دستیاب ہو؟ تب آپ کو کوئی حقیقی تجربہ نہیں ملے گا۔
اس دائرے سے کیسے نکلیں؟ پہلے انٹرفیس کے طور پر، کسی بھی سطح کے ڈویلپرز کے لیے آسان، ہم نے سلیک بوٹ کا انتخاب کیا۔ لیکن یہ کوئی دوسرا انٹرفیس ہو سکتا ہے۔
یہ آپ کو کیا کرنے کی اجازت دیتا ہے؟ آپ ایک مخصوص سوال لے سکتے ہیں اور اسے ڈیٹا بیس کے لیے ایک خصوصی چینل پر بھیج سکتے ہیں۔ ہم سیکنڈوں میں خود بخود ایک پتلا کلون تعینات کر دیں گے۔ آئیے اس درخواست کو چلائیں۔ ہم میٹرکس اور سفارشات جمع کرتے ہیں۔ آئیے ایک تصور دکھائیں۔ اور پھر یہ کلون باقی رہے گا تاکہ اس استفسار کو کسی نہ کسی طرح آپٹمائز کیا جا سکے، انڈیکسز کا اضافہ کیا جا سکے۔
اور Slack ہمیں باکس سے باہر تعاون کے مواقع فراہم کرتا ہے۔ چونکہ یہ صرف ایک چینل ہے، اس لیے آپ اس درخواست پر تھریڈ میں ہی اس درخواست پر بحث شروع کر سکتے ہیں، اپنے ساتھیوں، DBAs کو پنگ کر سکتے ہیں جو کمپنی کے اندر ہیں۔
لیکن یقیناً مسائل ہیں۔ چونکہ یہ حقیقی دنیا ہے، اور ہم ایک سرور کا استعمال کر رہے ہیں جس میں ایک ساتھ کئی کلون ہوسٹ کیے جا رہے ہیں، ہمیں کلون کے لیے دستیاب میموری اور CPU پاور کی مقدار کو کمپریس کرنا ہوگا۔
لیکن ان ٹیسٹوں کے قابل فہم ہونے کے لیے، آپ کو کسی نہ کسی طرح اس مسئلے کو حل کرنے کی ضرورت ہے۔
یہ واضح ہے کہ اہم نکتہ وہی ڈیٹا ہے۔ لیکن ہمارے پاس پہلے ہی موجود ہے۔ اور ہم اسی ترتیب کو حاصل کرنا چاہتے ہیں۔ اور ہم ایسی تقریباً ایک جیسی ترتیب دے سکتے ہیں۔
پروڈکشن کی طرح ایک ہی ہارڈ ویئر کا ہونا اچھا ہوگا، لیکن یہ مختلف ہوسکتا ہے۔
آئیے یاد رکھیں کہ پوسٹگریس میموری کے ساتھ کیسے کام کرتا ہے۔ ہمارے پاس دو کیچز ہیں۔ ایک فائل سسٹم سے اور ایک مقامی پوسٹگریس، یعنی مشترکہ بفر کیشے۔
یہ نوٹ کرنا ضروری ہے کہ پوسٹگریس شروع ہونے پر شیئرڈ بفر کیشے مختص کیا جاتا ہے، اس بات پر منحصر ہے کہ آپ کنفیگریشن میں کس سائز کی وضاحت کرتے ہیں۔
اور دوسرا کیش تمام دستیاب جگہ استعمال کرتا ہے۔
اور جب ہم ایک مشین پر کئی کلون بناتے ہیں تو پتہ چلتا ہے کہ ہم آہستہ آہستہ میموری کو بھرتے ہیں۔ اور اچھے طریقے سے، شیئرڈ بفر کیش مشین پر دستیاب میموری کی کل مقدار کا 25 فیصد ہے۔
اور یہ پتہ چلتا ہے کہ اگر ہم اس پیرامیٹر کو تبدیل نہیں کرتے ہیں، تو ہم ایک مشین پر صرف 4 مثالیں چلا سکیں گے، یعنی ایسے تمام پتلے کلون میں سے 4۔ اور یہ، یقیناً، برا ہے، کیونکہ ہم ان میں سے بہت کچھ حاصل کرنا چاہتے ہیں۔
لیکن دوسری طرف، Buffer Cache کا استعمال اشاریہ جات کے لیے استفسارات کو انجام دینے کے لیے کیا جاتا ہے، یعنی منصوبہ اس بات پر منحصر ہے کہ ہمارے کیشز کتنے بڑے ہیں۔ اور اگر ہم صرف اس پیرامیٹر کو لیں اور اسے کم کردیں تو ہمارے منصوبے بہت بدل سکتے ہیں۔
مثال کے طور پر، اگر ہمارے پاس پروڈ پر ایک بڑا ذخیرہ ہے، تو پوسٹگریس انڈیکس استعمال کرنے کو ترجیح دے گی۔ اور اگر نہیں، تو SeqScan ہوگا۔ اور اگر ہمارے منصوبے موافق نہ ہوئے تو کیا فائدہ ہوگا؟
لیکن یہاں ہم اس نتیجے پر پہنچے ہیں کہ درحقیقت پوسٹگریس میں پلان کا انحصار پلان میں شیئرڈ بفر میں بیان کردہ مخصوص سائز پر نہیں ہے، یہ اثر_کیچ_سائز پر منحصر ہے۔
Effective_cache_size کیشے کی تخمینی مقدار ہے جو ہمارے لیے دستیاب ہے، یعنی بفر کیشے اور فائل سسٹم کیشے کا مجموعہ۔ یہ ترتیب کے ذریعہ ترتیب دیا گیا ہے۔ اور یہ میموری مختص نہیں ہے۔
اور اس پیرامیٹر کی وجہ سے، ہم پوسٹگریس کو یہ کہتے ہوئے چال چل سکتے ہیں کہ ہمارے پاس واقعی بہت زیادہ ڈیٹا دستیاب ہے، چاہے ہمارے پاس یہ ڈیٹا نہ ہو۔ اور اس طرح، منصوبے مکمل طور پر پیداوار کے ساتھ موافق ہوں گے۔
لیکن یہ وقت کو متاثر کر سکتا ہے۔ اور ہم سوالات کو وقت کے لحاظ سے بہتر بناتے ہیں، لیکن یہ ضروری ہے کہ وقت کا انحصار بہت سے عوامل پر ہو:
-
یہ اس بوجھ پر منحصر ہے جو فی الحال پروڈ پر ہے۔
-
یہ خود مشین کی خصوصیات پر منحصر ہے۔
اور یہ ایک بالواسطہ پیرامیٹر ہے، لیکن درحقیقت ہم اعداد و شمار کی مقدار سے بالکل درست کر سکتے ہیں جسے یہ استفسار نتیجہ حاصل کرنے کے لیے پڑھے گا۔
اور اگر آپ چاہتے ہیں کہ وقت اس کے قریب ہو جو ہم پروڈ میں دیکھیں گے، تو ہمیں سب سے ملتا جلتا ہارڈ ویئر لینے کی ضرورت ہے اور ممکنہ طور پر اس سے بھی زیادہ تاکہ تمام کلون فٹ ہوجائیں۔ لیکن یہ ایک سمجھوتہ ہے، یعنی آپ کو وہی پلانز ملیں گے، آپ دیکھیں گے کہ ایک خاص استفسار کتنا ڈیٹا پڑھے گا اور آپ یہ نتیجہ اخذ کر سکیں گے کہ آیا یہ استفسار اچھا ہے (یا منتقلی) یا برا، اسے ابھی بھی بہتر کرنے کی ضرورت ہے۔ .
آئیے اس پر ایک نظر ڈالیں کہ Joe کو خاص طور پر کس طرح بہتر بنایا گیا ہے۔
آئیے ایک حقیقی نظام سے ایک درخواست لیتے ہیں۔ اس صورت میں، ڈیٹا بیس 1 ٹیرا بائٹ ہے۔ اور ہم ان تازہ پوسٹس کی تعداد گننا چاہتے ہیں جن پر 10 سے زیادہ لائکس تھے۔
ہم چینل کو پیغام لکھ رہے ہیں، ہمارے لیے کلون تعینات کر دیا گیا ہے۔ اور ہم دیکھیں گے کہ ایسی درخواست 2,5 منٹ میں مکمل ہو جائے گی۔ یہ پہلی چیز ہے جو ہم نے محسوس کی ہے۔
B Joe آپ کو پلان اور میٹرکس کی بنیاد پر خودکار سفارشات دکھائے گا۔
ہم دیکھیں گے کہ سوال نسبتاً کم تعداد میں قطاریں حاصل کرنے کے لیے بہت زیادہ ڈیٹا پر کارروائی کرتا ہے۔ اور کسی قسم کے خصوصی انڈیکس کی ضرورت ہے، کیونکہ ہم نے دیکھا کہ استفسار میں بہت زیادہ فلٹر شدہ قطاریں ہیں۔
آئیے ایک باریک بینی سے دیکھتے ہیں کہ کیا ہوا۔ درحقیقت، ہم دیکھتے ہیں کہ ہم نے فائل کیش یا ڈسک سے تقریباً ڈیڑھ گیگا بائٹ ڈیٹا پڑھا ہے۔ اور یہ اچھا نہیں ہے، کیونکہ ہمیں صرف 142 لائنیں ملی ہیں۔
اور، ایسا لگتا ہے کہ، ہمارے پاس یہاں ایک انڈیکس اسکین ہے اور اسے جلدی سے کام کرنا چاہیے تھا، لیکن چونکہ ہم نے بہت ساری لائنیں فلٹر کیں (ہمیں ان کو گننا پڑا)، استفسار آہستہ آہستہ پورا ہوا۔
اور یہ پلان میں اس حقیقت کی وجہ سے ہوا کہ استفسار کی شرائط اور انڈیکس میں موجود حالات جزوی طور پر میل نہیں کھاتے ہیں۔
آئیے انڈیکس کو زیادہ درست بنانے کی کوشش کرتے ہیں اور دیکھتے ہیں کہ اس کے بعد استفسار پر عمل کیسے بدلتا ہے۔
انڈیکس کی تشکیل میں کافی وقت لگا، لیکن اب ہم استفسار کو چیک کرتے ہیں اور دیکھتے ہیں کہ وقت 2,5 منٹ کے بجائے صرف 156 ملی سیکنڈ ہے، جو کافی اچھا ہے۔ اور ہم صرف 6 میگا بائٹس ڈیٹا پڑھتے ہیں۔
اور اب ہم صرف انڈیکس اسکین استعمال کرتے ہیں۔
ایک اور اہم کہانی یہ ہے کہ ہم منصوبہ کو کچھ اور قابل فہم انداز میں پیش کرنا چاہتے ہیں۔ ہم نے فلیم گرافس کا استعمال کرتے ہوئے تصور کو نافذ کیا ہے۔
یہ ایک الگ درخواست ہے، زیادہ شدید۔ اور ہم دو پیرامیٹرز کے مطابق Flame Graphs بناتے ہیں: یہ ڈیٹا کی وہ مقدار ہے جسے ایک خاص نوڈ پلان اور ٹائمنگ میں شمار کرتا ہے، یعنی نوڈ کے نفاذ کا وقت۔
یہاں ہم ایک دوسرے کے ساتھ مخصوص نوڈس کا موازنہ کر سکتے ہیں۔ اور یہ واضح ہو جائے گا کہ ان میں سے کون کم یا زیادہ لیتا ہے، جو عام طور پر دوسرے رینڈرنگ طریقوں میں کرنا مشکل ہوتا ہے۔
یقینا، سب جانتے ہیں explain.depesz.com۔ اس تصور کی ایک اچھی خصوصیت یہ ہے کہ ہم ٹیکسٹ پلان کو محفوظ کرتے ہیں اور کچھ بنیادی پیرامیٹرز کو بھی ایک ٹیبل میں رکھتے ہیں تاکہ ہم ترتیب دے سکیں۔
اور ڈویلپرز جنہوں نے ابھی تک اس موضوع پر غور نہیں کیا ہے وہ بھی explain.depesz.com کا استعمال کرتے ہیں، کیونکہ ان کے لیے یہ جاننا آسان ہوتا ہے کہ کون سے میٹرکس اہم ہیں اور کون سے نہیں۔
تصور کے لیے ایک نیا طریقہ ہے - یہ ہے explain.dalibo.com۔ وہ درخت کا تصور کرتے ہیں، لیکن نوڈس کا ایک دوسرے سے موازنہ کرنا بہت مشکل ہے۔ یہاں آپ ساخت کو اچھی طرح سمجھ سکتے ہیں، تاہم، اگر کوئی بڑی درخواست ہے، تو آپ کو آگے پیچھے سکرول کرنا پڑے گا، بلکہ ایک آپشن بھی۔
اشتراک
اور، جیسا کہ میں نے کہا، سلیک ہمیں تعاون کرنے کا موقع فراہم کرتا ہے۔ مثال کے طور پر، اگر ہم ایک پیچیدہ سوال کا سامنا کرتے ہیں جو واضح نہیں ہے کہ کس طرح اصلاح کرنا ہے، تو ہم اس مسئلے کو اپنے ساتھیوں کے ساتھ سلیک میں ایک تھریڈ میں واضح کر سکتے ہیں۔
ہمیں لگتا ہے کہ پورے سائز کے ڈیٹا پر جانچنا ضروری ہے۔ ایسا کرنے کے لیے، ہم نے اپ ڈیٹ ڈیٹا بیس لیب ٹول بنایا، جو اوپن سورس میں دستیاب ہے۔ آپ جو بوٹ بھی استعمال کر سکتے ہیں۔ آپ اسے ابھی لے سکتے ہیں اور اسے اپنی جگہ پر نافذ کرسکتے ہیں۔ تمام رہنما وہاں دستیاب ہیں۔
یہ نوٹ کرنا بھی ضروری ہے کہ حل بذات خود انقلابی نہیں ہے، کیونکہ ڈیلفکس ہے، لیکن یہ ایک انٹرپرائز حل ہے۔ یہ مکمل طور پر بند ہے، یہ بہت مہنگا ہے۔ ہم خاص طور پر پوسٹگریس میں مہارت رکھتے ہیں۔ یہ سب اوپن سورس پروڈکٹس ہیں۔ ہمارے ساتھ شامل ہوں!
میں یہیں ختم کرتا ہوں۔ شکریہ!
آپ کے سوالات
ہیلو! رپورٹ کے لیے شکریہ! بہت دلچسپ، خاص طور پر میرے لیے، کیونکہ میں نے کچھ عرصہ قبل اسی مسئلے کو حل کیا تھا۔ اور اس طرح میرے پاس کئی سوالات ہیں۔ امید ہے کہ مجھے اس کا کم از کم حصہ مل جائے گا۔
میں حیران ہوں کہ آپ اس ماحول کے لیے جگہ کا حساب کیسے لگاتے ہیں؟ ٹیکنالوجی کا مطلب ہے کہ مخصوص حالات میں، آپ کے کلون زیادہ سے زیادہ سائز تک بڑھ سکتے ہیں۔ اگر آپ کے پاس دس ٹیرا بائٹ ڈیٹا بیس اور 10 کلون ہیں، تو اس صورت حال کی نقل کرنا آسان ہے جہاں ہر کلون کا وزن 10 منفرد ڈیٹا ہو۔ آپ اس جگہ کا حساب کیسے لگاتے ہیں، یعنی وہ ڈیلٹا جس کے بارے میں آپ نے بات کی، جس میں یہ کلون رہیں گے؟
اچھا سوال. یہاں مخصوص کلون پر نظر رکھنا ضروری ہے۔ اور اگر کسی کلون میں کچھ بہت بڑی تبدیلی ہوتی ہے، یہ بڑھنے لگتا ہے، تو ہم سب سے پہلے اس بارے میں صارف کو وارننگ جاری کر سکتے ہیں، یا اس کلون کو فوری طور پر روک سکتے ہیں تاکہ ہمیں فیل کی صورت حال نہ ہو۔
ہاں، میرے پاس ایک سوال ہے۔ یعنی، آپ ان ماڈیولز کے لائف سائیکل کو کیسے یقینی بناتے ہیں؟ ہمارے پاس یہ مسئلہ اور ایک پوری الگ کہانی ہے۔ یہ کیسے ہوتا ہے؟
ہر کلون کے لیے کچھ ٹی ٹی ایل ہے۔ بنیادی طور پر، ہمارے پاس ایک فکسڈ ٹی ٹی ایل ہے۔
راز نہیں تو کیا؟
1 گھنٹہ، یعنی بیکار - 1 گھنٹہ۔ اگر یہ استعمال نہیں کیا جاتا ہے، تو ہم اسے مارتے ہیں. لیکن یہاں کوئی تعجب کی بات نہیں ہے، کیونکہ ہم کلون کو سیکنڈوں میں بڑھا سکتے ہیں۔ اور اگر آپ کو دوبارہ اس کی ضرورت ہو تو براہ کرم۔
میں ٹیکنالوجیز کے انتخاب میں بھی دلچسپی رکھتا ہوں، کیونکہ، مثال کے طور پر، ہم متوازی طور پر کسی نہ کسی وجہ سے متعدد طریقے استعمال کرتے ہیں۔ ZFS کیوں؟ آپ نے LVM کیوں نہیں استعمال کیا؟ آپ نے بتایا کہ LVM کے ساتھ مسائل تھے۔ مسائل کیا تھے؟ میری رائے میں، کارکردگی کے لحاظ سے، سب سے زیادہ بہترین آپشن اسٹوریج کے ساتھ ہے۔
ZFS کے ساتھ بنیادی مسئلہ کیا ہے؟ حقیقت یہ ہے کہ آپ کو ایک ہی میزبان پر چلنا چاہیے، یعنی تمام مثالیں ایک ہی OS کے اندر رہیں گی۔ اور سٹوریج کی صورت میں، آپ مختلف آلات کو جوڑ سکتے ہیں۔ اور رکاوٹ صرف وہی بلاکس ہیں جو اسٹوریج سسٹم پر ہیں۔ اور ٹیکنالوجیز کے انتخاب کا سوال دلچسپ ہے۔ LVM کیوں نہیں؟
خاص طور پر، ہم ملاقات میں LVM پر بات کر سکتے ہیں۔ اسٹوریج کے بارے میں - یہ صرف مہنگا ہے۔ ہم ZFS سسٹم کو کہیں بھی نافذ کر سکتے ہیں۔ آپ اسے اپنی مشین پر لگا سکتے ہیں۔ آپ آسانی سے ذخیرہ کو ڈاؤن لوڈ کر سکتے ہیں اور اسے تعینات کر سکتے ہیں۔ اگر ہم لینکس کے بارے میں بات کر رہے ہیں تو ZFS تقریبا ہر جگہ انسٹال ہے۔ یعنی ہمیں ایک بہت ہی لچکدار حل ملتا ہے۔ اور ZFS خود بہت کچھ دیتا ہے۔ آپ جتنا چاہیں ڈیٹا اپ لوڈ کر سکتے ہیں، بڑی تعداد میں ڈسک کو جوڑ سکتے ہیں، اسنیپ شاٹس ہیں۔ اور، جیسا کہ میں نے کہا، اس کا انتظام کرنا آسان ہے۔ یعنی یہ استعمال کرنے میں بہت خوشگوار لگتا ہے۔ اس کا امتحان ہے، اس کی عمر کئی سال ہے۔ اس کی ایک بہت بڑی کمیونٹی ہے جو بڑھ رہی ہے۔ ZFS ایک بہت ہی قابل اعتماد حل ہے۔
نکولائی سموخوالوف: کیا میں مزید تبصرہ کر سکتا ہوں؟ میرا نام نکولے ہے، ہم اناتولی کے ساتھ مل کر کام کرتے ہیں۔ میں اتفاق کرتا ہوں کہ اسٹوریج بہت اچھا ہے۔ اور ہمارے کچھ صارفین کے پاس خالص اسٹوریج وغیرہ ہے۔
اناتولی نے صحیح طور پر نوٹ کیا کہ ہم ماڈیولریٹی پر مرکوز ہیں۔ اور مستقبل میں، آپ ایک انٹرفیس کو لاگو کرسکتے ہیں - ایک سنیپ شاٹ لیں، کلون بنائیں، کلون کو تباہ کریں۔ یہ سب آسان ہے۔ اور اسٹوریج ٹھنڈا ہے، اگر یہ ہے.
لیکن ZFS سب کے لیے دستیاب ہے۔ ڈیل فکس پہلے ہی کافی ہے، ان کے 300 کلائنٹس ہیں۔ ان میں سے، fortune 100 کے 50 کلائنٹس ہیں، یعنی ان کا مقصد NASA وغیرہ ہے۔ اب وقت آگیا ہے کہ ہر کسی کو یہ ٹیکنالوجی مل جائے۔ اور اسی وجہ سے ہمارے پاس ایک اوپن سورس کور ہے۔ ہمارے پاس انٹرفیس کا ایک حصہ ہے جو اوپن سورس نہیں ہے۔ یہ وہ پلیٹ فارم ہے جسے ہم دکھائیں گے۔ لیکن ہم چاہتے ہیں کہ یہ سب کے لیے قابل رسائی ہو۔ ہم ایک انقلاب لانا چاہتے ہیں تاکہ تمام ٹیسٹرز لیپ ٹاپ پر اندازہ لگانا چھوڑ دیں۔ ہمیں SELECT لکھنا ہے اور فوری طور پر دیکھیں کہ یہ سست ہے۔ اس کے بارے میں آپ کو بتانے کے لیے DBA کا انتظار کرنا چھوڑ دیں۔ یہاں بنیادی مقصد ہے. اور مجھے لگتا ہے کہ ہم سب اس تک پہنچیں گے۔ اور ہم اس چیز کو ہر ایک کے لیے بناتے ہیں۔ لہذا ZFS، کیونکہ یہ ہر جگہ دستیاب ہوگا۔ مسائل کو حل کرنے اور اوپن سورس لائسنس وغیرہ کے لیے کمیونٹی کا شکریہ*
سلام! رپورٹ کے لیے شکریہ! میرا نام میکسم ہے۔ ہم نے انہی مسائل سے نمٹا ہے۔ انہوں نے اپنے طور پر فیصلہ کیا۔ آپ ان کلون کے درمیان وسائل کیسے بانٹتے ہیں؟ ہر کلون کسی بھی وقت اپنا کام خود کر سکتا ہے: کوئی ایک چیز کی جانچ کرتا ہے، کوئی دوسرا، کوئی انڈیکس بناتا ہے، کسی کے پاس بھاری کام ہوتا ہے۔ اور اگر آپ اب بھی CPU سے تقسیم کر سکتے ہیں، تو IO کے ذریعے، آپ کیسے تقسیم کریں گے؟ یہ پہلا سوال ہے۔
اور دوسرا سوال اسٹینڈز کے تفاوت کے بارے میں ہے۔ ہم کہتے ہیں کہ میرے پاس یہاں ZFS ہے اور سب کچھ ٹھنڈا ہے، لیکن پروڈ پر کلائنٹ کے پاس ZFS نہیں ہے، بلکہ ext4، مثال کے طور پر۔ اس معاملے میں کیسے؟
سوالات بہت اچھے ہیں۔ میں نے اس مسئلے کا تھوڑا سا ذکر اس حقیقت کے ساتھ کیا کہ ہم وسائل کا اشتراک کرتے ہیں۔ اور اس کا حل یہ ہے۔ تصور کریں کہ آپ اسٹیجنگ پر جانچ کر رہے ہیں۔ آپ کی بھی ایسی حالت ہو سکتی ہے کہ کوئی ایک بوجھ دے، کوئی اور۔ اور اس کے نتیجے میں، آپ کو ناقابل فہم میٹرکس نظر آتے ہیں۔ یہاں تک کہ ایک ہی مسئلہ پروڈ کے ساتھ بھی ہوسکتا ہے۔ جب آپ کسی درخواست کو چیک کرنا چاہتے ہیں اور آپ دیکھتے ہیں کہ اس میں کچھ مسئلہ ہے - یہ آہستہ آہستہ کام کرتا ہے، تو درحقیقت مسئلہ درخواست میں نہیں تھا، بلکہ حقیقت میں یہ تھا کہ کچھ متوازی بوجھ ہے۔
اور اس لیے، یہاں اس بات پر توجہ مرکوز کرنا ضروری ہے کہ پلان کیا ہوگا، ہم پلان میں کیا اقدامات کریں گے اور اس کے لیے ہم کتنا ڈیٹا اکٹھا کریں گے۔ حقیقت یہ ہے کہ ہماری ڈسکیں، مثال کے طور پر، کسی چیز سے بھری ہوں گی، یہ خاص طور پر وقت کو متاثر کرے گی۔ لیکن ہم ڈیٹا کی مقدار سے اندازہ لگا سکتے ہیں کہ یہ درخواست کتنی بھری ہوئی ہے۔ یہ اتنا اہم نہیں ہے کہ ایک ہی وقت میں کسی قسم کی پھانسی ہوگی۔
میرے دو سوال ہیں۔ یہ بہت ٹھنڈی چیز ہے۔ کیا ایسے معاملات ہوئے ہیں جہاں پروڈکشن ڈیٹا اہم ہے، جیسے کریڈٹ کارڈ نمبر؟ کیا پہلے سے کچھ تیار ہے یا یہ ایک الگ کام ہے؟ اور دوسرا سوال - کیا MySQL کے لیے ایسا کچھ ہے؟
ڈیٹا کے بارے میں۔ جب تک ہم ایسا نہیں کرتے تب تک ہم مبہم کرتے رہیں گے۔ لیکن اگر آپ بالکل جو کو تعینات کرتے ہیں، اگر آپ ڈویلپرز تک رسائی نہیں دیتے ہیں، تو ڈیٹا تک رسائی نہیں ہوگی۔ کیوں؟ کیونکہ جو ڈیٹا نہیں دکھاتا ہے۔ یہ صرف میٹرکس، منصوبے دکھاتا ہے اور بس۔ یہ جان بوجھ کر کیا گیا تھا، کیونکہ یہ ہمارے مؤکل کی ضروریات میں سے ایک ہے۔ وہ سب کو رسائی دیے بغیر اصلاح کرنے کے قابل ہونا چاہتے تھے۔
MySQL کے بارے میں۔ یہ سسٹم کسی بھی چیز کے لیے استعمال کیا جا سکتا ہے جو ڈسک پر اسٹیٹ کو اسٹور کرتا ہے۔ اور چونکہ ہم پوسٹگریس کر رہے ہیں، اب ہم پوسٹگریس کے لیے پہلے تمام آٹومیشن کر رہے ہیں۔ ہم بیک اپ سے ڈیٹا حاصل کرنا خودکار بنانا چاہتے ہیں۔ ہم پوسٹگریس کو صحیح طریقے سے ترتیب دے رہے ہیں۔ ہم جانتے ہیں کہ پلانز کو کیسے میچ کرنا ہے، وغیرہ۔
لیکن چونکہ سسٹم قابل توسیع ہے، اس لیے اسے MySQL کے لیے بھی استعمال کیا جا سکتا ہے۔ اور ایسی مثالیں موجود ہیں۔ Yandex کے پاس بھی ایسی ہی چیز ہے، لیکن وہ اسے کہیں شائع نہیں کرتے ہیں۔ وہ اسے Yandex.Metrica کے اندر استعمال کرتے ہیں۔ اور MySQL کے بارے میں صرف ایک کہانی ہے۔ لیکن ٹیکنالوجیز وہی ہیں، ZFS.
رپورٹ کے لیے شکریہ! میرے بھی ایک دو سوالات ہیں۔ آپ نے بتایا کہ کلوننگ کو تجزیات کے لیے استعمال کیا جا سکتا ہے، مثال کے طور پر وہاں اضافی اشاریہ جات بنانے کے لیے۔ کیا آپ کچھ اور بتا سکتے ہیں کہ یہ کیسے کام کرتا ہے؟
اور میں فوری طور پر دوسرا سوال اسٹینڈز کی مماثلت، منصوبوں کی مماثلت کے بارے میں پوچھوں گا۔ منصوبہ پوسٹگریس کے جمع کردہ اعدادوشمار پر بھی منحصر ہے۔ آپ اس مسئلے کو کیسے حل کرتے ہیں؟
تجزیات کے مطابق، کوئی خاص کیس نہیں ہیں، کیونکہ ہم نے ابھی تک اسے استعمال نہیں کیا ہے، لیکن ایسا موقع موجود ہے۔ اگر ہم اشاریہ جات کے بارے میں بات کر رہے ہیں، تو تصور کریں کہ ایک سوال لاکھوں ریکارڈز اور ایک کالم کے ساتھ ٹیبل کا پیچھا کر رہا ہے جو عام طور پر پروڈ میں انڈیکس نہیں ہوتا ہے۔ اور ہم وہاں کچھ ڈیٹا کا حساب لگانا چاہتے ہیں۔ اگر یہ درخواست پروڈ کو بھیجی جاتی ہے، تو اس بات کا امکان ہے کہ یہ پروڈ پر سادہ ہو، کیونکہ درخواست پر ایک منٹ تک کارروائی کی جائے گی۔
ٹھیک ہے، آئیے ایک پتلا کلون بناتے ہیں جو چند منٹ کے لیے رکنا خوفناک نہیں ہے۔ اور تجزیات کو پڑھنے میں مزید آرام دہ بنانے کے لیے، ہم ان کالموں کے لیے اشاریے شامل کریں گے جن میں ہمیں ڈیٹا میں دلچسپی ہے۔
انڈیکس ہر بار بنایا جائے گا؟
آپ اسے بنا سکتے ہیں تاکہ ہم ڈیٹا کو ٹچ کریں، اسنیپ شاٹس بنائیں، پھر ہم اس سنیپ شاٹ سے بازیافت کریں گے اور نئی درخواستیں چلائیں گے۔ یعنی، آپ اسے بنا سکتے ہیں تاکہ آپ پہلے سے چسپاں انڈیکس کے ساتھ نئے کلون اٹھا سکیں۔
جہاں تک شماریات کے بارے میں سوال ہے، اگر ہم بیک اپ سے بحال کرتے ہیں، اگر ہم نقل کرتے ہیں، تو ہمارے اعدادوشمار بالکل ایک جیسے ہوں گے۔ کیونکہ ہمارے پاس مکمل فزیکل ڈیٹا سٹرکچر ہے، یعنی ہم ڈیٹا کو لائیں گے جیسا کہ تمام شماریات میٹرکس کے ساتھ بھی ہے۔
یہاں ایک اور مسئلہ ہے۔ اگر آپ کلاؤڈ حل استعمال کرتے ہیں، تو وہاں صرف منطقی ڈمپ دستیاب ہوتے ہیں، کیونکہ گوگل، ایمیزون آپ کو فزیکل کاپی لینے کی اجازت نہیں دیتے۔ کوئی مسئلہ ہو گا۔
رپورٹ کے لیے شکریہ۔ MySQL اور وسائل کے اشتراک کے بارے میں یہاں دو اچھے سوالات تھے۔ لیکن، حقیقت میں، یہ سب کچھ اس حقیقت پر آتا ہے کہ یہ مخصوص DBMS کا موضوع نہیں ہے، بلکہ مجموعی طور پر فائل سسٹم کا ہے۔ اور، اس کے مطابق، وسائل کی تقسیم کے مسائل کو بھی وہیں سے حل کیا جانا چاہیے، آخر میں یہ نہیں کہ یہ Postgres ہے، بلکہ فائل سسٹم میں، سرور میں، مثال کے طور پر۔
میرا سوال تھوڑا مختلف ہے۔ یہ کثیر پرتوں والے ڈیٹا بیس کے قریب ہے، جہاں کئی پرتیں ہیں۔ مثال کے طور پر، ہم نے دس ٹیرا بائٹ امیج اپ ڈیٹ ترتیب دیا ہے، ہم نقل کر رہے ہیں۔ اور ہم خاص طور پر اس حل کو ڈیٹا بیس کے لیے استعمال کرتے ہیں۔ نقل جاری ہے، ڈیٹا کو اپ ڈیٹ کیا جا رہا ہے۔ یہاں 100 ملازمین متوازی طور پر کام کر رہے ہیں، جو مسلسل یہ مختلف شاٹس شروع کر رہے ہیں۔ کیا کرنا ہے؟ اس بات کو کیسے یقینی بنایا جائے کہ کوئی تنازعہ نہ ہو، کہ انہوں نے ایک لانچ کیا، اور پھر فائل سسٹم بدل گیا، اور یہ تصویریں سب چلی گئیں؟
وہ نہیں جائیں گے کیونکہ ZFS اسی طرح کام کرتا ہے۔ ہم فائل سسٹم کی تبدیلیوں کو الگ سے ایک تھریڈ میں رکھ سکتے ہیں جو نقل کی وجہ سے آتی ہیں۔ اور وہ کلون رکھیں جو ڈیولپرز ڈیٹا کے پرانے ورژنز پر استعمال کرتے ہیں۔ اور یہ ہمارے لیے کام کرتا ہے، سب کچھ اس کے مطابق ہے۔
یہ پتہ چلتا ہے کہ اپ ڈیٹ ایک اضافی پرت کے طور پر ہوگی، اور اس پرت کی بنیاد پر تمام نئی تصاویر پہلے ہی چلی جائیں گی، ٹھیک ہے؟
پچھلی پرتوں سے جو پچھلی نقلوں سے تھیں۔
پچھلی پرتیں گر جائیں گی، لیکن وہ پرانی پرت کا حوالہ دیں گے، اور کیا وہ آخری پرت سے نئی تصاویر لیں گے جو اپ ڈیٹ میں موصول ہوئی تھی؟
عام طور پر، ہاں۔
پھر اس کے نتیجے میں ہمارے پاس تہوں کی ایک انجیر تک ہوگی۔ اور وقت گزرنے کے ساتھ ساتھ انہیں کمپریس کرنا پڑے گا؟
ہاں سب کچھ درست ہے۔ کچھ کھڑکی ہے۔ ہم ہفتہ وار سنیپ شاٹس رکھتے ہیں۔ یہ اس بات پر منحصر ہے کہ آپ کے پاس کون سا وسیلہ ہے۔ اگر آپ کے پاس بہت زیادہ ڈیٹا ذخیرہ کرنے کی صلاحیت ہے، تو آپ اسنیپ شاٹس کو طویل عرصے تک محفوظ کر سکتے ہیں۔ وہ خود نہیں جائیں گے۔ ڈیٹا کرپٹ نہیں ہوگا۔ اگر سنیپ شاٹس پرانے ہیں، جیسا کہ ہمیں لگتا ہے، یعنی یہ کمپنی کی پالیسی پر منحصر ہے، تو ہم انہیں آسانی سے حذف کر سکتے ہیں اور جگہ خالی کر سکتے ہیں۔
ہیلو، رپورٹ کے لئے شکریہ! جو کے بارے میں سوال۔ آپ نے کہا کہ صارف ہر کسی کو ڈیٹا تک رسائی نہیں دینا چاہتا تھا۔ سخت الفاظ میں، اگر کسی شخص کے پاس Explain Analyze کا نتیجہ ہے، تو وہ ڈیٹا کو جھانک سکتا ہے۔
ایسا ہی ہے۔ مثال کے طور پر، ہم لکھ سکتے ہیں: "SELECT FROM WHERE email = to that"۔ یعنی، ہم ڈیٹا کو خود نہیں دیکھیں گے، لیکن ہم کچھ بالواسطہ نشانیاں دیکھ سکتے ہیں۔ یہ سمجھنا چاہیے۔ لیکن دوسری طرف، یہ سب کچھ موجود ہے۔ ہمارے پاس لاگ آڈٹ ہے، ہمارے پاس دوسرے ساتھیوں کا کنٹرول ہے جو یہ بھی دیکھتے ہیں کہ ڈویلپر کیا کر رہے ہیں۔ اور اگر کوئی ایسا کرنے کی کوشش کرتا ہے تو سیکیورٹی سروس ان کے پاس آئے گی اور اس معاملے پر کام کرے گی۔
صبح بخیر رپورٹ کے لیے شکریہ! میرا ایک مختصر سوال ہے۔ اگر کمپنی سلیک کا استعمال نہیں کرتی ہے، کیا اب اس کا کوئی پابند ہے، یا کیا ڈویلپرز کے لیے ٹیسٹ ایپلیکیشن کو ڈیٹا بیس سے منسلک کرنے کے لیے مثالیں تعینات کرنا ممکن ہے؟
اب سلیک کا ایک لنک ہے، یعنی کوئی دوسرا میسنجر نہیں ہے، لیکن میں واقعی میں دوسرے میسنجر کے لیے بھی سپورٹ کرنا چاہتا ہوں۔ تم کیا کر سکتے ہو؟ آپ Joe کے بغیر DB Lab کو تعینات کر سکتے ہیں، REST API کی مدد سے یا ہمارے پلیٹ فارم کی مدد سے کلون بنا سکتے ہیں اور PSQL سے جڑ سکتے ہیں۔ لیکن اگر آپ اپنے ڈویلپرز کو ڈیٹا تک رسائی دینے کے لیے تیار ہیں تو یہ کیا جا سکتا ہے، کیونکہ اب کوئی اسکرین نہیں ہوگی۔
مجھے اس پرت کی ضرورت نہیں ہے، لیکن مجھے ایسے موقع کی ضرورت ہے۔
پھر ہاں، یہ کیا جا سکتا ہے۔
ماخذ: www.habr.com