هڪ پس منظر ڊولپر ڪيئن سمجهي ٿو ته هڪ SQL سوال "پروڊ" تي سٺو ڪم ڪندو؟ وڏن يا تيزيء سان وڌندڙ ڪمپنين ۾، هر ڪنهن کي "پراڊڪٽ" تائين رسائي ناهي. ۽ رسائي سان، سڀئي درخواستون بي درديءَ سان جانچي سگھجن ٿيون، ۽ ڊيٽابيس جي ڪاپي ٺاهڻ ۾ اڪثر ڪلاڪ لڳن ٿا. انهن مسئلن کي حل ڪرڻ لاء، اسان هڪ مصنوعي DBA ٺاهيو - جو. اهو اڳ ۾ ئي ڪيترن ئي ڪمپنين ۾ ڪاميابي سان لاڳو ڪيو ويو آهي ۽ هڪ درجن کان وڌيڪ ڊولپرز جي مدد ڪري ٿو.
وڊيو:
هيلو سڀ! منهنجو نالو Anatoly Stansler آهي. مان هڪ ڪمپني لاءِ ڪم ڪريان ٿو . اسان ڊولپرز، DBAs ۽ QAs کان Postgres جي ڪم سان لاڳاپيل دير کي ختم ڪندي ترقي جي عمل کي تيز ڪرڻ لاء پرعزم آهيون.
اسان وٽ عظيم گراهڪ آهن ۽ ا today رپورٽ جو حصو انهن ڪيسن لاءِ وقف ڪيو ويندو جيڪي اسان انهن سان ڪم ڪرڻ دوران مليا هئا. مان ان بابت ڳالهائيندس ته ڪيئن اسان انهن کي ڪافي سنجيده مسئلا حل ڪرڻ ۾ مدد ڪئي.
جڏهن اسان ترقي ڪري رهيا آهيون ۽ پيچيده تيز لوڊ لڏپلاڻ ڪري رهيا آهيون، اسان پاڻ کان سوال پڇون ٿا: "ڇا هي لڏپلاڻ ختم ٿي ويندي؟" اسان جائزو استعمال ڪندا آهيون، اسان وڌيڪ تجربيڪار ساٿين جي ڄاڻ استعمال ڪندا آهيون، ڊي بي اي ماهر. ۽ اهي چئي سگهن ٿا ته اهو پرواز ڪندو يا نه.
پر شايد اھو بھتر ھوندو جيڪڏھن اسان پاڻ ان کي پوري سائيز جي نقلن تي آزمائي سگھون. ۽ اڄ اسان صرف ان بابت ڳالهائينداسين ته جاچ جا ڪهڙا طريقا آهن ۽ اهو ڪيئن بهتر ٿي سگهي ٿو ۽ ڪهڙن اوزارن سان. اسان اهڙن طريقن جي فائدن ۽ نقصانن بابت پڻ ڳالهائينداسين، ۽ اسان هتي ڇا ڪري سگهون ٿا.
ڪنهن ڪڏهن انڊيڪسس سڌو سنئون پروڊ تي ٺاهيو آهي يا ڪا تبديلي ڪئي آهي؟ ڪافي ٿورڙو. ۽ ڪنهن جي لاءِ اها حقيقت اها آهي ته ڊيٽا گم ٿي وئي هئي يا دير ٿي وئي هئي؟ پوءِ تون هن درد کي سڃاڻين. خدا جو شڪر آهي ته بيڪ اپ آهن.
پهريون طريقو پروڊ ۾ جاچ آهي. يا، جڏهن هڪ ڊولپر مقامي مشين تي ويٺو آهي، هن وٽ ٽيسٽ ڊيٽا آهي، اتي ڪجهه قسم جي محدود چونڊ آهي. ۽ اسان پروڊڪٽ لاءِ ٻاهر نڪتاسين ، ۽ اسان کي اها صورتحال ملي ٿي.
اهو درد آهي، اهو قيمتي آهي. اهو شايد بهترين نه آهي.
۽ اهو ڪرڻ جو بهترين طريقو ڇا آهي؟
اچو ته اسٽيجنگ وٺون ۽ اتي پروڊ جو ڪجھ حصو چونڊيو. يا بهترين طور تي، اچو ته هڪ حقيقي پيداوار وٺو، سڀ ڊيٽا. ۽ اسان ان کي مقامي طور تي ترقي ڪرڻ کان پوء، اسان اضافي طور تي اسٽيجنگ لاء چيڪ ڪنداسين.
اهو اسان کي ڪجهه غلطين کي هٽائڻ جي اجازت ڏيندو، يعني انهن کي پروڊڪٽ تي ٿيڻ کان روڪيو.
مسئلا ڪهڙا آهن؟
- مسئلو اهو آهي ته اسان هن اسٽيجنگ کي ڀائيوارن سان حصيداري ڪندا آهيون. ۽ گهڻو ڪري اهو ٿئي ٿو ته توهان ڪنهن قسم جي تبديلي آڻيندا آهيو، بام - ۽ ڪو به ڊيٽا ناهي، ڪم ختم ٿي ويو آهي. اسٽيجنگ ملٽي ٽيرا بائيٽ هئي. ۽ ان کي ٻيهر اڀرڻ لاءِ توهان کي ڊگهو انتظار ڪرڻو پوندو. ۽ اسان سڀاڻي ان کي حتمي شڪل ڏيڻ جو فيصلو ڪيو. اھو اھو آھي، اسان وٽ ھڪڙو ترقي آھي.
- ۽، يقينا، اسان وٽ ڪيترائي ساٿي ڪم ڪري رهيا آهن، ڪيتريون ئي ٽيمون. ۽ اهو دستي طور تي ڪيو وڃي. ۽ اهو ناگزير آهي.
۽ اهو چوڻ جي قابل آهي ته اسان وٽ صرف هڪ ڪوشش آهي، هڪ شاٽ، جيڪڏهن اسان ڊيٽابيس ۾ ڪجهه تبديليون ڪرڻ چاهيون ٿا، ڊيٽا کي ڇڪيو، ساخت کي تبديل ڪريو. ۽ جيڪڏهن ڪجهه غلط ٿي ويو آهي، جيڪڏهن لڏپلاڻ ۾ ڪا غلطي هئي، ته پوء اسان جلدي واپس نه ڪنداسين.
اهو اڳئين طريقي کان بهتر آهي، پر اڃا به هڪ اعلي امڪان آهي ته ڪجهه قسم جي غلطي پيداوار ڏانهن ويندي.
ڇا اسان کي هر ڊولپر کي ٽيسٽ بينچ ڏيڻ کان روڪي ٿو، هڪ مڪمل سائيز ڪاپي؟ مان سمجهان ٿو ته اهو واضح آهي ته رستي ۾ ڇا ٿيندو.
ڪنهن وٽ ڊيٽابيس کان وڏو ٽيرا بائيٽ آهي؟ اڌ کان وڌيڪ ڪمرو.
۽ اهو واضح آهي ته هر ڊولپر لاءِ مشينون رکڻ، جڏهن اهڙي وڏي پيداوار آهي، تمام مهانگو آهي، ۽ ان کان علاوه، اهو هڪ ڊگهو وقت وٺندو آهي.
اسان وٽ ڪلائنٽ آهن جن اهو محسوس ڪيو آهي ته اهو تمام ضروري آهي ته سڀني تبديلين کي مڪمل سائيز ڪاپين تي جانچڻ، پر انهن جو ڊيٽابيس هڪ ٽيرا بائيٽ کان گهٽ آهي، ۽ هر ڊولپر لاءِ ٽيسٽ بينچ رکڻ لاءِ ڪي وسيلا نه آهن. تنهن ڪري، انهن کي ڊمپ کي مقامي طور تي پنهنجي مشين تي ڊائون لوڊ ڪرڻو پوندو ۽ هن طريقي سان ٽيسٽ ڪيو. اهو گهڻو وقت وٺندو آهي.
جيتوڻيڪ جيڪڏهن توهان ان کي انفراسٽرڪچر جي اندر ڪريو ٿا، ته پوءِ في ڪلاڪ هڪ ٽيرابائيٽ ڊيٽا ڊائون لوڊ ڪرڻ تمام سٺو آهي. پر اھي منطقي ڊمپ استعمال ڪندا آھن، اھي بادل کان مقامي طور تي ڊائون لوڊ ڪندا آھن. انهن لاء، رفتار تقريبا 200 گيگا بائيٽ في ڪلاڪ آهي. ۽ اهو اڃا تائين وقت وٺندو آهي منطقي ڊمپ مان ڦري وڃڻ، انڊيڪس کي رول ڪرڻ، وغيره.
پر اهي هن طريقي کي استعمال ڪن ٿا ڇاڪاڻ ته اها انهن کي اجازت ڏئي ٿي ته پروڊ قابل اعتماد.
اسان هتي ڇا ڪري سگهون ٿا؟ اچو ته ٽيسٽ بينچ کي سستو بڻايون ۽ هر ڊولپر کي پنهنجي ٽيسٽ بينچ ڏيون.
۽ اهو ممڪن آهي.
۽ هن طريقي ۾، جڏهن اسان هر ڊولپر لاء پتلي کلون ٺاهيندا آهيون، اسان ان کي هڪ مشين تي حصيداري ڪري سگهون ٿا. مثال طور، جيڪڏهن توهان وٽ 10TB ڊيٽابيس آهي ۽ توهان ان کي 10 ڊولپرز کي ڏيڻ چاهيو ٿا، توهان کي XNUMX x XNUMXTB ڊيٽابيس جي ضرورت ناهي. توهان کي صرف هڪ مشين جي ضرورت آهي پتلي الڳ ٿيل ڪاپيون ٺاهڻ لاءِ هر ڊولپر لاءِ هڪ مشين استعمال ڪندي. مان توهان کي ٻڌايان ٿو ته اهو ڪيئن ڪم ڪري ٿو ٿوري دير کان پوء.
حقيقي مثال:
-
ڊي بي - 4,5 ٽيرا بائيٽ.
-
اسان 30 سيڪنڊن ۾ آزاد ڪاپيون حاصل ڪري سگهون ٿا.
توهان کي ٽيسٽ اسٽينڊ جو انتظار ڪرڻ جي ضرورت ناهي ۽ ان تي منحصر آهي ته اهو ڪيترو وڏو آهي. توهان ان کي سيڪنڊن ۾ حاصل ڪري سگهو ٿا. اهو مڪمل طور تي الڳ ٿيل ماحول هوندو، پر جيڪي پاڻ ۾ ڊيٽا حصيداري ڪندا آهن.
هي عظيم آهي. هتي اسان جادو ۽ هڪ متوازي ڪائنات بابت ڳالهائي رهيا آهيون.
اسان جي حالت ۾، اهو ڪم ڪري ٿو OpenZFS سسٽم استعمال ڪندي.
OpenZFS هڪ ڪاپي-آن-لکڻ وارو فائل سسٽم آهي جيڪو سنيپ شاٽ ۽ دٻي مان کلون کي سپورٽ ڪري ٿو. اهو قابل اعتماد ۽ اسپيبلبل آهي. هوء منظم ڪرڻ بلڪل آسان آهي. اهو لفظي طور تي ٻن ٽيمن ۾ ترتيب ڏئي سگهجي ٿو.
ٻيا اختيار آھن:
-
ايل وي ايم ،
-
اسٽوريج (مثال طور، خالص اسٽوريج).
ڊيٽابيس جي ليب جنهن بابت مان ڳالهائي رهيو آهيان ماڊلر آهي. انهن اختيارن کي استعمال ڪندي لاڳو ڪري سگهجي ٿو. پر هينئر تائين، اسان OpenZFS تي ڌيان ڏنو آهي، ڇاڪاڻ ته خاص طور تي LVM سان مسئلا هئا.
اهو ڪيئن ڪم ڪري ٿو؟ هر دفعي ڊيٽا کي اوور رائٽ ڪرڻ بجاءِ جڏهن اسان ان کي تبديل ڪندا آهيون، اسان ان کي محفوظ ڪريون ٿا صرف نشان لڳڻ سان ته هي نئون ڊيٽا وقت جي هڪ نئين نقطي کان آهي، هڪ نئون سنيپ شاٽ.
۽ مستقبل ۾، جڏهن اسان رول بيڪ ڪرڻ چاهيون ٿا يا اسان چاهيون ٿا ته ڪجهه پراڻن ورزن مان هڪ نئون کلون، اسان صرف چوندا آهيون: "ٺيڪ، اسان کي ڊيٽا جا اهي بلاڪ ڏيو جيڪي هن طرح نشان لڳل آهن."
۽ هي صارف اهڙي ڊيٽا سيٽ سان ڪم ڪندو. هو آهستي آهستي انهن کي تبديل ڪندو، پنهنجون تصويرون ٺاهيندو.
۽ اسان شاخ ڪنداسين. اسان جي ڪيس ۾ هر ڊولپر کي موقعو هوندو ته هو پنهنجو ڪلون رکي جنهن کي هو ايڊٽ ڪري ٿو، ۽ جيڪا ڊيٽا شيئر ڪئي ويندي اها هر ڪنهن جي وچ ۾ شيئر ڪئي ويندي.
گهر ۾ اهڙي سسٽم کي ترتيب ڏيڻ لاء، توهان کي ٻه مسئلا حل ڪرڻ جي ضرورت آهي:
-
پهرين ڊيٽا جو ذريعو آهي، جتي توهان ان کي وٺي ويندا. توهان پيداوار سان نقل قائم ڪري سگهو ٿا. توھان اڳ ۾ ئي استعمال ڪري سگھو ٿا بيڪ اپ جيڪي توھان ترتيب ڏنو آھي، مون کي اميد آھي. وال-اي، وال-جي يا برمن. ۽ جيتوڻيڪ جيڪڏهن توهان استعمال ڪري رهيا آهيو ڪنهن قسم جو Cloud حل جهڙوڪ RDS يا Cloud SQL، پوء توهان استعمال ڪري سگهو ٿا منطقي ڊمپ. پر اسان اڃا به توهان کي مشورو ڏيون ٿا ته بيڪ اپ استعمال ڪريو، ڇاڪاڻ ته هن طريقي سان توهان فائلن جي جسماني ساخت کي پڻ برقرار رکندي، جيڪا توهان کي انهن ميٽرڪس جي ويجھو ٿيڻ جي اجازت ڏيندو جيڪا توهان انهن مسئلن کي پڪڙڻ لاء پيداوار ۾ ڏسندا.
-
ٻيو آهي جتي توهان ميزباني ڪرڻ چاهيو ٿا ڊيٽابيس ليب. اهو ڪلائوڊ ٿي سگهي ٿو، اهو آن پريم ٿي سگهي ٿو. هتي اهو چوڻ ضروري آهي ته ZFS ڊيٽا کمپريشن کي سپورٽ ڪري ٿو. ۽ اهو تمام سٺو ڪري ٿو.
تصور ڪريو ته هر هڪ اهڙي ڪلون لاءِ، انهن عملن تي منحصر آهي جيڪي اسان بنياد سان ڪندا آهيون، ڪجهه قسم جو ديو وڌندو. ان لاءِ، ديو کي به جاءِ جي ضرورت پوندي. پر ان حقيقت جي ڪري ته اسان 4,5 ٽيرا بائيٽ جو بنياد ورتو، ZFS ان کي 3,5 ٽيرا بائيٽ تائين دٻائي ڇڏيندو. اهو سيٽنگن جي لحاظ کان مختلف ٿي سگهي ٿو. ۽ اسان وٽ اڃا تائين ديو لاء ڪمرو آهي.
اهڙي نظام کي مختلف ڪيسن ۾ استعمال ڪري سگهجي ٿو.
-
اھي ڊولپر آھن، ڊي بي ايز سوالن جي تصديق لاءِ، اصلاح لاءِ.
-
اهو استعمال ڪري سگهجي ٿو QA ٽيسٽنگ ۾ ڪنهن خاص لڏپلاڻ کي جانچڻ لاءِ ان کان اڳ جو اسان ان کي پروڊ ڏانهن رول آئوٽ ڪريون. ۽ اسان حقيقي ڊيٽا سان QA لاءِ خاص ماحول پڻ وڌائي سگهون ٿا، جتي اهي نئين ڪارڪردگي کي جانچي سگهن ٿا. ۽ اهو انتظار جي ڪلاڪن جي بدران سيڪنڊ وٺندو، ۽ شايد ڪجهه ٻين ڪيسن ۾ ڏينهن جتي پتلي ڪاپيون استعمال نه ڪيون وينديون آهن.
-
۽ ٻيو ڪيس. جيڪڏهن ڪمپني وٽ اينالائيٽڪس سسٽم سيٽ اپ نه آهي، ته پوءِ اسان پراڊڪٽ بيس جي هڪ پتلي ڪلون کي الڳ ڪري سگھون ٿا ۽ ان کي ڊگھي سوالن يا خاص انڊيڪسز کي ڏئي سگھون ٿا جيڪي اينالائيٽڪس ۾ استعمال ڪري سگھجن ٿيون.
هن طريقي سان:
-
"پروڊ" تي غلطين جو گھٽ امڪان، ڇاڪاڻ ته اسان مڪمل سائيز ڊيٽا تي سڀني تبديلين کي آزمايو.
-
اسان وٽ جاچ جو ڪلچر آهي، ڇو ته هاڻي توهان کي پنهنجي اسٽينڊ لاءِ ڪلاڪن جا ڪلاڪ انتظار ڪرڻ جي ضرورت ناهي.
-
۽ ڪابه رڪاوٽ ناهي، ٽيسٽ جي وچ ۾ ڪوبه انتظار ناهي. توهان اصل ۾ وڃو ۽ چيڪ ڪري سگهو ٿا. ۽ اهو بهتر ٿيندو ته جيئن اسان ترقي کي تيز ڪنداسين.
-
اتي گهٽ refactoring ٿيندو. ٿورڙا بگ ختم ٿي ويندا پروڊ ۾. اسان ان کي ٿوري دير کان پوء refactor ڪندو.
-
اسان ناقابل واپسي تبديلين کي رد ڪري سگھون ٿا. اهو معياري طريقو ناهي.
- اهو فائدي وارو آهي ڇو ته اسان ٽيسٽ بينچ جا وسيلا حصيداري ڪريون ٿا.
اڳ ۾ ئي سٺو، پر ٻيو ڇا تيز ٿي سگهي ٿو؟
اهڙي سسٽم جي مهرباني، اسان اهڙي جاچ ۾ داخل ٿيڻ جي حد کي تمام گهڻو گهٽائي سگهون ٿا.
ھاڻي ھڪڙو شيطاني دائرو آھي، جڏھن ھڪڙو ڊولپر، حقيقي مڪمل سائز جي ڊيٽا تائين رسائي حاصل ڪرڻ لاء، ھڪڙو ماهر ٿيڻ گھرجي. هن کي اهڙي رسائي سان ڀروسو ڪرڻ گهرجي.
پر جيڪڏهن اهو ناهي ته ڪيئن وڌو. پر ڇا جيڪڏهن توهان وٽ صرف هڪ تمام ننڍڙو سيٽ آهي ٽيسٽ ڊيٽا جو توهان وٽ دستياب آهي؟ پوء توهان کي ڪو به حقيقي تجربو حاصل نه ٿيندو.
هن دائري مان نڪرڻ ڪيئن؟ پهرين انٽرفيس جي طور تي، ڪنهن به سطح جي ڊولپرز لاءِ آسان، اسان چونڊيو Slack bot. پر اهو ڪنهن ٻئي انٽرفيس ٿي سگهي ٿو.
اهو توهان کي ڇا ڪرڻ جي اجازت ڏئي ٿو؟ توهان هڪ مخصوص سوال وٺي سگهو ٿا ۽ ڊيٽابيس لاء هڪ خاص چينل ڏانهن موڪلي سگهو ٿا. اسان خودڪار طريقي سان هڪ پتلي ڪلون سيڪنڊن ۾ ترتيب ڏينداسين. اچو ته هن درخواست کي هلائي. اسان ميٽرڪ ۽ سفارشون گڏ ڪندا آهيون. اچو ته هڪ تصوير ڏيکاريو. ۽ پوءِ ھي ڪلون رھندو ته جيئن ھن سوال کي ڪنھن طرح بهتر ڪري سگھجي، انڊيڪس شامل ڪريو، وغيره.
۽ پڻ Slack اسان کي باڪس کان ٻاهر تعاون جا موقعا ڏئي ٿو. جيئن ته هي صرف هڪ چينل آهي، توهان هن درخواست تي بحث شروع ڪري سگهو ٿا اتي ئي اهڙي درخواست جي سلسلي ۾، توهان جي ساٿين، ڊي بي ايز کي پنگ ڪريو جيڪي ڪمپني جي اندر آهن.
پر اتي، يقينا، مسئلا آهن. ڇاڪاڻ ته هي حقيقي دنيا آهي، ۽ اسان هڪ سرور استعمال ڪري رهيا آهيون جيڪو هڪ ئي وقت ۾ ڪيترن ئي ڪلونن کي ميزباني ڪري رهيو آهي، اسان کي ڪلون تائين موجود ميموري ۽ سي پي يو پاور جي مقدار کي دٻائڻو پوندو.
پر انهن ٽيسٽن لاءِ ممڪن آهي، توهان کي ڪنهن به طرح هن مسئلي کي حل ڪرڻ جي ضرورت آهي.
اهو واضح آهي ته اهم نقطو ساڳيو ڊيٽا آهي. پر اسان وٽ اڳ ۾ ئي آهي. ۽ اسان ساڳي ترتيب حاصل ڪرڻ چاهيون ٿا. ۽ اسان اهڙي تقريبن هڪجهڙائي واري ترتيب ڏئي سگهون ٿا.
اهو سٺو هوندو ته ساڳيو هارڊويئر پيداوار ۾ هجي، پر اهو مختلف ٿي سگهي ٿو.
اچو ته ياد رکو ته پوسٽ گريس ميموري سان ڪيئن ڪم ڪري ٿي. اسان وٽ ٻه ڪيچ آهن. ھڪڙي فائل سسٽم مان ۽ ھڪڙو اصلي پوسٽ گريس، يعني حصيداري بفر ڪيش.
اهو نوٽ ڪرڻ ضروري آهي ته شيئر ٿيل بفر ڪيش مختص ڪيو ويو آهي جڏهن پوسٽ گريس شروع ٿئي ٿي، ان تي منحصر آهي ته توهان ترتيب ۾ ڪهڙي سائيز جي وضاحت ڪندا آهيو.
۽ ٻيو ڪيش سڀ موجود جاءِ استعمال ڪري ٿو.
۽ جڏهن اسان هڪ مشين تي ڪيترائي کلون ٺاهيندا آهيون، اهو ظاهر ٿئي ٿو ته اسان آهستي آهستي ميموري کي ڀريندا آهيون. ۽ سٺي طريقي سان، شيئر ٿيل بفر ڪيش ميموري جي ڪل مقدار جو 25 سيڪڙو آهي جيڪا مشين تي موجود آهي.
۽ اهو ظاهر ٿئي ٿو ته جيڪڏهن اسان هن پيٽرولر کي تبديل نه ڪندا آهيون، ته پوء اسان هڪ مشين تي صرف 4 مثالن کي هلائڻ جي قابل ٿي سگهنداسين، اهو آهي، انهن مان 4 پتلي ڪلون مجموعي طور تي. ۽ اهو، يقينا، خراب آهي، ڇاڪاڻ ته اسان چاهيون ٿا انهن مان گهڻو ڪجهه.
پر ٻئي طرف، بفر ڪيش استعمال ڪيو ويندو آهي انڊيڪسز لاءِ سوالن تي عمل ڪرڻ لاءِ، اهو آهي، پلان ان تي منحصر آهي ته اسان جا ڪيش ڪيترا وڏا آهن. ۽ جيڪڏھن اسان صرف ھي پيٽرول وٺون ٿا ۽ ان کي گھٽائي سگھون ٿا، پوء اسان جا منصوبا تمام گھڻو تبديل ڪري سگھن ٿا.
مثال طور، جيڪڏهن اسان وٽ پروڊ تي وڏو ڪيش آهي، پوء پوسٽ گريس هڪ انڊيڪس استعمال ڪرڻ کي ترجيح ڏيندو. ۽ جيڪڏهن نه، ته پوء اتي ٿيندو SeqScan. ۽ جيڪڏھن اسان جا منصوبا ٺھي نه سگھندا ته ڇا ٿيندو؟
پر هتي اسان ان نتيجي تي پهتا آهيون ته حقيقت ۾ پوسٽ گريس ۾ پلان شيئرڊ بفر ۾ بيان ڪيل مخصوص سائيز تي منحصر نه آهي، ان تي منحصر آهي effective_cache_size.
Effective_cache_size ڪيش جي اندازي مطابق مقدار آھي جيڪا اسان وٽ موجود آھي، يعني بفر ڪيش ۽ فائل سسٽم ڪيش جو مجموعو. هي ترتيب ترتيب ڏنل آهي. ۽ هي ياداشت مختص نه ڪئي وئي آهي.
۽ هن پيٽرولر جي ڪري، اسان پوسٽ گريس کي چال ڪري سگهون ٿا، اهو چوڻ آهي ته اسان وٽ اصل ۾ تمام گهڻو ڊيٽا موجود آهي، جيتوڻيڪ اسان وٽ اهو ڊيٽا نه آهي. ۽ اهڙيء طرح، منصوبا مڪمل طور تي پيداوار سان ٺهڪندڙ هوندا.
پر اهو وقت تي اثر انداز ڪري سگهي ٿو. ۽ اسان وقت جي ذريعي سوالن کي بهتر ڪريون ٿا، پر اهو ضروري آهي ته وقت ڪيترن ئي عنصر تي منحصر آهي:
-
اهو ان لوڊ تي منحصر آهي جيڪو هن وقت پروڊ تي آهي.
-
اهو خود مشين جي خاصيتن تي منحصر آهي.
۽ اھو ھڪڙو اڻ سڌي طرح پيٽرولر آھي، پر حقيقت ۾ اسين ڊيٽا جي مقدار کي درست ڪري سگھون ٿا جيڪو نتيجو حاصل ڪرڻ لاء ھي سوال پڙھندو.
۽ جيڪڏهن توهان چاهيو ٿا ته وقت ان جي ويجهو هجي جيڪو اسان پروڊ ۾ ڏسندا سين، ته پوءِ اسان کي تمام گهڻو ساڳيو هارڊويئر وٺڻو پوندو ۽ ممڪن آهي ته اڃا به وڌيڪ ته جيئن سڀئي کلون مناسب هجن. پر اھو سمجھوتو آھي، يعني توھان کي ساڳيا منصوبا ملندا، توھان ڏسندؤ ته ھڪ خاص سوال ڪيترو ڊيٽا پڙھندو ۽ توھان ان نتيجي تي پھچي سگھندؤ ته اھو سوال سٺو آھي (يا لڏپلاڻ) يا خراب، ان کي اڃا بھتر ڪرڻ جي ضرورت آھي. .
اچو ته هڪ نظر رکون ته ڪيئن جويو خاص طور تي بهتر ڪيو ويو آهي.
اچو ته هڪ حقيقي نظام کان هڪ درخواست وٺون. هن معاملي ۾، ڊيٽابيس 1 terabyte آهي. ۽ اسان تازن پوسٽن جو تعداد ڳڻڻ چاهيون ٿا جن کي 10 کان وڌيڪ پسند ڪيو ويو.
اسان چينل کي پيغام لکي رهيا آهيون، اسان لاءِ ڪلون لڳايو ويو آهي. ۽ اسان ڏسنداسين ته اهڙي درخواست 2,5 منٽن ۾ مڪمل ٿيندي. اها پهرين شيء آهي جيڪا اسان نوٽيس ڪندا آهيون.
B Joe توهان کي ڏيکاريندو خودڪار تجويزون پلان ۽ ميٽرڪس جي بنياد تي.
اسان ڏسنداسين ته سوال تمام گهڻي ڊيٽا کي پروسيس ڪري ٿو نسبتا ننڍڙي قطار حاصل ڪرڻ لاء. ۽ ڪجهه قسم جي مخصوص انڊيڪس جي ضرورت آهي، ڇو ته اسان ڏٺو آهي ته سوال ۾ تمام گهڻيون فلٽر ٿيل قطارون آهن.
اچو ته هڪ ويجهي نظر رکون ته ڇا ٿيو. درحقيقت، اسان ڏسون ٿا ته اسان تقريبا هڪ اڌ گيگا بائيٽ ڊيٽا فائل ڪيش يا ڊسڪ مان پڻ پڙهي چڪا آهيون. ۽ اهو سٺو ناهي، ڇاڪاڻ ته اسان کي صرف 142 لائينون مليون آهن.
۽، اهو لڳي ٿو، اسان وٽ هتي هڪ انڊيڪس اسڪين آهي ۽ جلدي ڪم ڪرڻ گهرجي ها، پر جيئن ته اسان تمام گهڻيون لائينون فلٽر ڪيون (اسان کي انهن کي ڳڻڻ گهرجي)، درخواست سست رفتار سان ڪم ڪيو.
۽ اهو منصوبو ۾ ان حقيقت جي ڪري ٿيو آهي ته سوال ۾ حالتون ۽ انڊيڪس ۾ حالتون جزوي طور تي ميلاپ نه ٿيون ڪن.
اچو ته انڊيڪس کي وڌيڪ درست بڻائڻ جي ڪوشش ڪريون ۽ ڏسو ته ان کان پوءِ پڇا ڳاڇا ڪيئن بدلجي ٿي.
انڊيڪس جي ٺهڻ ۾ ڪافي وقت لڳي ويو، پر هاڻي اسان سوال کي چيڪ ڪري ڏسون ٿا ته وقت 2,5 منٽن بدران صرف 156 ملي سيڪنڊن جو آهي، جيڪو ڪافي سٺو آهي. ۽ اسان صرف 6 ميگا بائيٽ ڊيٽا پڙهندا آهيون.
۽ ھاڻي اسان انڊيڪس صرف اسڪين استعمال ڪندا آھيون.
ٻي اهم ڪهاڻي اها آهي ته اسان پلان کي ڪجهه وڌيڪ سمجھڻ واري انداز ۾ پيش ڪرڻ چاهيون ٿا. اسان فليم گرافس استعمال ڪندي تصور کي لاڳو ڪيو آهي.
هي هڪ مختلف درخواست آهي، وڌيڪ شديد. ۽ اسان فليم گرافس کي ٻن پيرا ميٽرن جي مطابق ٺاھيون ٿا: ھي ڊيٽا جو اھو مقدار آھي جيڪو ھڪ خاص نوڊ پلان ۽ ٽائمنگ ۾ شمار ٿئي ٿو، يعني نوڊ جي عمل جو وقت.
هتي اسان هڪ ٻئي سان مخصوص نوڊس جو مقابلو ڪري سگهون ٿا. ۽ اهو واضح ٿيندو ته انهن مان ڪير وڌيڪ يا گهٽ وٺندو آهي، جيڪو عام طور تي ٻين رينجرنگ طريقن ۾ ڪرڻ ڏکيو آهي.
يقينا، هرڪو ڄاڻي ٿو وضاحت.depesz.com. هن تصوير جي هڪ سٺي خصوصيت اها آهي ته اسان ٽيڪسٽ پلان کي محفوظ ڪريون ٿا ۽ ڪجهه بنيادي پيرا ميٽرز کي ٽيبل ۾ پڻ رکون ٿا ته جيئن اسان ترتيب ڏئي سگهون.
۽ ڊولپرز جن اڃا تائين هن موضوع تي ڌيان نه ڏنو آهي اهي به وضاحت.depesz.com استعمال ڪندا آهن، ڇاڪاڻ ته انهن لاءِ اهو معلوم ڪرڻ آسان آهي ته ڪهڙا ميٽرڪ اهم آهن ۽ ڪهڙا نه آهن.
ڏسڻ لاء هڪ نئون طريقو آهي - هي وضاحت.dalibo.com آهي. اهي هڪ وڻ جي تصوير ڪندا آهن، پر هڪ ٻئي سان نوڊس جو مقابلو ڪرڻ تمام ڏکيو آهي. هتي توهان ڍانچي کي چڱيءَ طرح سمجهي سگهو ٿا، جڏهن ته، جيڪڏهن ڪا وڏي درخواست آهي، ته پوءِ توهان کي اڳتي ۽ پوئتي وڃڻو پوندو، پر هڪ اختيار پڻ.
تعاون
۽، جيئن مون چيو، سست اسان کي تعاون ڪرڻ جو موقعو ڏئي ٿو. مثال طور، جيڪڏهن اسان وٽ هڪ پيچيده سوال آهي جيڪو واضح ناهي ته ڪيئن بهتر ڪجي، اسان هن مسئلي کي اسان جي ساٿين سان سليڪ ۾ هڪ سلسلي ۾ واضح ڪري سگهون ٿا.
اهو اسان کي لڳي ٿو ته اهو ضروري آهي ته مڪمل سائيز ڊيٽا تي جانچ ڪرڻ لاء. ائين ڪرڻ لاءِ، اسان ٺاھيو آھي تازه ڪاري ڊيٽابيس ليب ٽول، جيڪو موجود آھي اوپن سورس ۾. توھان استعمال ڪري سگھوٿا جو بوٽ پڻ. توھان ان کي ھاڻي وٺي سگھو ٿا ۽ پنھنجي جاء تي ان کي لاڳو ڪريو. سڀ گائيڊ اتي موجود آهن.
اهو پڻ ياد رکڻ ضروري آهي ته حل پاڻ کي انقلابي نه آهي، ڇاڪاڻ ته اتي ڊيلفڪس آهي، پر اهو هڪ ڪاروباري حل آهي. اهو مڪمل طور تي بند آهي، اهو تمام قيمتي آهي. اسان خاص طور تي Postgres ۾ ماهر. اهي سڀ اوپن سورس پراڊڪٽس آهن. اسان سان شامل ٿيو!
هي آهي جتي آئون ختم ڪريان ٿو. تنهنجي مهرباني!
توهان جا سوال
سلام! رپورٽ لاءِ مهرباني! تمام دلچسپ، خاص طور تي مون لاء، ڇاڪاڻ ته مون ڪجهه وقت اڳ ساڳئي مسئلي بابت حل ڪيو. ۽ تنهنڪري مون وٽ ڪيترائي سوال آهن. اميد آهي ته مان گهٽ ۾ گهٽ ان جو حصو حاصل ڪندس.
مون کي عجب لڳو ته توهان هن ماحول جي جڳهه کي ڪيئن ڳڻيو؟ ٽيڪنالاجي جو مطلب آهي ته ڪجهه حالتن ۾، توهان جا کلون وڌ ۾ وڌ سائيز تائين وڌي سگهن ٿا. عام طور تي ڳالهائڻ، جيڪڏهن توهان وٽ 10 ٽيرا بائيٽ ڊيٽابيس ۽ 10 ڪلون آهن، ته پوء هڪ اهڙي صورتحال کي ترتيب ڏيڻ آسان آهي جتي هر کلون XNUMX منفرد ڊيٽا جو وزن آهي. توهان هن جڳهه جو اندازو ڪيئن لڳايو، اهو آهي، اهو ڊيلٽا جنهن بابت توهان ڳالهايو آهي، جنهن ۾ اهي کلون رهندا؟
سٺو سوال. هتي مخصوص کلون جي ٽريڪ رکڻ ضروري آهي. ۽ جيڪڏهن ڪنهن ڪلون ۾ ڪا وڏي تبديلي اچي ٿي، اها وڌڻ شروع ٿئي ٿي، ته پوءِ اسان پهريان ان بابت استعمال ڪندڙ کي وارننگ جاري ڪري سگهون ٿا، يا فوري طور تي هن کلون کي روڪي سگهون ٿا ته جيئن اسان کي ناڪامي جي صورتحال نه اچي.
ها، مون وٽ هڪ سوال آهي. اهو آهي، توهان انهن ماڊلز جي زندگي جي چڪر کي ڪيئن يقيني بڻائي سگهو ٿا؟ اسان وٽ اهو مسئلو آهي ۽ هڪ مڪمل الڳ ڪهاڻي. اهو ڪيئن ٿو ٿئي؟
هر کلون لاءِ ڪجهه ٽي ٽي ايل آهي. بنيادي طور تي، اسان وٽ هڪ مقرر ٿيل ttl آهي.
ڇا، جيڪڏهن هڪ راز نه آهي؟
1 ڪلاڪ، يعني بيڪار - 1 ڪلاڪ. جيڪڏهن اهو استعمال نه ڪيو وڃي، پوء اسان ان کي ڌڪيو. پر هتي ڪا به تعجب ناهي، ڇو ته اسان ڪلون کي سيڪنڊن ۾ وڌائي سگهون ٿا. ۽ جيڪڏهن توهان کي ٻيهر ضرورت آهي، ته مهرباني ڪري.
مان پڻ ٽيڪنالاجي جي چونڊ ۾ دلچسپي وٺان ٿو، ڇاڪاڻ ته، مثال طور، اسان هڪ يا ٻئي سبب لاء متوازي ۾ ڪيترائي طريقا استعمال ڪندا آهيون. ڇو ZFS؟ توهان LVM ڇو نه استعمال ڪيو؟ توهان ٻڌايو ته LVM سان مسئلا هئا. مسئلا ڪهڙا هئا؟ منهنجي خيال ۾، سڀ کان وڌيڪ بهتر اختيار اسٽوريج سان آهي، ڪارڪردگي جي لحاظ کان.
ZFS سان بنيادي مسئلو ڇا آهي؟ حقيقت اها آهي ته توهان کي هڪ ئي ميزبان تي هلڻ گهرجي، يعني سڀئي مثال هڪ ئي او ايس اندر رهندا. ۽ اسٽوريج جي صورت ۾، توهان مختلف سامان ڳنڍي سگهو ٿا. ۽ رڪاوٽ صرف اهي بلاڪ آهن جيڪي اسٽوريج سسٽم تي آهن. ۽ ٽيڪنالاجي جي چونڊ جو سوال دلچسپ آهي. ڇو نه LVM؟
خاص طور تي، اسان گڏجاڻي ۾ LVM تي بحث ڪري سگهون ٿا. اسٽوريج بابت - اهو صرف قيمتي آهي. اسان ZFS سسٽم کي ڪٿي به لاڳو ڪري سگھون ٿا. توھان ان کي پنھنجي مشين تي ترتيب ڏئي سگھو ٿا. توهان صرف مخزن کي ڊائون لوڊ ڪري سگھو ٿا ۽ ان کي ترتيب ڏيو. ZFS لڳ ڀڳ هر جڳهه نصب ٿيل آهي جيڪڏهن اسان لينڪس بابت ڳالهائي رهيا آهيون. اهو آهي، اسان هڪ تمام لچڪدار حل حاصل ڪندا آهيون. ۽ دٻي کان ٻاهر، ZFS تمام گهڻو ڏئي ٿو. توھان اپلوڊ ڪري سگھوٿا گھڻو ڊيٽا جيترو توھان چاھيو، ڳنڍيو وڏي تعداد ۾ ڊسڪ، اتي سنيپ شاٽ آھن. ۽، جيئن مون چيو، اهو انتظام ڪرڻ آسان آهي. اهو آهي، اهو استعمال ڪرڻ تمام خوشگوار لڳي ٿو. هن کي آزمايو ويو آهي، هو ڪيترن ئي سالن جو آهي. هن وٽ هڪ تمام وڏي برادري آهي جيڪا وڌي رهي آهي. ZFS هڪ تمام قابل اعتماد حل آهي.
Nikolai Samokhvalov: ڇا مان وڌيڪ تبصرو ڪري سگهان ٿو؟ منهنجو نالو نيڪولي آهي، اسان اناتولي سان گڏ ڪم ڪريون ٿا. مان سمجهان ٿو ته اسٽوريج عظيم آهي. ۽ اسان جي ڪجهه گراهڪن وٽ خالص اسٽوريج وغيره آهن.
اناتولي صحيح طور تي نوٽ ڪيو آهي ته اسان ماڊليت تي مرکوز آهيون. ۽ مستقبل ۾، توهان هڪ انٽرفيس تي عمل ڪري سگهو ٿا - هڪ سنيپ شاٽ وٺو، هڪ کلون ٺاهيو، ڪلون کي تباهه ڪريو. اهو سڀ آسان آهي. ۽ اسٽوريج ٿڌو آهي، جيڪڏهن اهو آهي.
پر ZFS هر ڪنهن لاء دستياب آهي. ڊيلفڪس اڳ ۾ ئي ڪافي آهي، انهن وٽ 300 ڪلائنٽ آهن. انهن مان، fortune 100 وٽ 50 ڪلائنٽ آهن، يعني انهن جو مقصد ناسا وغيره آهي. اهو وقت آهي هر ڪنهن لاءِ هي ٽيڪنالاجي حاصل ڪرڻ. ۽ اهو ئي سبب آهي ته اسان وٽ هڪ کليل ذريعو ڪور آهي. اسان وٽ ھڪڙو انٽرفيس حصو آھي جيڪو کليل ذريعو نه آھي. هي اهو پليٽ فارم آهي جيڪو اسان ڏيکارينداسين. پر اسان چاهيون ٿا ته اهو هر ڪنهن لاءِ دستياب هجي. اسان هڪ انقلاب آڻڻ چاهيون ٿا ته جيئن سڀئي ٽيسٽ ڪندڙ ليپ ٽاپ تي اندازو لڳائڻ بند ڪن. اسان کي SELECT لکڻو آهي ۽ فوري طور تي ڏسو ته اهو سست آهي. ان بابت توهان کي ٻڌائڻ لاءِ DBA جو انتظار ڪرڻ بند ڪريو. هتي جو بنيادي مقصد آهي. ۽ مان سمجهان ٿو ته اسان سڀ هن ڏانهن ايندا. ۽ اسان اها شيءِ هر ڪنهن لاءِ ٺاهيندا آهيون. تنهن ڪري ZFS، ڇاڪاڻ ته اهو هر هنڌ موجود هوندو. مسئلن کي حل ڪرڻ ۽ اوپن سورس لائسنس وغيره حاصل ڪرڻ لاءِ ڪميونٽي جي مهرباني*
سلام! رپورٽ لاءِ مهرباني! منهنجو نالو ميڪسم آهي. اسان ساڳين مسئلن سان معاملو ڪيو آهي. پاڻ فيصلو ڪيائون. توهان انهن ڪلون جي وچ ۾ وسيلن کي ڪيئن حصيداري ڪندا آهيو؟ هر ڪلون ڪنهن به وقت پنهنجو ڪم ڪري سگهي ٿو: ڪو هڪ شيءِ کي آزمائي ٿو، ٻيو ٻيو، ڪو هڪ انڊيڪس ٺاهي ٿو، ڪنهن وٽ وڏي نوڪري آهي. ۽ جيڪڏھن توھان اڃا تائين سي پي يو سان ورهائي سگھو ٿا، پوءِ IO ذريعي، توھان ڪيئن ورهايو ٿا؟ هي پهريون سوال آهي.
۽ ٻيو سوال اسٽينڊ جي تفاوت بابت آهي. اچو ته چئو ته مون وٽ هتي ZFS آهي ۽ سڀ ڪجهه ٿڌو آهي، پر پروڊ تي ڪلائنٽ ZFS نه آهي، پر مثال طور ext4. ڪيئن هن معاملي ۾؟
سوال ڏاڍا سٺا آهن. مون هن مسئلي جو ٿورو ذڪر ڪيو حقيقت سان ته اسان وسيلن کي حصيداري ڪريون ٿا. ۽ حل هي آهي. تصور ڪريو ته توهان اسٽيجنگ تي جاچ ڪري رهيا آهيو. توهان وٽ به اهڙي حالت هڪ ئي وقت ٿي سگهي ٿي جو ڪو هڪ لوڊ ڪري، ڪو ٻيو. ۽ نتيجي طور، توهان ناقابل فهم ميٽرڪ ڏسو. جيتوڻيڪ ساڳيو مسئلو پيداوار سان ٿي سگهي ٿو. جڏهن توهان ڪجهه درخواست چيڪ ڪرڻ چاهيو ٿا ۽ توهان ڏسو ٿا ته ان ۾ ڪجهه مسئلو آهي - اهو سست رفتاري سان ڪم ڪري ٿو، پوء حقيقت ۾ مسئلو درخواست ۾ نه هو، پر حقيقت ۾ اهو آهي ته ڪجهه قسم جي متوازي لوڊ آهي.
۽ ان ڪري، هتي اهو ضروري آهي ته ان ڳالهه تي ڌيان ڏيڻ گهرجي ته پلان ڇا هوندو، اسان پلان ۾ ڪهڙا قدم کڻنداسين ۽ ان لاءِ ڪيترو ڊيٽا گڏ ڪنداسين. حقيقت اها آهي ته اسان جي ڊسڪ، مثال طور، ڪنهن شيء سان لوڊ ڪيو ويندو، اهو خاص طور تي وقت تي اثر انداز ڪندو. پر اسان اندازو لڳائي سگهون ٿا ته هي درخواست ڪيتري لوڊ ٿيل آهي ڊيٽا جي مقدار مان. اهو ايترو ضروري ناهي ته هڪ ئي وقت ۾ ڪنهن قسم جي عملدرآمد ٿي ويندي.
مون وٽ ٻه سوال آهن. هي تمام ٿڌو سامان آهي. ڇا اهڙا ڪيس آهن جتي پيداوار ڊيٽا نازڪ آهي، جهڙوڪ ڪريڊٽ ڪارڊ نمبر؟ ڇا اڳ ۾ ئي ڪجهه تيار آهي يا اهو هڪ الڳ ڪم آهي؟ ۽ ٻيو سوال - ڇا MySQL لاءِ اهڙي ڪا شيءِ آهي؟
ڊيٽا جي باري ۾. جيستائين اسان ڪندا تيستائين obfuscation ڪندا رهنداسين. پر جيڪڏهن توهان صحيح طور تي جويو کي ترتيب ڏيو ٿا، جيڪڏهن توهان ڊولپرز تائين رسائي نه ڏيو، پوء ڊيٽا تائين ڪا به رسائي ناهي. ڇو؟ ڇو جو جو ڊيٽا نه ڏيکاريندو آهي. اهو صرف ڏيکاري ٿو ميٽرڪ، منصوبا ۽ اهو ئي آهي. اهو مقصد تي ڪيو ويو آهي، ڇاڪاڻ ته هي اسان جي ڪلائنٽ جي گهرجن مان هڪ آهي. اهي چاهيندا هئا ته هر ڪنهن کي رسائي ڏيڻ کان سواء بهتر ڪرڻ جي قابل.
MySQL بابت. هي سسٽم ڪنهن به شيءِ لاءِ استعمال ٿي سگهي ٿو جيڪو ڊسڪ تي اسٽيٽ اسٽور ڪري ٿو. ۽ جيئن ته اسان ڪري رهيا آهيون Postgres، اسان هاڻي ڪري رهيا آهيون سڀ آٽوميشن Postgres لاءِ پهرين. اسان هڪ بيڪ اپ مان ڊيٽا حاصل ڪرڻ کي خودڪار ڪرڻ چاهيون ٿا. اسان صحيح ترتيب ڏئي رهيا آهيون Postgres. اسان ڄاڻون ٿا ته منصوبا ڪيئن ٺاهجن، وغيره.
پر جيئن ته سسٽم وسيع آهي، اهو پڻ استعمال ڪري سگهجي ٿو MySQL لاءِ. ۽ اهڙا مثال آهن. Yandex وٽ ھڪڙي ھڪڙي شيء آھي، پر اھي ان کي ڪٿي به شايع نه ڪندا آھن. اهي Yandex.Metrica اندر استعمال ڪندا آهن. ۽ MySQL بابت صرف هڪ ڪهاڻي آهي. پر ٽيڪنالاجيون ساڳيون آهن، ZFS.
رپورٽ لاءِ مهرباني! مون وٽ به ڪجهه سوال آهن. توهان ذڪر ڪيو آهي ته ڪلوننگ استعمال ڪري سگهجي ٿي تجزياتي لاءِ، مثال طور اتي اضافي انڊيڪس ٺاهڻ لاءِ. ڇا توهان ٿورو وڌيڪ ٻڌائي سگهو ٿا ته اهو ڪيئن ڪم ڪري ٿو؟
۽ مان فوري طور تي ٻيو سوال پڇندس اسٽينڊ جي هڪجهڙائي بابت، منصوبن جي هڪجهڙائي. منصوبو پڻ پوسٽ گريس پاران گڏ ڪيل انگن اکرن تي منحصر آهي. توهان هن مسئلي کي ڪيئن حل ڪندا؟
تجزيي جي مطابق، ڪو خاص ڪيس نه آهن، ڇو ته اسان اڃا تائين استعمال نه ڪيو آهي، پر اتي هڪ موقعو آهي. جيڪڏهن اسان انڊيڪس جي باري ۾ ڳالهائي رهيا آهيون، پوء تصور ڪريو ته هڪ سوال سئو لکن جي رڪارڊ ۽ هڪ ڪالمن سان گڏ ٽيبل جو تعاقب ڪري رهيو آهي جيڪو عام طور تي پروڊ ۾ نه آهي. ۽ اسان اتي ڪجھ ڊيٽا کي ڳڻڻ چاهيون ٿا. جيڪڏهن اها درخواست پروڊ ڏانهن موڪلي وئي ته پوءِ امڪان آهي ته اهو پروڊ تي سادو هوندو، ڇاڪاڻ ته درخواست تي عمل ڪيو ويندو اتي هڪ منٽ لاءِ.
ٺيڪ آهي، اچو ته هڪ پتلي کلون ٺاهيو جيڪو ڪجهه منٽن لاء روڪڻ لاء خوفناڪ نه آهي. ۽ اينالائيٽڪس پڙهڻ لاءِ وڌيڪ آرامده بڻائڻ لاءِ، اسان انهن ڪالمن لاءِ اشارا شامل ڪنداسين جن ۾ اسان ڊيٽا ۾ دلچسپي رکون ٿا.
انڊيڪس هر وقت ٺاهي ويندي؟
توهان اهو ڪري سگهو ٿا ته جيئن اسان ڊيٽا کي ڇڪيون، سنيپ شاٽ ٺاهيو، پوء اسان هن سنيپ شاٽ مان حاصل ڪنداسين ۽ نئين درخواستن کي ڊرائيو ڪنداسين. اهو آهي، توهان ان کي ٺاهي سگهو ٿا ته جيئن توهان اڳ ۾ ئي لڳل انڊيڪس سان نوان کلون بلند ڪري سگهو ٿا.
انگن اکرن بابت سوال جي طور تي، جيڪڏهن اسان بيڪ اپ مان بحال ڪريون ٿا، جيڪڏهن اسان نقل ڪريون ٿا، ته اسان جا انگ اکر بلڪل ساڳيا هوندا. ڇاڪاڻ ته اسان وٽ پوري جسماني ڊيٽا جي جوڙجڪ آهي، اهو آهي، اسان ڊيٽا آڻينداسين جيئن اهو سڀني انگن اکرن سان گڏ آهي.
هتي هڪ ٻيو مسئلو آهي. جيڪڏهن توهان ڪلائوڊ حل استعمال ڪريو ٿا، ته پوء صرف منطقي ڊمپ موجود آهن، ڇاڪاڻ ته گوگل، ايم ڊيزون توهان کي جسماني ڪاپي وٺڻ جي اجازت نه ڏيندا آهن. ڪو مسئلو ٿيندو.
رپورٽ لاءِ مهرباني. هتي ٻه سٺا سوال هئا MySQL ۽ وسيلن جي حصيداري بابت. پر، حقيقت ۾، اهو سڀ ڪجهه حقيقت تي اچي ٿو ته اهو مخصوص DBMS جو موضوع ناهي، پر مڪمل طور تي فائل سسٽم جو. ۽، مطابق، وسيلن جي حصيداري جا مسئلا پڻ اتان کان حل ٿيڻ گهرجن، نه ته آخر ۾ اهو پوسٽ گريس آهي، پر فائل سسٽم ۾، سرور ۾، مثال طور.
منهنجو سوال ٿورو مختلف آهي. اهو گھڻن پرت واري ڊيٽابيس جي ويجهو آهي، جتي ڪيترائي تہه آهن. مثال طور، اسان هڪ ڏهه ٽيرا بائيٽ تصويري اپڊيٽ قائم ڪئي، اسان نقل ڪري رهيا آهيون. ۽ اسان خاص طور تي هي حل ڊيٽابيس لاءِ استعمال ڪندا آهيون. نقل جاري آهي، ڊيٽا کي اپڊيٽ ڪيو پيو وڃي. هتي 100 ملازم متوازي طور تي ڪم ڪري رهيا آهن، جيڪي مسلسل اهي مختلف شاٽ شروع ڪري رهيا آهن. ڇا ڪجي؟ ڪيئن پڪ ڪجي ته ڪو به تڪرار نه آهي، ته انهن هڪ لانچ ڪيو، ۽ پوءِ فائيل سسٽم بدلجي ويو، ۽ اهي تصويرون سڀ هلي ويون؟
اهي نه ويندا ڇو ته اهو ڪيئن ZFS ڪم ڪري ٿو. اسان فائل سسٽم جي تبديلين کي الڳ الڳ هڪ سلسلي ۾ رکي سگهون ٿا جيڪي نقل ڪرڻ جي ڪري اچن ٿيون. ۽ ڪلون رکو جيڪي ڊولپرز ڊيٽا جي پراڻن ورزن تي استعمال ڪن ٿا. ۽ اهو اسان لاء ڪم ڪري ٿو، هر شيء هن سان ترتيب ۾ آهي.
اهو ظاهر ٿئي ٿو ته تازه ڪاري هڪ اضافي پرت جي طور تي ٿيندي، ۽ سڀ نيون تصويرون اڳ ۾ ئي ويندا، هن پرت جي بنياد تي، صحيح؟
پوئين پرت کان جيڪي اڳئين نقلن مان هئا.
پوئين پرت ختم ٿي وينديون، پر اهي پراڻي پرت ڏانهن اشارو ڪندا، ۽ ڇا اهي تازه ڪاري ۾ حاصل ڪيل آخري پرت مان نيون تصويرون وٺندا؟
عام طور تي، ها.
ان جي نتيجي ۾ اسان وٽ هڪ انجير تائين تہون هونديون. ۽ وقت سان گڏ انهن کي دٻائڻ جي ضرورت پوندي؟
ها سڀ ڪجهه صحيح آهي. ڪجهه ونڊو آهي. اسان هفتيوار تصويرون رکون ٿا. اهو منحصر آهي ته توهان وٽ ڪهڙو وسيلو آهي. جيڪڏهن توهان وٽ تمام گهڻو ڊيٽا ذخيرو ڪرڻ جي صلاحيت آهي، توهان ڊگهي وقت تائين سنيپ شاٽ محفوظ ڪري سگهو ٿا. اهي پاڻ تي نه ويندا. ڪو به ڊيٽا ڪرپشن نه ٿيندو. جيڪڏهن سنيپ شاٽ پراڻا آهن، جيئن اهو اسان کي لڳي ٿو، يعني اهو ڪمپني جي پاليسي تي منحصر آهي، پوء اسان صرف انهن کي حذف ڪري سگھون ٿا ۽ جاء خالي ڪري سگهون ٿا.
هيلو، رپورٽ لاء مهرباني! جو بابت سوال. توهان چيو ته ڪسٽمر هر ڪنهن کي ڊيٽا تائين رسائي نه ڏيڻ چاهيندو هو. سختي سان ڳالهائڻ، جيڪڏهن ڪنهن شخص کي وضاحت جي تجزيي جو نتيجو آهي، پوء هو ڊيٽا کي ڇڪي سگهي ٿو.
ائين ئي آهي. مثال طور، اسان لکي سگھون ٿا: "SELECT FROM WHERE email = to that". اهو آهي، اسان ڊيٽا پاڻ کي نه ڏسنداسين، پر اسان ڪجهه اڻ سڌي طرح نشانيون ڏسي سگهون ٿا. اهو سمجهڻ گهرجي. پر ٻئي طرف، اهو سڀ ڪجهه آهي. اسان وٽ لاگ آڊٽ آهي، اسان وٽ ٻين ساٿين جو ڪنٽرول آهي، جيڪي پڻ ڏسن ٿا ته ڊولپر ڇا ڪري رهيا آهن. ۽ جيڪڏهن ڪو اهڙو ڪم ڪرڻ جي ڪوشش ڪندو ته پوءِ سيڪيورٽي سروس ان وٽ ايندي ۽ هن مسئلي تي ڪم ڪندي.
منجهند جو سلام رپورٽ لاءِ مهرباني! مون وٽ هڪ مختصر سوال آهي. جيڪڏهن ڪمپني Slack استعمال نه ڪندي آهي، ڇا هاڻي ان لاءِ ڪو پابند آهي، يا ڇا اهو ممڪن آهي ته ڊولپرز لاءِ مثالن کي ترتيب ڏيڻ لاءِ ٽيسٽ ايپليڪيشن کي ڊيٽابيس سان ڳنڍڻ لاءِ؟
ھاڻي ھتي Slack جي ھڪڙي لنڪ آھي، يعني ڪو ٻيو ميسينجر ناھي، پر مان واقعي چاھيان ٿو ٻين ميسينجرن لاءِ به مدد ڪرڻ. توهان ڇا ٿا ڪري سگھو؟ توهان جوئي کان سواءِ ڊي بي ليب ترتيب ڏئي سگهو ٿا، وڃو REST API جي مدد سان يا اسان جي پليٽ فارم جي مدد سان ۽ ڪلون ٺاهيو ۽ PSQL سان ڳنڍيو. پر اهو ٿي سگهي ٿو جيڪڏهن توهان پنهنجي ڊولپرز کي ڊيٽا تائين رسائي ڏيڻ لاءِ تيار آهيو، ڇو ته هاڻي ڪو به اسڪرين نه هوندو.
مون کي هن پرت جي ضرورت ناهي، پر مون کي اهڙي موقعي جي ضرورت آهي.
پوء ها، اهو ڪري سگهجي ٿو.
جو ذريعو: www.habr.com