نوٽ. ترجمو: Jaana Dogan گوگل ۾ هڪ تجربيڪار انجنيئر آهي جيڪو هن وقت گو ۾ لکيل ڪمپني جي پيداواري خدمتن جي مشاهدي تي ڪم ڪري رهيو آهي. هن آرٽيڪل ۾، جنهن انگريزي ڳالهائيندڙ سامعين ۾ وڏي مقبوليت حاصل ڪئي، هن DBMSs (۽ ڪڏهن ڪڏهن عام طور تي ورهايل نظام) جي حوالي سان 17 نقطا اهم ٽيڪنيڪل تفصيل گڏ ڪيا جيڪي وڏي/مطالبو ڪندڙ ايپليڪيشنن جي ڊولپرز لاءِ غور ڪرڻ لاءِ ڪارآمد آهن.
ڪمپيوٽر سسٽم جي وڏي اڪثريت انهن جي رياست جي نگراني ڪندو آهي ۽، مطابق، ڪجهه قسم جي ڊيٽا اسٽوريج سسٽم جي ضرورت هوندي آهي. مون ڊگھي عرصي دوران ڊيٽابيس جي باري ۾ ڄاڻ گڏ ڪئي، طريقي سان ٺاھڻ جي غلطيون جيڪي ڊيٽا جي نقصان ۽ بندش جو سبب بڻيا. سسٽم ۾ جيڪي معلومات جي وڏي مقدار تي عمل ڪن ٿا، ڊيٽابيس سسٽم جي فن تعمير جي دل تي ڪوڙ ڪن ٿا ۽ بهترين حل چونڊڻ ۾ هڪ اهم عنصر طور ڪم ڪن ٿا. انهي حقيقت جي باوجود ته ڊيٽابيس جي ڪم تي تمام گهڻو ڌيان ڏنو ويو آهي، اهي مسئلا جيڪي ايپليڪيشن ڊولپرز کي پيش ڪرڻ جي ڪوشش ڪندا آهن اڪثر ڪري صرف برفاني ٽڪر جي ٽپ آهن. مضمونن جي هن سلسلي ۾، آئون ڪجهه خيالن جو حصيداري ڪريان ٿو جيڪي ڊولپرز لاء مفيد هوندا جيڪي هن فيلڊ ۾ ماهر نه آهن.
- توهان خوش قسمت آهيو جيڪڏهن 99,999٪ وقت نيٽ ورڪ مسئلا پيدا نه ڪري رهيو آهي.
- ACID جو مطلب آھي ڪيتريون ئي مختلف شيون.
- هر ڊيٽابيس ۾ مستقل مزاجي ۽ اڪيلائي کي يقيني بڻائڻ لاءِ پنهنجو ميکانيزم هوندو آهي.
- Optimistic Blocking اچي ٿو بچاءُ لاءِ جڏهن ان کي برقرار رکڻ ڏکيو هوندو آهي معمولي کي.
- گندي پڙھڻ ۽ ڊيٽا جي نقصان کان سواء ٻيون غير معمولي آھن.
- ڊيٽابيس ۽ صارف هميشه عمل جي عمل تي متفق نه آهن.
- ايپليڪيشن جي سطح جي شارڊنگ کي ايپليڪيشن کان ٻاهر منتقل ڪري سگھجي ٿو.
- خودڪار اضافو خطرناڪ ٿي سگهي ٿو.
- اسٽيل ڊيٽا مفيد ٿي سگهي ٿي ۽ ان کي بند ڪرڻ جي ضرورت ناهي.
- ڪنهن به وقت جي ذريعن لاءِ تحريف عام آهن.
- دير جا ڪيترائي مطلب آهن.
- ڪارڪردگي جي ضرورتن کي هڪ مخصوص ٽرانزيڪشن لاء جائزو وٺڻ گهرجي.
- Nested ٽرانزيڪشن خطرناڪ ٿي سگهي ٿو.
- ٽرانزيڪشن کي ايپليڪيشن اسٽيٽ سان ڳنڍيل نه هجڻ گهرجي.
- سوالن جا منصوبا توهان کي ڊيٽابيس بابت گهڻو ڪجهه ٻڌائي سگھن ٿا.
- آن لائين لڏپلاڻ ڏکيو آهي، پر ممڪن آهي.
- ڊيٽابيس ۾ هڪ اهم اضافو غير متوقع طور تي اضافو آهي.
مان ايممنول اوڊيڪ، رين هينريڪس ۽ ٻين جو شڪريو ادا ڪرڻ چاهيان ٿو انهن جي راءِ لاءِ هن آرٽيڪل جي اڳوڻي ورزن تي.
توهان خوش قسمت آهيو جيڪڏهن 99,999٪ وقت نيٽ ورڪ مسئلا پيدا نه ڪري رهيو آهي.
سوال رهي ٿو ته ڪيئن قابل اعتماد جديد نيٽ ورڪ ٽيڪنالاجيون آهن ۽ ڪيترا ئي سسٽم نيٽ ورڪ ناڪامي جي ڪري هيٺ آهن. هن مسئلي تي معلومات ناياب آهي ۽ تحقيق اڪثر ڪري خاص نيٽ ورڪن، سامان ۽ اهلڪارن سان وڏي تنظيمن جي تسلط آهي.
اسپنر لاءِ 99,999٪ جي دستيابي جي شرح سان (گوگل جو عالمي سطح تي ورهايل ڊيٽابيس)، گوگل دعويٰ ڪري ٿو ته صرف مسئلا نيٽ ورڪ سان لاڳاپيل آهن. ساڳئي وقت، ڪمپني پنهنجي خاص نيٽ ورڪ کي اعلي دستيابي جو "مکيه ستون" سڏيندو آهي. مطالعو 2014 ۾ ڪيل، هڪ چيلينج ""، جيڪو پيٽر Deutsch 1994 ۾ ٺاهيو. ڇا نيٽ ورڪ واقعي قابل اعتماد آهي؟
وشال ڪمپنين کان ٻاهر جامع تحقيق، وسيع انٽرنيٽ لاءِ ڪئي وئي، بس موجود ناهي. وڏن رانديگرن کان ڪافي ڊيٽا پڻ نه آهي ته انهن جي گراهڪن جي مسئلن جو سيڪڙو نيٽ ورڪ سان لاڳاپيل آهن. اسان وڏي ڪلائوڊ فراهم ڪندڙن جي نيٽ ورڪ اسٽيڪ ۾ بندش کان چڱيءَ طرح واقف آهيون جيڪي ڪيترن ئي ڪلاڪن لاءِ انٽرنيٽ جو پورو حصو وٺي سگهن ٿا صرف ان ڪري جو اهي اعليٰ سطحي واقعا آهن جيڪي ماڻهن ۽ ڪمپنين جي وڏي تعداد کي متاثر ڪن ٿا. نيٽ ورڪ بندش ڪيترن ئي ڪيسن ۾ مسئلا پيدا ڪري سگهي ٿي، جيتوڻيڪ اهي سڀئي ڪيس روشني ۾ نه آهن. ڪلائوڊ سروسز جا گراهڪ پڻ مسئلن جي سببن بابت ڪجھ به نه ڄاڻندا آهن. جيڪڏهن ڪو ناڪامي آهي، اهو تقريبا ناممڪن آهي ته ان کي منسوب ڪرڻ لاء نيٽ ورڪ جي غلطي جي خدمت فراهم ڪندڙ جي پاسي تي. انهن لاءِ، ٽئين پارٽي جون خدمتون ڪارو باڪس آهن. وڏي خدمت فراهم ڪندڙ کان سواءِ اثر جو اندازو لڳائڻ ناممڪن آهي.
ڏنو ويو آهي ته وڏن رانديگرن انهن جي سسٽم بابت ڇا رپورٽ ڪن ٿا، اهو چوڻ لاء محفوظ آهي ته توهان قسمت ۾ آهيو جيڪڏهن نيٽ ورڪ مشڪلاتن جي امڪاني وقت جي مسئلن جو صرف هڪ ننڍڙو حصو آهي. نيٽ ورڪ ڪميونيڪيشن اڃا تائين اهڙين غير معمولي شين کان متاثر آهن جيئن هارڊويئر ناڪامي، ٽوپولوجي تبديلين، انتظامي ترتيبن جي تبديلين، ۽ بجلي جي بندش. تازو، مون کي حيران ٿي ويو ته سکڻ جي ممڪن مسئلن جي فهرست شامل ڪئي وئي (ها، توهان صحيح ٻڌو).
ACID جو مطلب آھي مختلف شيون
ACID جو مخفف آهي Atomicity, Consistency, Isolation, Reliability. ٽرانزيڪشن جي انهن ملڪيتن جو مقصد آهي انهن جي صحيحيت کي يقيني بڻائڻ جي ناڪامي جي صورت ۾، غلطيون، هارڊويئر ناڪامي وغيره. ACID يا ساڳين اسڪيمن کان سواءِ، ايپليڪيشن ڊولپرز لاءِ ان ۾ فرق ڪرڻ ڏکيو هوندو ته اهي ڪهڙا ذميوار آهن ۽ ڪهڙي ڊيٽابيس لاءِ ذميوار آهي. اڪثر لاڳاپي واري ٽرانزيڪشنل ڊيٽابيس ACID مطابق ٿيڻ جي ڪوشش ڪندا آهن، پر نوان طريقا جهڙوڪ NoSQL ڪيترن ئي ڊيٽابيس کي جنم ڏنو آهي ACID ٽرانزيڪشن کان سواءِ ڇاڪاڻ ته انهن تي عمل ڪرڻ مهانگو آهي.
جڏهن مون پهريون ڀيرو صنعت ۾ داخل ٿيو، اسان جي ٽيڪنيڪل ليڊ بابت ڳالهايو ته ACID تصور ڪيترو لاڳاپيل هو. منصفانه هجڻ لاء، ACID کي سخت عمل جي معيار جي بجاء هڪ خراب وضاحت سمجهيو ويندو آهي. اڄ مون کي اهو تمام گهڻو مفيد آهي ڇو ته اهو مسئلن جي هڪ مخصوص قسم کي وڌائيندو آهي (۽ ممڪن حل جي هڪ حد جو مشورو ڏئي ٿو).
هر DBMS ACID مطابق ناهي. ساڳئي وقت، ڊيٽابيس تي عمل درآمد جيڪي ACID کي سپورٽ ڪن ٿا ضرورتن جي سيٽ کي مختلف طرح سان سمجهن ٿا. ACID تي عمل درآمد جي خراب ٿيڻ جو ھڪڙو سبب اھو آھي ته ACID جي ضرورتن کي لاڳو ڪرڻ لاءِ گھڻا ئي واپار بند ڪيا وڃن. ٺاھيندڙ پنھنجي ڊيٽابيس کي ACID-compliant طور پيش ڪري سگھن ٿا، پر ڪنارن جي ڪيسن جي تشريح مختلف ٿي سگھي ٿي، جيئن "ناممڪن" واقعن کي ھٿ ڪرڻ جو ميکانيزم. تمام گھٽ ۾ گھٽ، ڊولپرز بنيادي عملن جي پيچيدگين جي اعلي سطحي سمجھ حاصل ڪري سگھن ٿا انھن جي خاص رويي ۽ ڊيزائن جي واپاري بندن جي صحيح سمجھ حاصل ڪرڻ لاء.
بحث جاري آهي ته ڇا MongoDB ACID گهرجن سان تعميل ڪري ٿو نسخو 4 جي ڇڏڻ کان پوءِ به. MongoDB هڪ ڊگهي وقت تائين سپورٽ نه ڪئي وئي آهي , جيتوڻيڪ ڊفالٽ طور تي ڊيٽا ڊسڪ کي هر 60 سيڪنڊن ۾ هڪ ڀيرو کان وڌيڪ نه هئي. هيٺ ڏنل منظر جو تصور ڪريو: هڪ ايپليڪيشن پوسٽ ڪري ٿي ٻه لکت (w1 ۽ w2). MongoDB ڪاميابيءَ سان w1 اسٽور ڪري ٿو، پر هارڊويئر جي ناڪاميءَ جي ڪري w2 گم ٿي ويو آهي.
ڊراگرام منظر عام کي بيان ڪري ٿو. MongoDB حادثو ان کان اڳ ٿي سگھي ٿو جيڪو ڊسڪ تي ڊيٽا لکي سگھي
ڊسڪ تي ڪم ڪرڻ هڪ قيمتي عمل آهي. بار بار ڪمن کان بچڻ سان، ڊولپرز قابل اعتماد جي خرچ تي رڪارڊنگ ڪارڪردگي کي بهتر بڻائي ٿو. MongoDB في الحال لاگنگ کي سپورٽ ڪري ٿو، پر گندي لکڻيون اڃا تائين ڊيٽا جي سالميت کي متاثر ڪري سگهن ٿيون ڇو ته لاگز هر 100ms تي ڊفالٽ طور تي قبضو ڪيو ويندو آهي. اھو آھي، ھڪڙو ساڳيو منظر اڃا تائين لاگ ان ۽ انھن ۾ پيش ڪيل تبديلين لاء ممڪن آھي، جيتوڻيڪ خطرو تمام گھٽ آھي.
هر ڊيٽابيس جي پنهنجي مستقل مزاجي ۽ اڪيلائي واري ميڪانيزم آهي
ACID جي ضرورتن مان، مستقل مزاجي ۽ اڪيلائي مختلف عملن جي وڏي تعداد تي فخر ڪري ٿي ڇاڪاڻ ته واپار جي حد وسيع آهي. اهو ضرور چيو وڃي ٿو ته استحڪام ۽ اڪيلائي ڪافي قيمتي ڪم آهن. انهن کي همٿ جي ضرورت آهي ۽ ڊيٽا جي استحڪام لاءِ مقابلو وڌايو. مسئلي جي پيچيدگي خاص طور تي وڌي ٿي جڏهن اهو ضروري آهي ته ڊيٽابيس کي افقي طور تي ڪيترن ئي ڊيٽا سينٽرن (خاص طور تي جيڪڏهن اهي مختلف جاگرافيائي علائقن ۾ واقع آهن). هڪ اعلي سطحي استحڪام حاصل ڪرڻ تمام ڏکيو آهي، ڇاڪاڻ ته اهو پڻ دستيابي کي گھٽائي ٿو ۽ نيٽ ورڪ جي ڀاڱي کي وڌائي ٿو. هن رجحان جي وڌيڪ عام وضاحت لاء، آئون توهان کي رجوع ڪرڻ جي صلاح ڏيان ٿو . اهو پڻ نوٽ ڪرڻ جي قابل آهي ته ايپليڪيشنون ننڍي مقدار ۾ غير مطابقت کي سنڀالي سگهن ٿيون، ۽ پروگرامر مسئلي جي نونسن کي چڱي طرح سمجهي سگهن ٿا ته ايپليڪيشن ۾ اضافي منطق کي لاڳو ڪرڻ لاء ان کي سنڀالڻ لاء ڊيٽابيس تي تمام گهڻو انحصار ڪرڻ کان سواء.
ڊي بي ايم ايس اڪثر ڪري مختلف سطحن جي اڪيلائي مهيا ڪن ٿا. ايپليڪيشن ڊولپرز انهن جي ترجيحن جي بنياد تي سڀ کان وڌيڪ اثرائتي چونڊ ڪري سگهن ٿا. گھٽ علحدگيءَ جي اجازت ڏئي ٿي رفتار وڌائڻ جي، پر ڊيٽا ريس جي خطري کي به وڌائي ٿي. هاء موصليت هن امڪان کي گهٽائي ٿو، پر ڪم کي سست ڪري ٿو ۽ مقابلو ڪري سگهي ٿو، جنهن جي بنياد تي اهڙي برڪون ٿينديون جيڪي ناڪامي شروع ٿينديون آهن.
موجوده سمورو ماڊل جو جائزو ۽ انهن جي وچ ۾ لاڳاپا
SQL معيار صرف چار اڪيلائي جي سطح کي بيان ڪري ٿو، جيتوڻيڪ نظريي ۽ عمل ۾ اتي ڪيترائي وڌيڪ آھن. موجوده هم وقت سازي جي ماڊل جو هڪ بهترين جائزو پيش ڪري ٿو. مثال طور، گوگل اسپنر گھڙي جي هم وقت سازي سان خارجي سيريلائيزيشن جي ضمانت ڏئي ٿو، ۽ جيتوڻيڪ اھو ھڪڙو سخت اڪيلائي واري پرت آھي، ان کي معياري آئسوليشن پرت ۾ بيان نه ڪيو ويو آھي.
SQL معيار هيٺ ڏنل اڪيلائي جي سطحن جو ذڪر ڪري ٿو:
- سيرالي ٿيل (سڀ کان وڌيڪ سخت ۽ مهانگو): سيريلائيبل ايگزيڪيوشن جو ساڳيو اثر آهي جيئن ڪجهه ترتيب وار ٽرانزيڪشن تي عمل. تسلسل واري عمل جو مطلب آهي ته هر ايندڙ ٽرانزيڪشن صرف پوئين مڪمل ٿيڻ کان پوء شروع ٿئي ٿي. اهو نوٽ ڪرڻ گهرجي ته سطح سيرالي ٿيل تفسير ۾ اختلافن جي ڪري اڪثر نام نهاد سنيپ شاٽ آئسوليشن (مثال طور، Oracle ۾) لاڳو ڪيو ويندو آهي، جيتوڻيڪ سنيپ شاٽ آئسوليشن خود SQL معيار ۾ نمايان نه آهي.
- بار بار پڙهڻ: موجوده ٽرانزيڪشن ۾ اڻڄاتل رڪارڊ موجوده ٽرانزيڪشن لاء دستياب آهن، پر ٻين ٽرانزيڪشن پاران ڪيل تبديليون (جهڙوڪ نئين قطار) .
- پابند پڙهو: اڻڄاتل ڊيٽا ٽرانزيڪشن لاء دستياب ناهي. انهي صورت ۾، ٽرانزيڪشن صرف ڪم ٿيل ڊيٽا ڏسي سگھن ٿا، ۽ پريتم پڙهڻ ٿي سگھي ٿي. جيڪڏهن هڪ ٽرانزيڪشن داخل ٿئي ٿي ۽ نئين قطارن کي انجام ڏئي، موجوده ٽرانزيڪشن انهن کي ڏسي سگهندا جڏهن سوال ڪيو ويندو.
- اڻ پڙهيل پڙهو (گهٽ ۾ گهٽ سخت ۽ قيمتي سطح): گندي پڙهڻ جي اجازت آهي، ٽرانزيڪشن ٻين ٽرانزيڪشن پاران ٺاهيل غير معمولي تبديلين کي ڏسي سگهي ٿو. عملي طور تي، هي سطح ڪارائتو ٿي سگھي ٿو اڻڄاتل تخميني لاء، جهڙوڪ سوال
COUNT(*)ميز تي.
سطح سيرالي ٿيل ڊيٽا نسلن جي خطري کي گھٽائي ٿو، جڏهن ته لاڳو ڪرڻ لاء سڀ کان وڌيڪ مهانگو آهي ۽ نتيجي ۾ سسٽم تي تمام گهڻي مقابلي واري لوڊ. ٻين اڪيلائي جي سطحن تي عمل ڪرڻ آسان آهي، پر ڊيٽا جي نسلن جي امڪان کي وڌايو. ڪجھ DBMSs توهان کي اجازت ڏين ٿا ته هڪ ڪسٽم آئسوليشن ليول سيٽ ڪريو، ٻين کي مضبوط ترجيحات آهن ۽ سڀني سطحن کي سپورٽ نه آهي.
علحدگيءَ جي سطحن لاءِ سپورٽ اڪثر ڪري ڏنل ڊي بي ايم ايس ۾ اشتهار ڏنو ويندو آهي، پر صرف ان جي رويي جو محتاط مطالعو اهو ظاهر ڪري سگهي ٿو ته اصل ۾ ڇا ٿي رهيو آهي.
مختلف ڊي بي ايم ايسز لاءِ مختلف اڪيلائي جي سطحن تي اتفاق راءِ جو جائزو
مارٽن ڪلپمن پنهنجي منصوبي ۾ مختلف علحدگيءَ جي سطحن جو مقابلو ڪري ٿو، اتفاق راءِ جي بي ضابطگين بابت ڳالهائي ٿو، ۽ ڇا ڊيٽابيس هڪ خاص اڪيلائي جي سطح تي عمل ڪرڻ جي قابل آهي. ڪليپمين جي تحقيق ڏيکاري ٿي ته ڊيٽابيس ڊولپرز اڪيلائي جي سطح بابت ڪيئن مختلف سوچن ٿا.
Optimistic Blocking اچي ٿو بچاءُ لاءِ جڏهن ان کي برقرار رکڻ ڏکيو هوندو آهي معمولي کي.
بلاڪ ڪرڻ تمام مهانگو ٿي سگهي ٿو، نه رڳو اهو ڇو ته اهو ڊيٽابيس ۾ مقابلو وڌائي ٿو، پر ان لاءِ ته اهو ايپليڪيشن سرورز کي مسلسل ڊيٽابيس سان ڳنڍڻ جي ضرورت آهي. نيٽ ورڪ جي ڀاڱيداري خاص لاڪنگ جي حالتن کي وڌائي سگھي ٿي ۽ ڊيڊ لاڪ جي ڪري سگھي ٿي جن کي سڃاڻڻ ۽ حل ڪرڻ ڏکيو آھي. ڪيسن ۾ جتي خاص تالا لڳائڻ مناسب نه آهي، اميد رکندڙ تالا مدد ڪري ٿي.
هڪ طريقو آهي جنهن ۾ هڪ اسٽرنگ پڙهڻ وقت ان جي ورجن، چيڪسم، يا آخري ترميم جي وقت کي نظر ۾ رکندي آهي. هي توهان کي پڪ ڪرڻ جي اجازت ڏئي ٿو ته داخلا کي تبديل ڪرڻ کان پهريان ڪو ايٽمي نسخو تبديلي نه آهي:
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
انهي حالت ۾، ٽيبل کي اپڊيٽ ڪرڻ products نه ڪيو ويندو جيڪڏهن ٻيو آپريشن اڳ ۾ هن قطار ۾ تبديليون ڪيون. جيڪڏهن هن قطار تي ڪو ٻيو عمل نه ڪيو ويو، هڪ قطار لاء تبديلي ٿيندي ۽ اسان اهو چئي سگهون ٿا ته تازه ڪاري ڪامياب هئي.
گندي پڙھڻ ۽ ڊيٽا جي نقصان کان سواء ٻيون غير معمولي آھن
جڏهن اها ڊيٽا جي استحڪام تي اچي ٿي، توجهه نسل جي حالتن جي صلاحيت تي آهي جيڪا گندي پڙهڻ ۽ ڊيٽا جي نقصان جي ڪري سگھي ٿي. بهرحال، ڊيٽا جي غير معموليات اتي روڪي نه ٿيون.
اهڙي بي ضابطگين جو هڪ مثال رڪارڊنگ تحريف آهي (اسڪيوز لکڻ). تحريف کي ڳولڻ ڏکيو آهي ڇو ته اهي عام طور تي فعال طور تي نه ڳولي رهيا آهن. اهي گندي پڙهڻ يا ڊيٽا جي نقصان جي سبب نه آهن، پر ڊيٽا تي رکيل منطقي رڪاوٽن جي ڀڃڪڙي جي ڪري.
مثال طور، اچو ته هڪ مانيٽرنگ ايپليڪيشن تي غور ڪريون جنهن لاءِ هڪ آپريٽر کي هر وقت آن ڪال هجڻ جي ضرورت آهي:
BEGIN tx1; BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0 SELECT COUNT(*)
FROM operators
WHERE oncall = TRUE;
0
UPDATE operators UPDATE operators
SET oncall = TRUE SET oncall = TRUE
WHERE userId = 4; WHERE userId = 2;
COMMIT tx1; COMMIT tx2;مٿين صورتحال ۾، هڪ رڪارڊ ڪرپشن واقع ٿيندي جيڪڏهن ٻنهي ٽرانزيڪشن کي ڪاميابي سان انجام ڏنو وڃي. جيتوڻيڪ اتي ڪا به گندي پڙهڻ يا ڊيٽا نقصان نه هئا، ڊيٽا جي سالميت سمجهي وئي هئي: هاڻي ٻه ماڻهو هڪ ئي وقت تي ڪال تي سمجهيا وڃن ٿا.
سيريلائيبل آئسوليشن، اسڪيما ڊيزائن، يا ڊيٽابيس جي رڪاوٽون لکڻ جي ڪرپشن کي ختم ڪرڻ ۾ مدد ڪري سگھن ٿيون. ڊولپرز کي لازمي طور تي ترقي جي دوران اهڙن بي ضابطگين کي سڃاڻڻ جي قابل هوندو ته جيئن پيداوار ۾ انهن کان بچڻ لاءِ. ساڳئي وقت، رڪارڊنگ جي تحريف کي ڪوڊ بيس ۾ ڳولڻ تمام ڏکيو آهي. خاص طور تي وڏي سسٽم ۾، جڏهن مختلف ترقياتي ٽيمون ڪمن کي لاڳو ڪرڻ لاء ذميوار آهن ساڳئي جدولن جي بنياد تي ۽ ڊيٽا جي رسائي جي خاصيتن تي متفق نه آهن.
ڊيٽابيس ۽ صارف هميشه متفق نه آهن ته ڇا ڪجي
ڊيٽابيس جي اهم خصوصيتن مان هڪ آهي عملدرآمد آرڊر جي ضمانت، پر اهو آرڊر بذات خود سافٽ ويئر ڊولپر لاءِ شفاف نه هوندو. ڊيٽابيس ٽرانزيڪشن کي ان ترتيب سان انجام ڏين ٿا جيئن اهي وصول ڪيا وڃن، نه ته آرڊر ۾ پروگرامر ارادو ڪيو. ٽرانزيڪشن جو حڪم پيش ڪرڻ ڏکيو آهي، خاص طور تي انتهائي لوڊ ٿيل متوازي سسٽم ۾.
ترقي دوران، خاص طور تي جڏهن نان بلاڪنگ لائبريرين سان ڪم ڪندي، خراب انداز ۽ گهٽ پڙهڻ جي صلاحيت صارفين کي يقين ڏيارڻ جو سبب بڻجي سگهي ٿي ته ٽرانزيڪشن تي عمل ڪيو وڃي ٿو، جڏهن حقيقت ۾ اهي ڪنهن به ترتيب ۾ ڊيٽابيس ۾ پهچي سگهن ٿيون.
پهرين نظر ۾، هيٺ ڏنل پروگرام ۾، T1 ۽ T2 کي ترتيب سان سڏيو ويندو آهي، پر جيڪڏهن اهي فنڪشن غير بلاڪ آهن ۽ فوري طور تي نتيجو فارم ۾ واپس آڻيندا آهن. ، پوءِ ڪالن جو حڪم ان لمحن سان طئي ڪيو ويندو جڏهن اهي ڊيٽابيس ۾ داخل ٿيا:
result1 = T1() // حقيقي نتيجا واعدا آهن
نتيجو 2 = T2 ()
جيڪڏهن ايٽمي جي ضرورت آهي (يعني، يا ته سڀني عملن کي مڪمل ڪيو وڃي يا ختم ڪيو وڃي) ۽ ترتيب جي معاملن، پوء آپريشن T1 ۽ T2 کي هڪ واحد ٽرانزيڪشن ۾ انجام ڏيڻ گهرجي.
ايپليڪيشن جي سطح جي شارڊنگ کي ايپليڪيشن کان ٻاهر منتقل ڪري سگھجي ٿو
شارڊنگ هڪ ڊيٽابيس کي افقي طور تي ورهائڻ جو هڪ طريقو آهي. ڪجهه ڊيٽابيس خودڪار طريقي سان ڊيٽا کي افقي طور تي ورهائي سگھن ٿا، جڏهن ته ٻيا نٿا ڪري سگهن، يا ان تي تمام سٺو نه آهن. جڏهن ڊيٽا آرڪيٽيڪٽس / ڊولپرز اڳڪٿي ڪرڻ جي قابل هوندا آهن ته ڊيٽا ڪيئن پهچندي، اهي هن ڪم کي ڊيٽابيس ڏانهن نمائندو ڪرڻ جي بدران صارف جي جاء تي افقي ورهاڱي ٺاهي سگهن ٿا. هن عمل کي "ايپليڪيشن-سطح شارڊنگ" سڏيو ويندو آهي. (ايپليڪيشن-سطح شارڊنگ).
بدقسمتي سان، هي نالو اڪثر ڪري غلط فڪر پيدا ڪري ٿو ته شارڊنگ ايپليڪيشن سروسز ۾ رهي ٿو. حقيقت ۾، اهو ڊيٽابيس جي سامهون هڪ الڳ پرت جي طور تي لاڳو ڪري سگهجي ٿو. ڊيٽا جي ترقي ۽ اسڪيما جي ورهاڱي تي منحصر ڪري، شارڊنگ جون گهرجون ڪافي پيچيده ٿي سگهن ٿيون. ڪجھ حڪمت عمليون شايد قابليت مان فائدو حاصل ڪري سگھن ٿيون بغير ايپليڪيشن سرور کي ٻيهر ترتيب ڏيڻ جي.
هڪ فن تعمير جو هڪ مثال جنهن ۾ ايپليڪيشن سرورز کي شارڊنگ سروس کان الڳ ڪيو ويو آهي
شارڊنگ کي الڳ خدمت ۾ منتقل ڪرڻ جي صلاحيت کي وڌائي ٿو شارڊنگ جي مختلف حڪمت عملين کي استعمال ڪرڻ جي بغير ايپليڪيشنن کي ٻيهر ترتيب ڏيڻ جي. ايپليڪيشن سطح تي اهڙي شارڊنگ سسٽم جو هڪ مثال آهي. Vitess MySQL لاءِ افقي شارڊنگ مهيا ڪري ٿو ۽ گراهڪن کي اجازت ڏئي ٿو ته ان سان ڳنڍڻ جي ذريعي MySQL پروٽوڪول. سسٽم ڊيٽا کي مختلف MySQL نوڊس ۾ ورهائي ٿو جيڪي هڪ ٻئي بابت ڪجھ به نه ڄاڻندا آهن.
خودڪار اضافو خطرناڪ ٿي سگهي ٿو
AUTOINCREMENT ھڪڙو عام طريقو آھي پرائمري ڪنجيون ٺاھيو. اھڙا اڪثر ڪيس آھن جڏھن ڊيٽابيسس استعمال ڪيا ويندا آھن ID جنريٽر، ۽ ڊيٽابيس ۾ جدول آھن جيڪي سڃاڻپ ڪندڙ پيدا ڪرڻ لاءِ ٺهيل آھن. اتي ڪيترائي سبب آهن ڇو ته خودڪار واڌارو استعمال ڪندي پرائمري چابيون پيدا ڪرڻ مثالي کان پري آهي:
- ورهايل ڊيٽابيس ۾، خودڪار واڌارو هڪ سنگين مسئلو آهي. ID ٺاھڻ لاءِ، ھڪ گلوبل لاڪ گھربل آھي. ان جي بدران، توهان هڪ UUID ٺاهي سگهو ٿا: اهو مختلف ڊيٽابيس نوڊس جي وچ ۾ رابطي جي ضرورت ناهي. لاڪ سان خودڪار واڌارو تڪرار جو سبب بڻجي سگھي ٿو ۽ ورهايل حالتن ۾ داخل ٿيڻ تي ڪارڪردگي کي خاص طور تي گھٽائي سگھي ٿو. ڪجهه DBMSs (مثال طور، MySQL) کي خاص ترتيب ڏيڻ جي ضرورت پوندي ۽ ماسٽر-ماسٽر ريپليڪشن کي صحيح طريقي سان ترتيب ڏيڻ لاءِ وڌيڪ ڌيان ڏيڻ جي ضرورت پوندي. ۽ ترتيب ڏيڻ وقت غلطيون ڪرڻ آسان آھي، جيڪي رڪارڊنگ جي ناڪامي کي ڏسندا.
- ڪجھ ڊيٽابيس ۾ پرائمري ڪيز جي بنياد تي ورهاڱي واري الگورتھم آھن. لڳاتار آئي ڊيز غير متوقع گرم هنڌن جو سبب بڻجي سگهن ٿيون ۽ ڪجهه ورهاڱي تي لوڊ وڌائي ٿي جڏهن ته ٻيا بيڪار رهن ٿا.
- بنيادي ڪيچي ڊيٽابيس ۾ قطار تائين رسائي جو تيز ترين طريقو آهي. رڪارڊ کي سڃاڻڻ لاءِ بهتر طريقن سان، ترتيب وار IDs جدولن ۾ سڀ کان اهم ڪالمن کي بي معنيٰ قدرن سان ڀريل بيڪار ڪالمن ۾ بدلائي سگهن ٿيون. تنهن ڪري، جڏهن به ممڪن هجي، مهرباني ڪري هڪ عالمي طور تي منفرد ۽ قدرتي پرائمري چيڪ چونڊيو (مثال طور صارف نالو).
ڪنهن نقطي تي فيصلو ڪرڻ کان اڳ، انڊيڪسنگ، ورهاڱي، ۽ شارڊنگ تي خودڪار وڌندڙ IDs ۽ UUIDs جي اثر تي غور ڪريو.
اسٽيل ڊيٽا مفيد ٿي سگهي ٿي ۽ تالا لڳائڻ جي ضرورت ناهي
Multiversion Concurrency Control (MVCC) ڪيترن ئي تسلسل جي ضرورتن کي لاڳو ڪري ٿو جن تي مختصر طور تي مٿي ذڪر ڪيو ويو آهي. ڪجھ ڊيٽابيس (مثال طور، پوسٽ گريس، اسپنر) MVCC استعمال ڪن ٿا "فيڊ" ٽرانزيڪشن کي سنيپ شاٽ سان - ڊيٽابيس جا پراڻا ورجن. سنيپ شاٽ ٽرانزيڪشن پڻ ترتيب ڏئي سگھجن ٿيون تسلسل کي يقيني بڻائڻ لاءِ. جڏهن هڪ پراڻي سنيپ شاٽ مان پڙهي، پراڻي ڊيٽا پڙهي ويندي آهي.
ٿورڙي پراڻي ڊيٽا کي پڙهڻ مفيد ٿي سگهي ٿو، مثال طور، جڏهن ڊيٽا مان اينالائيٽڪس ٺاهيندي يا لڳ ڀڳ مجموعي قدرن جي حساب سان.
ورثي واري ڊيٽا سان ڪم ڪرڻ جو پهريون فائدو گهٽ ويڪرائي آهي (خاص طور تي جيڪڏهن ڊيٽابيس مختلف جغرافين ۾ ورهايل هجي). ٻيو اهو آهي ته صرف پڙهڻ وارا ٽرانزيڪشن لاڪ فري آهن. هي ايپليڪيشنن لاءِ هڪ اهم فائدو آهي جيڪي گهڻو پڙهي رهيا آهن ، جيستائين اهي اسٽيل ڊيٽا کي سنڀالي سگهن.
ايپليڪيشن سرور مقامي نقل مان ڊيٽا پڙهي ٿو جيڪا 5 سيڪنڊن جي تاريخ کان ٻاهر آهي، جيتوڻيڪ جديد نسخو پئسفڪ سمنڊ جي ٻئي پاسي موجود آهي
DBMSs خودڪار طريقي سان پراڻن نسخن کي صاف ڪن ٿا ۽، ڪجهه حالتن ۾، توهان کي درخواست تي ڪرڻ جي اجازت ڏين ٿا. مثال طور، Postgres صارفين کي ڪرڻ جي اجازت ڏئي ٿو VACUUM درخواست تي، ۽ پڻ وقتي طور تي هن آپريشن کي خودڪار طريقي سان انجام ڏئي ٿو. اسپنر هڪ ڪلاڪ کان پراڻن تصويرن کان نجات حاصل ڪرڻ لاءِ ڪچرو ڪليڪٽر هلائي ٿو.
ڪنهن به وقت ذريعن تحريف جي تابع آهن
ڪمپيوٽر سائنس ۾ بهترين رکيل راز اهو آهي ته سڀ ٽائمنگ APIs ڪوڙ. حقيقت ۾، اسان جي مشين کي صحيح موجوده وقت جي خبر ناهي. ڪمپيوٽرن ۾ ڪوارٽز ڪرسٽل هوندا آهن جيڪي وائبريشن پيدا ڪندا آهن جيڪي وقت کي برقرار رکڻ لاءِ استعمال ٿيندا آهن. تنهن هوندي، اهي ڪافي صحيح نه آهن ۽ ٿي سگهي ٿو اڳتي / پوئتي صحيح وقت کان پوئتي. شفٽ في ڏينهن 20 سيڪنڊن تائين پهچي سگهي ٿو. تنهن ڪري، اسان جي ڪمپيوٽرن تي وقت وقتي طور تي هڪ نيٽ ورڪ سان هم وقت سازي هجڻ ضروري آهي.
NTP سرورز هم وقت سازي لاءِ استعمال ڪيا ويندا آهن، پر هم وقت سازي جو عمل پاڻ نيٽ ورڪ جي دير جي تابع هوندو آهي. جيتوڻيڪ ساڳئي ڊيٽا سينٽر ۾ NTP سرور سان هم وقت سازي ڪجهه وقت وٺندو آهي. اهو واضح آهي ته عوامي NTP سرور سان ڪم ڪري سگھي ٿو اڃا به وڏي تحريف.
ايٽمي ڪلاڪ ۽ انهن جا GPS هم منصب موجوده وقت کي طئي ڪرڻ لاءِ بهتر آهن، پر اهي قيمتي آهن ۽ پيچيده سيٽ اپ جي ضرورت آهي، تنهنڪري اهي هر ڪار تي نصب نه ٿي سگهن. انهي جي ڪري، ڊيٽا سينٽر هڪ ٽائرڊ انداز استعمال ڪندا آهن. ايٽمي ۽/يا GPS گھڙيون صحيح وقت ڏيکارينديون آھن، جنھن کان پوءِ اھو ثانوي سرورز ذريعي ٻين مشينن ڏانھن نشر ڪيو ويندو آھي. هن جو مطلب اهو آهي ته هر مشين کي صحيح وقت کان هڪ خاص آفٽ جو تجربو ٿيندو.
صورتحال حقيقت جي ڪري بگڙيل آهي ته ايپليڪيشنون ۽ ڊيٽابيس اڪثر ڪري مختلف مشينن تي واقع آهن (جيڪڏهن مختلف ڊيٽا سينٽرن ۾ نه هجي). ان ڪري، وقت مختلف ٿيندو نه رڳو ڊي بي نوڊس تي مختلف مشينن ۾ ورهايل. اهو ايپليڪيشن سرور تي پڻ مختلف هوندو.
Google TrueTime هڪ مڪمل طور تي مختلف طريقو وٺندو آهي. گهڻا ماڻهو يقين رکن ٿا ته گوگل جي هن هدايت ۾ پيش رفت ائٽمي ۽ GPS جي گھڙين تي عام منتقلي جي وضاحت ڪئي وئي آهي، پر اهو صرف وڏي تصوير جو حصو آهي. ھتي آھي ڪيئن TrueTime ڪم ڪندو آھي:
- TrueTime استعمال ڪري ٿو ٻه مختلف ذريعا: GPS ۽ ايٽمي ڪلاڪ. اهي واچون غير لاڳاپيل ناڪامي موڊ آهن. تفصيل لاءِ ڏسو صفحو 5 - لڳ ڀڳ ترجمو.)، تنهنڪري انهن جو گڏيل استعمال قابل اعتماد وڌائي ٿو.
- TrueTime ھڪڙو غير معمولي API آھي. اهو وقت کي هڪ وقفي جي طور تي موٽائي ٿو ماپ جي غلطي ۽ ان ۾ ٺهيل غير يقيني صورتحال سان. وقت ۾ حقيقي لمحو وقفي جي مٿين ۽ هيٺين حدن جي وچ ۾ آهي. اسپنر، گوگل جو ورهايل ڊيٽابيس، بس انتظار ڪري ٿو جيستائين اهو چوڻ لاءِ محفوظ ناهي ته موجوده وقت حد کان ٻاهر آهي. اهو طريقو سسٽم ۾ ڪجهه دير سان متعارف ڪرايو آهي، خاص طور تي جيڪڏهن ماسٽرن تي غير يقيني صورتحال تمام گهڻي آهي، پر عالمي سطح تي ورهايل صورتحال ۾ به صحيحيت کي يقيني بڻائي ٿي.
اسپنر جا حصا TrueTime استعمال ڪندا آهن، جتي TT.now() هڪ وقفو موٽائي ٿو، تنهنڪري اسپنر صرف ان نقطي تائين سمهي ٿو جتي اهو يقين ڪري سگهجي ٿو ته موجوده وقت هڪ خاص نقطو گذري چڪو آهي.
موجوده وقت کي طئي ڪرڻ ۾ گھٽتائي جي درستگي جو مطلب آھي اسپينر آپريشن جي مدت ۾ اضافو ۽ ڪارڪردگي ۾ گھٽتائي. اهو ئي سبب آهي ته اهو ضروري آهي ته سڀ کان وڌيڪ ممڪن درستگي برقرار رکڻ جي باوجود مڪمل طور تي درست واچ حاصل ڪرڻ ناممڪن آهي.
دير جا ڪيترائي مطلب آهن
جيڪڏهن توهان درجنين ماهرن کان پڇو ته دير ڇا آهي، توهان کي شايد مختلف جواب ملندا. DBMS ۾ ويڪرائي اڪثر ڪري سڏيو ويندو آهي "ڊيٽابيس ويڪرائي" ۽ مختلف آهي جيڪو ڪلائنٽ طرفان سمجهي ويو آهي. حقيقت اها آهي ته ڪلائنٽ نيٽ ورڪ جي دير ۽ ڊيٽابيس جي دير جي رقم جو مشاهدو ڪري ٿو. ويڪرائي جي قسم کي الڳ ڪرڻ جي صلاحيت نازڪ آهي جڏهن وڌندڙ مسئلن کي ڊيب ڪرڻ. جڏهن ميٽرڪ گڏ ڪرڻ ۽ ڏيکاريندي، هميشه ٻنهي قسمن تي نظر رکڻ جي ڪوشش ڪريو.
ڪارڪردگي جي ضرورتن کي هڪ مخصوص ٽرانزيڪشن لاء جائزو وٺڻ گهرجي
ڪڏهن ڪڏهن ڊي بي ايم ايس جي ڪارڪردگي جون خاصيتون ۽ ان جون حدون لکڻ/پڙهڻ جي ذريعي ۽ ويڪرائي جي لحاظ کان بيان ڪيل آهن. هي اهم سسٽم جي پيراگرافن جو هڪ عام جائزو مهيا ڪري ٿو، پر جڏهن نئين ڊي بي ايم ايس جي ڪارڪردگي جو جائزو وٺڻ، هڪ وڌيڪ جامع طريقو آهي الڳ الڳ تنقيدي عملن جو جائزو وٺڻ (هر سوال ۽/يا ٽرانزيڪشن لاء). مثال:
- ٽيبل X (50 ملين قطارن سان) ۾ مخصوص رڪاوٽن ۽ قطار جي پيڊنگ سان لاڳاپيل جدولن ۾ نئين قطار داخل ڪرڻ وقت throughput ۽ lateency لکو.
- ڪنهن خاص صارف جي دوستن جي دوستن کي ظاهر ڪرڻ ۾ دير ٿي جڏهن دوستن جو سراسري تعداد 500 آهي.
- هڪ صارف جي تاريخ مان مٿين 100 داخلائن کي ٻيهر حاصل ڪرڻ ۾ دير جڏهن استعمال ڪندڙ 500 ٻين استعمال ڪندڙن کي في ڪلاڪ X داخلائن سان گڏ ڪري ٿو.
تشخيص ۽ تجربا شايد اهڙا نازڪ ڪيس شامل ڪري سگھن ٿا جيستائين توهان کي يقين نه هجي ته ڊيٽابيس ڪارڪردگي گهرجن کي پورو ڪري ٿو. انگن اکرن جو ساڳيو قاعدو پڻ هن وقفي کي حساب ۾ رکي ٿو جڏهن ويڪرائي ميٽرڪ گڏ ڪرڻ ۽ SLO جو تعين ڪرڻ.
هر آپريشن لاءِ ميٽرڪ گڏ ڪرڻ وقت اعليٰ ڪارڪردگيءَ کان آگاهه رهو. اعلي طاقت ڊيبگنگ ڊيٽا حاصل ڪرڻ لاء لاگز، واقعا گڏ ڪرڻ، يا ورهايل ٽريڪنگ استعمال ڪريو. مضمون ۾ "»توهان پاڻ کي دير سان ڊيبگنگ جي طريقن سان واقف ڪري سگهو ٿا.
Nested ٽرانزيڪشن خطرناڪ ٿي سگهي ٿو
نه هر DBMS nested ٽرانزيڪشن کي سپورٽ ڪندو آهي، پر جڏهن اهي ڪندا آهن، اهڙي ٽرانزيڪشن جي نتيجي ۾ ٿي سگهي ٿو غير متوقع غلطيون جيڪي هميشه ڳولڻ آسان نه هوندا آهن (يعني، اهو واضح هجڻ گهرجي ته ڪجهه قسم جي غير معمولي آهي).
توهان استعمال ڪرڻ کان پاسو ڪري سگهو ٿا nested ٽرانزيڪشن کي استعمال ڪندي ڪلائنٽ لائبريريون جيڪي انهن کي ڳولي ۽ بائي پاس ڪري سگهن ٿيون. جيڪڏهن nested ٽرانزيڪشن کي ڇڏي نه ٿو سگهجي، انهن تي عمل ڪرڻ ۾ خاص خيال رکو ته جيئن اڻڄاتل حالتن کان بچڻ لاءِ جتي مڪمل ٿيل ٽرانزيڪشن nested ماڻهن جي ڪري حادثاتي طور ختم ٿي وڃن.
مختلف تہن ۾ ٽرانزيڪشن کي گڏ ڪرڻ غير متوقع طور تي غير متوقع ٽرانزيڪشن جي ڪري سگھي ٿو، ۽ ڪوڊ پڙهڻ جي قابل نقطي نظر کان، اهو ليکڪ جي ارادن کي سمجهڻ ڏکيو بڻائي سگھي ٿو. هيٺ ڏنل پروگرام تي هڪ نظر وٺو:
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();مٿي ڏنل ڪوڊ جو نتيجو ڇا ٿيندو؟ ڇا اهو ٻنهي ٽرانزيڪشن کي واپس آڻيندو، يا صرف اندروني هڪ؟ ڇا ٿيندو جيڪڏهن اسان لائبريرين جي ڪيترن ئي تہن تي ڀروسو ڪندا آهيون جيڪي اسان لاءِ ٽرانزيڪشن جي تخليق کي شامل ڪن ٿا؟ ڇا اسان اهڙن ڪيسن کي سڃاڻڻ ۽ سڌارڻ جي قابل ٿي سگهنداسين؟
تصور ڪريو ھڪڙي ڊيٽا پرت سان گھڻن عملن سان (مثال طور newAccount) اڳ ۾ ئي پنهنجي ٽرانزيڪشن ۾ لاڳو ڪيو ويو آهي. ڇا ٿيندو جيڪڏهن توهان انهن کي هلائيندا آهيو انهن کي اعليٰ سطحي ڪاروباري منطق جي حصي جي طور تي جيڪو پنهنجي ٽرانزيڪشن ۾ هلندو آهي؟ ان صورت ۾ اڪيلائي ۽ تسلسل ڇا هوندو؟
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}اهڙن لامحدود سوالن جا جواب ڳولڻ بدران، بهتر آهي ته نراسائي ٽرانزيڪشن کان پاسو ڪجي. سڀ کان پوء، توهان جي ڊيٽا پرت آساني سان اعلي سطحي عملن کي انجام ڏئي سگهي ٿي بغير پنهنجي ٽرانزيڪشن ٺاهڻ جي. ان کان علاوه، ڪاروباري منطق پاڻ هڪ ٽرانزيڪشن کي شروع ڪرڻ، ان تي عمل ڪرڻ، هڪ ٽرانزيڪشن کي انجام ڏيڻ يا ختم ڪرڻ جي قابل آهي.
function newAccount(id string) {
Accounts.create(id)
}
// In main application:
with newTransaction():
// Read some data from database for configuration.
// Generate an ID from the ID service.
Accounts.create(id)
Uploads.create(id) // create upload queue for the user.ٽرانزيڪشن کي ايپليڪيشن اسٽيٽ سان ڳنڍيل نه هجڻ گهرجي
ڪڏهن ڪڏهن ڪجهه قدرن کي تبديل ڪرڻ لاءِ ٽرانزيڪشن ۾ ايپليڪيشن اسٽيٽ کي استعمال ڪرڻ يا سوال جي پيٽرولن کي ٽائيڪ ڪرڻ لاءِ پرجوش آهي. غور ڪرڻ لاء نازڪ nuance درخواست جي صحيح گنجائش آهي. ڪلائنٽ اڪثر ڪري ٽرانزيڪشن کي ٻيهر شروع ڪندا آهن جڏهن نيٽ ورڪ مسئلا آهن. جيڪڏهن ٽرانزيڪشن پوء هڪ رياست تي منحصر آهي جيڪا ڪنهن ٻئي عمل سان تبديل ٿي رهي آهي، اهو ڊيٽا جي نسل جي امڪان جي لحاظ سان غلط قيمت چونڊيندو. ٽرانزيڪشن کي ايپليڪيشن ۾ ڊيٽا جي نسل جي حالتن جي خطري تي غور ڪرڻ گهرجي.
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...مٿيون ٽرانزيڪشن هر دفعي ان تي عمل ڪيو ويندو، آخري نتيجو کان سواءِ ترتيب نمبر کي وڌائيندو. جيڪڏهن ڪمٽ نيٽ ورڪ جي مسئلن جي ڪري ناڪام ٿئي ٿي، درخواست هڪ مختلف ترتيب نمبر سان عمل ڪيو ويندو جڏهن توهان ٻيهر ڪوشش ڪندا.
سوالن جا منصوبا توهان کي ڊيٽابيس بابت گهڻو ڪجهه ٻڌائي سگھن ٿا
سوال منصوبه بندي ڪندڙ اهو طئي ڪن ٿا ته هڪ سوال کي ڊيٽابيس ۾ ڪيئن عمل ڪيو ويندو. اهي پڻ درخواستن جو تجزيو ڪن ٿا ۽ انهن کي موڪلڻ کان پهريان انهن کي بهتر ڪن ٿا. منصوبه بندي ڪندڙ صرف سگنلن جي بنياد تي ڪجھ ممڪن تخمينو مهيا ڪري سگھن ٿا. مثال طور، هيٺ ڏنل سوال لاء بهترين ڳولا جو طريقو ڇا آهي؟
SELECT * FROM articles where author = "rakyll" order by title;نتيجن کي ٻن طريقن سان حاصل ڪري سگهجي ٿو:
- مڪمل ٽيبل اسڪين: توھان جدول ۾ ھر داخلي کي ڏسي سگھو ٿا ۽ مضمونن کي ھڪڙي ملندڙ ليکڪ جي نالي سان واپس ڪري سگھو ٿا، ۽ پوء انھن کي ترتيب ڏيو.
- انڊيڪس اسڪين: توهان هڪ انڊيڪس استعمال ڪري سگهو ٿا ملندڙ IDs ڳولڻ لاءِ، اهي قطارون حاصل ڪريو، ۽ پوءِ انهن کي ترتيب ڏيو.
سوال جي رٿابندي ڪندڙ جو ڪم اهو طئي ڪرڻ آهي ته ڪهڙي حڪمت عملي بهترين آهي. اهو غور ڪرڻ جي قابل آهي ته سوال جي رٿابندي ڪندڙ صرف محدود پيش گوئي صلاحيتون آهن. اهو خراب فيصلا ڪري سگهي ٿو. DBAs يا ڊولپرز انھن کي استعمال ڪري سگھن ٿا انھن کي تشخيص ڪرڻ ۽ ٺيڪ ڪرڻ لاءِ ناقص ڪارڪردگي سوالن کي. DBMS جا نوان ورزن سوالن جي رٿابندي ڪندڙن کي ترتيب ڏئي سگھن ٿا، ۽ خود تشخيص مدد ڪري سگھن ٿا جڏھن ڊيٽابيس کي اپڊيٽ ڪرڻ ۾ جيڪڏھن نئون ورزن ڪارڪردگي جي مسئلن جي ڪري ٿي. سست سوال لاگ، دير جي مسئلي جي رپورٽ، يا عمل جي وقت جا انگ اکر انهن سوالن جي نشاندهي ڪرڻ ۾ مدد ڪري سگھن ٿيون جن کي اصلاح جي ضرورت آهي.
سوال منصوبه بندي ڪندڙ طرفان پيش ڪيل ڪجهه ميٽرڪ شور جي تابع ٿي سگھي ٿي (خاص طور تي جڏهن ويڪرائي يا سي پي يو جي وقت جو اندازو لڳائڻ). شيڊيولرز لاءِ سٺو اضافو اوزار آهن عمل جي رستي کي ٽريڪ ڪرڻ ۽ ٽريڪ ڪرڻ لاءِ. اهي توهان کي اهڙين مسئلن جي تشخيص ڪرڻ جي اجازت ڏين ٿا (افسوس، نه سڀئي ڊي بي ايم ايس اهڙا اوزار مهيا ڪن ٿا).
آن لائين لڏپلاڻ ڏکيو پر ممڪن آهي
آن لائين لڏپلاڻ، لائيو لڏپلاڻ، يا حقيقي وقت جي لڏپلاڻ جو مطلب آهي هڪ ڊيٽابيس کان ٻئي ڏانهن منتقل ٿيڻ کان سواء بغير ڪنهن وقت يا ڊيٽا جي ڪرپشن. لائيو لڏپلاڻ ڪرڻ آسان آهي جيڪڏهن منتقلي ساڳئي DBMS/انجڻ جي اندر ٿئي ٿي. صورتحال وڌيڪ پيچيده ٿي ويندي آهي جڏهن مختلف ڪارڪردگي ۽ اسڪيما گهرجن سان گڏ نئين ڊي بي ايم ايس ڏانهن منتقل ٿيڻ ضروري آهي.
هتي مختلف آن لائين لڏپلاڻ جا ماڊل آهن. هتي انهن مان هڪ آهي:
- ٻنهي ڊيٽابيس ۾ ڊبل داخلا کي فعال ڪريو. هن اسٽيج تي نئين ڊيٽابيس ۾ سڀ ڊيٽا نه آهي، پر صرف تازو ڊيٽا کي قبول ڪري ٿو. هڪ دفعو توهان کي پڪ آهي ته، توهان اڳتي وڌي سگهو ٿا ايندڙ قدم ڏانهن.
- ٻنهي ڊيٽابيس مان پڙهڻ کي فعال ڪريو.
- سسٽم کي ترتيب ڏيو ته جيئن پڙهڻ ۽ لکڻ جو ڪم بنيادي طور تي نئين ڊيٽابيس تي ڪيو وڃي.
- پراڻي ڊيٽابيس ڏانهن لکڻ بند ڪريو جڏهن ته ان مان ڊيٽا پڙهڻ جاري رکو. هن مرحلي تي، نئون ڊيٽابيس اڃا تائين ڪجهه ڊيٽا کان خالي آهي. انهن کي پراڻي ڊيٽابيس مان نقل ڪيو وڃي.
- پراڻو ڊيٽابيس صرف پڙهڻ لاءِ آهي. پراڻي ڊيٽابيس مان گم ٿيل ڊيٽا کي نئين کي نقل ڪريو. لڏپلاڻ مڪمل ٿيڻ کان پوء، نئين ڊيٽابيس ڏانهن رستن کي تبديل ڪريو، ۽ پراڻي کي روڪيو ۽ ان کي سسٽم مان حذف ڪريو.
اضافي معلومات لاء، آئون رابطو ڪرڻ جي صلاح ڪريان ٿو , جيڪو تفصيل ڏئي ٿو Stripe جي لڏپلاڻ واري حڪمت عملي هن ماڊل جي بنياد تي.
ڊيٽابيس ۾ هڪ اهم اضافو غير متوقع طور تي اضافو آهي
ڊيٽابيس جي ترقي ان جي پيماني سان لاڳاپيل غير متوقع مسئلن جي ڪري ٿي. وڌيڪ اسان هڪ ڊيٽابيس جي اندروني جوڙجڪ بابت ڄاڻون ٿا، بهتر اسان اڳڪٿي ڪري سگهون ٿا ته اهو ڪيئن ٿيندو. تنهن هوندي به، ڪجهه لمحن جي اڳڪٿي ڪرڻ اڃا به ناممڪن آهي.
جيئن ته بنياد وڌندو آهي، ڊيٽا جي مقدار ۽ نيٽ ورڪ بينڊوڊٿ جي ضرورتن جي حوالي سان پوئين مفروضا ۽ اميدون پراڻي ٿي سگهن ٿيون. اهو تڏهن آهي جڏهن سوال پيدا ٿئي ٿو وڏن ڊيزائن جي اوور هالز، وڏي پيماني تي آپريشنل بهتري، ٻيهر سوچڻ، يا ٻين DBMSs ڏانهن لڏپلاڻ جو امڪاني مسئلن کان بچڻ لاء.
پر اهو نه سوچيو ته موجوده ڊيٽابيس جي اندروني ڍانچي جي شاندار ڄاڻ صرف ضروري آهي. نوان اسڪيل پاڻ سان گڏ نوان اڻڄاڻ به آڻيندا. اڻڄاتل درد پوائنٽون، اڻڄاتل ڊيٽا جي ورڇ، اڻڄاتل بينڊوڊٿ ۽ هارڊويئر مسئلا، ڪڏهن به وڌندڙ ٽرئفڪ ۽ نوان نيٽ ورڪ حصا توهان کي توهان جي ڊيٽابيس جي طريقيڪار، ڊيٽا ماڊل، ترتيب ڏيڻ واري ماڊل، ۽ ڊيٽابيس جي سائيز تي ٻيهر غور ڪرڻ تي مجبور ڪندا.
...
جنهن وقت مون هن مضمون کي شايع ڪرڻ جي باري ۾ سوچڻ شروع ڪيو، منهنجي اصل لسٽ ۾ اڳ ۾ ئي پنج وڌيڪ شيون موجود هيون. پوءِ وڏو انگ آيو ٻيو ڇا ڍڪي سگهجي ٿو بابت. تنهن ڪري، آرٽيڪل گهٽ ۾ گهٽ واضح مسئلن تي ڌيان ڏئي ٿو جيڪي وڌ کان وڌ ڌيان جي ضرورت آهي. بهرحال، هن جو مطلب اهو ناهي ته موضوع ختم ٿي ويو آهي ۽ مان هاڻي منهنجي مستقبل جي مواد ۾ ان ڏانهن واپس نه ويندس ۽ موجوده ۾ تبديلي نه ڪندس.
پي ايس
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com