نوټ. ژباړه: جانا دوګان په ګوګل کې تجربه لرونکې انجینر ده چې اوس مهال په Go کې لیکل شوي د شرکت تولید خدماتو مشاهده کولو کې کار کوي. په دې مقاله کې، چې د انګلیسي ژبو لیدونکو په منځ کې خورا شهرت ترلاسه کړ، هغې په 17 ټکو کې د DBMSs په اړه مهم تخنیکي توضیحات راټول کړل (او ځینې وختونه په عمومي توګه ویشل شوي سیسټمونه) چې د لویو / غوښتنې غوښتنلیکونو پراختیا کونکو لپاره په پام کې نیولو لپاره ګټور دي.
د کمپیوټر سیسټمونو ډیری برخه د دوی حالت تعقیبوي او په وینا یې، د معلوماتو ذخیره کولو سیسټم ته اړتیا لري. ما د اوږدې مودې په اوږدو کې د ډیټابیسونو په اړه پوهه راټوله کړه، د ډیزاین غلطیو کولو په لاره کې چې د معلوماتو له لاسه ورکولو او بندیدو لامل شو. په سیسټمونو کې چې د معلوماتو لوی مقدار پروسس کوي ، ډیټابیس د سیسټم جوړښت په زړه کې پروت دی او د غوره حل په غوره کولو کې د کلیدي عنصر په توګه عمل کوي. د دې حقیقت سره سره چې د ډیټابیس کار ته نږدې پاملرنه کیږي، هغه ستونزې چې د غوښتنلیک پراختیا کونکي یې د اټکل کولو هڅه کوي اکثرا یوازې د یخ کندې برخه وي. د مقالو پدې لړۍ کې ، زه ځینې نظرونه شریکوم چې د پراختیا کونکو لپاره به ګټور وي څوک چې پدې برخه کې تخصص نلري.
- تاسو نېکمرغه یاست که چیرې 99,999٪ وخت شبکه ستونزې نه رامینځته کوي.
- ACID د ډیری مختلف شیانو معنی لري.
- هر ډیټابیس خپل میکانیزمونه لري چې د دوام او جلا کیدو ډاډ ترلاسه کړي.
- د خوشبین بلاک کول د ژغورنې لپاره راځي کله چې د معمول ساتل ستونزمن وي.
- د خندا لوستلو او د معلوماتو له لاسه ورکولو سربیره نورې ګډوډي شتون لري.
- ډیټابیس او کارونکي تل د عمل په جریان کې موافق ندي.
- د غوښتنلیک په کچه شارډینګ د غوښتنلیک څخه بهر لیږدول کیدی شي.
- په اتوماتیک ډول وده کول خطرناک کیدی شي.
- زاړه معلومات ګټور کیدی شي او د بندولو ته اړتیا نلري.
- تحریفونه د هر وخت سرچینې لپاره معمول دي.
- ځنډ ډیری معنی لري.
- د فعالیت اړتیاوې باید د یوې ځانګړې راکړې ورکړې لپاره و ارزول شي.
- تړل شوي لیږدونه خطرناک کیدی شي.
- لیږدونه باید د غوښتنلیک حالت پورې تړلي نه وي.
- د پوښتنې پلان کونکي کولی شي تاسو ته د ډیټابیسونو په اړه ډیر څه ووایی.
- آنلاین مهاجرت ستونزمن دی، مګر امکان لري.
- په ډیټابیس کې د پام وړ زیاتوالی د غیر وړاندوینې زیاتوالي ته اړتیا لري.
زه غواړم د دې مقالې پخوانۍ نسخې په اړه د دوی د فیډبیک لپاره ایمانویل اوډیک، ریین هینریچ او نورو څخه مننه وکړم.
تاسو نېکمرغه یاست که چیرې 99,999٪ وخت شبکه ستونزې نه رامینځته کوي.
پوښتنه د دې په اړه پاتې ده چې د شبکې عصري ټیکنالوژي څومره د باور وړ دي او څو ځله سیسټمونه د شبکې د ناکامۍ له امله ښکته کیږي. د دې مسلې په اړه معلومات کم دي او څیړنه اکثرا د ځانګړو شبکو، تجهیزاتو او پرسونل سره د لوی سازمانونو لخوا تسلط لري.
د سپنر لپاره د 99,999٪ د شتون نرخ سره (د ګوګل په نړیواله کچه توزیع شوی ډیټابیس)، ګوګل ادعا کوي چې یوازې ستونزې د شبکې سره تړاو لري. په ورته وخت کې، شرکت خپل ځانګړي شبکه د لوړ شتون "اصلي ستن" بولي. مطالعه په 2014 کې ترسره شوي، یو له ننګونو څخه ""، کوم چې پیټر دویچ په 1994 کې جوړ کړ. ایا شبکه واقعیا د اعتبار وړ ده؟
د لوی شرکتونو څخه بهر پراخه څیړنه، د پراخ انټرنیټ لپاره ترسره شوي، په ساده ډول شتون نلري. د لوی لوبغاړو څخه کافي معلومات هم شتون نلري چې د دوی د پیرودونکو ستونزې څومره سلنه په شبکه پورې اړه لري. موږ د لوی کلاوډ چمتو کونکو شبکې سټیک کې له بندیدو څخه ښه خبر یو چې کولی شي د څو ساعتونو لپاره د انټرنیټ ټوله برخه ښکته کړي ځکه چې دا د لوړې کچې پیښې دي چې په لوی شمیر خلکو او شرکتونو اغیزه کوي. د شبکې بندیدل کولی شي په ډیرو نورو قضیو کې ستونزې رامینځته کړي، حتی که دا ټولې قضیې د پام وړ نه وي. د بادل خدماتو پیرودونکي هم د ستونزو د لاملونو په اړه هیڅ نه پوهیږي. که چیرې کومه ناکامي شتون ولري، نو دا تقریبا ناممکن ده چې دا د خدماتو چمتو کونکي اړخ کې د شبکې تېروتنې ته منسوب شي. د دوی لپاره، د دریمې ډلې خدمتونه تور بکسونه دي. د لوی خدمت چمتو کونکي پرته د اغیزو ارزونه ناممکن ده.
د دې په پام کې نیولو سره چې لوی لوبغاړي د دوی سیسټمونو په اړه راپور ورکوي، دا خوندي دی چې ووایاست چې تاسو په بخت کې یاست که د شبکې ستونزې یوازې د احتمالي ځنډ وخت مسلو یوه کوچنۍ سلنه حساب کړي. د شبکې مخابراتو لاهم د داسې غیر معمولي شیانو څخه رنځ وړي لکه د هارډویر ناکامۍ ، د ټوپولوژي بدلونونه ، د اداري تشکیلاتو بدلونونه ، او د بریښنا بندیدل. په دې وروستیو کې، زه حیران وم چې پوه شوم چې د احتمالي ستونزو لیست اضافه شوی (هو، تاسو سم اوریدلي دي).
ACID د ډیری مختلف شیانو معنی لري
د ACID لنډیز د اټومي، ثبات، جلا کولو، اعتبار لپاره ولاړ دی. د معاملو دا ملکیتونه د دې لپاره دي چې د ناکامۍ، غلطیو، هارډویر ناکامیو، او داسې نورو په صورت کې د دوی اعتبار یقیني کړي. د ACID یا ورته سکیمونو پرته، دا به ستونزمنه وي چې د غوښتنلیک پراختیا کونکو لپاره توپیر وکړي چې دوی د څه لپاره مسؤل دي او ډیټابیس د څه لپاره مسؤل دی. د ارتباطي معاملو ډیری ډیټابیسونه هڅه کوي چې د ACID سره مطابقت ولري، مګر نوې طریقې لکه NoSQL د ACID لیږد پرته ډیری ډیټابیسونو ته وده ورکړې ځکه چې پلي کول ګران دي.
کله چې زه لومړی صنعت ته داخل شوم، زموږ تخنیکي مشر په دې اړه خبرې وکړې چې د ACID مفهوم څومره اړونده و. د عادلانه کیدو لپاره، ACID د سخت تطبیق معیار پر ځای یو ناڅاپه توضیح ګڼل کیږي. نن ورځ زه دا خورا ګټور وموم ځکه چې دا د مسلو ځانګړې کټګورۍ راپورته کوي (او د ممکنه حلونو لړۍ وړاندیز کوي).
هر DBMS د ACID سره مطابقت نلري؛ په ورته وخت کې، د ډیټابیس پلي کول چې د ACID ملاتړ کوي د اړتیاو سیټ په مختلف ډول پوهیږي. یو له هغه دلیلونو څخه چې ولې د ACID پلي کول پیچلي دي د ډیری سوداګرۍ بندونو له امله دي چې د ACID اړتیاو پلي کولو لپاره باید ترسره شي. جوړونکي کولی شي خپل ډیټابیسونه د ACID سره مطابقت لرونکي په توګه وړاندې کړي، مګر د څنډې قضیې تفسیر ممکن په ډراماتیک ډول توپیر ولري، لکه څنګه چې د "ممکنه" پیښو اداره کولو میکانیزم به وي. لږترلږه، پراختیا کونکي کولی شي د اساس پلي کولو پیچلتیاو په اړه د لوړې کچې پوهه ترلاسه کړي ترڅو د دوی ځانګړي چلند او ډیزاین سوداګرۍ بندونو سم پوهه ترلاسه کړي.
د دې په اړه بحث چې ایا MongoDB د ACID اړتیاو سره مطابقت لري حتی د 4 نسخه خوشې کیدو وروسته هم دوام لري. MongoDB د اوږدې مودې لپاره نه دی ملاتړ شوی ، که څه هم د ډیفالټ ډیټا په هرو 60 ثانیو کې له یو ځل څخه ډیر ډیسک ته ژمن و. لاندې سناریو تصور کړئ: یو غوښتنلیک دوه لیکنې پوسټ کوي (w1 او w2). MongoDB په بریالیتوب سره w1 ذخیره کوي، مګر w2 د هارډویر ناکامۍ له امله ورک شوی.
ډیاګرام د سناریو انځوروي. MongoDB مخکې له دې چې ډیسک ته ډاټا ولیکي کریش کیږي
ډیسک ته ژمنتیا یوه ګرانه پروسه ده. د پرله پسې ژمنو څخه مخنیوي سره، پراختیا کونکي د اعتبار په لګښت د ثبت کولو فعالیت ښه کوي. MongoDB اوس مهال د ننوتلو ملاتړ کوي، مګر ناپاک لیکونه لاهم د معلوماتو بشپړتیا اغیزه کولی شي ځکه چې لاګونه په هر 100ms کې د ډیفالټ لخوا نیول کیږي. دا، د لاګونو او په دوی کې وړاندې شوي بدلونونو لپاره ورته سناریو لاهم ممکنه ده، که څه هم خطر خورا ټیټ دی.
هر ډیټابیس خپل دوام او د جلا کولو میکانیزمونه لري
د ACID اړتیاو څخه، ثبات او انزوا د مختلف پلي کولو ترټولو لوی شمیر ویاړي ځکه چې د سوداګرۍ لړۍ پراخه ده. دا باید وویل شي چې دوام او جلا کول خورا ګران دندې دي. دوی همغږي ته اړتیا لري او د معلوماتو دوام لپاره سیالي زیاتوي. د ستونزې پیچلتیا د پام وړ وده کوي کله چې دا اړینه وي چې ډیټابیس په افقی ډول په ډیری ډیټا مرکزونو کې اندازه کړئ (په ځانګړي توګه که دوی په مختلف جغرافیایی سیمو کې موقعیت ولري). د لوړې کچې ثبات ترلاسه کول خورا ستونزمن دي، ځکه چې دا هم شتون کموي او د شبکې ویش زیاتوي. د دې پدیدې نور عمومي توضیحاتو لپاره ، زه تاسو ته مشوره درکوم چې مراجعه وکړئ . دا هم د یادونې وړ ده چې غوښتنلیکونه کولی شي د لږ مقدار متضادیت اداره کړي، او پروګرام کونکي کولی شي د ستونزې لنډیزونه په ښه توګه درک کړي ترڅو په غوښتنلیک کې اضافي منطق پلي کړي پرته له دې چې دا اداره کولو لپاره په ډیټابیس باندې ډیر تکیه وکړي.
DBMSs اکثرا د انزوا مختلف کچې چمتو کوي. د غوښتنلیک پراختیا کونکي کولی شي د دوی غوره توبونو پراساس خورا مؤثره غوره کړي. ټیټ انزوا د سرعت زیاتوالي ته اجازه ورکوي، مګر د ډیټا ریس خطر هم زیاتوي. لوړ موصلیت دا احتمال کموي، مګر کار ورو کوي او کولی شي د سیالۍ لامل شي، کوم چې به په بیس کې داسې بریکونه رامینځته کړي چې ناکامي پیل شي.
د موجوده همغږي موډلونو بیاکتنه او د دوی ترمنځ اړیکو
د SQL معیار یوازې څلور د جلا کولو کچه تعریفوي، که څه هم په تیوري او عمل کې ډیری نور شتون لري. د موجوده همغږي ماډلونو عالي کتنه وړاندې کوي. د مثال په توګه، د ګوګل سپنر د ساعت همغږي کولو سره د بهرني سریال وړتیا تضمینوي، او که څه هم دا یو سخت انزوا پرت دی، دا د معیاري جلا کولو پرتونو کې نه تعریف شوی.
د SQL معیار لاندې د انزوا کچه یادونه کوي:
- سریالیزیږي (خورا سخت او ګران): د لړۍ وړ اجرا کول د ځینې ترتیب شوي لیږد اجرا کولو په څیر ورته تاثیر لري. په ترتیب سره اجرا کول پدې معنی دي چې هر راتلونکی لیږد یوازې د تیر بشپړیدو وروسته پیل کیږي. دا باید په پام کې ونیول شي چې کچه سریالیزیږي ډیری وختونه په تشریح کې د توپیرونو له امله د تش په نامه سنیپ شاټ انزوا په توګه پلي کیږي (د مثال په توګه په اوریکل کې)، که څه هم د سنیپ شاټ جلا کول پخپله د SQL معیاري استازیتوب نه کوي.
- د تکرار وړ لوستل: په اوسني لیږد کې غیر راجع شوي ریکارډونه د اوسني لیږد لپاره شتون لري، مګر د نورو معاملو لخوا رامینځته شوي بدلونونه (لکه نوي قطارونه) .
- ژمن لوستل: د راکړې ورکړې لپاره غیر ژمن معلومات شتون نلري. په دې حالت کې، لیږد یوازې ژمنې ډاټا لیدلی شي، او د فینټم لوستل ممکن واقع شي. که چیرې یو لیږد نوي قطارونه داخل کړي او ترسره کړي، اوسنی لیږد به د پوښتنې په وخت کې د لیدلو وړ وي.
- بې ژمنې ولولئ (لږترلږه سخت او ګرانه کچه): ناپاک لوستلو ته اجازه ورکول کیږي، لیږد کولی شي د نورو معاملو لخوا رامینځته شوي غیر محدود بدلونونه وګوري. په عمل کې، دا کچه ممکن د لږ اټکلونو لپاره ګټور وي، لکه پوښتنې
COUNT(*)پر میز
کچه د سریالیزیږي د ډیټا ریسونو خطر کموي ، پداسې حال کې چې پلي کول خورا ګران دي او پایله یې په سیسټم کې ترټولو لوړ رقابتي بار دی. د انزوا نورې کچې پلي کول اسانه دي ، مګر د ډیټا ریسونو احتمال ډیروي. ځینې DBMSs تاسو ته اجازه درکوي چې د دودیز انزوا کچه وټاکئ، نور یې قوي غوره توبونه لري او ټولې کچې ملاتړ نه کوي.
د انزوا کچې لپاره ملاتړ اکثرا په ورکړل شوي DBMS کې اعلان کیږي، مګر یوازې د دې چلند یوه دقیقه مطالعه کولی شي ښکاره کړي چې واقعا څه پیښیږي.
د بیالبیلو DBMSs لپاره په مختلف انزوا کچه کې د همغږۍ ګډوډي بیاکتنه
مارتین کلیپمن په خپله پروژه کې د انزوا کولو مختلفې کچې پرتله کوي، د همغږۍ انډولونو په اړه خبرې کوي، او ایا ډیټابیس د دې توان لري چې د یو ځانګړي انزوا کچه تعقیب کړي. د کلیپمن څیړنه ښیي چې د ډیټابیس جوړونکي د انزوا کچې په اړه څومره توپیر لري.
د خوشبین بلاک کول د ژغورنې لپاره راځي کله چې د معمول ساتل ستونزمن وي.
بلاک کول خورا ګران کیدی شي ، نه یوازې دا چې دا په ډیټابیس کې سیالي ډیروي ، بلکه دا هم د دې لپاره چې دا د غوښتنلیک سرورونو ته اړتیا لري چې په دوامداره توګه ډیټابیس سره وصل شي. د شبکې قطع کول کولی شي د ځانګړي تالاشۍ حالتونه لا پسې خراب کړي او د بندیدو لامل شي چې پیژندل او حل کول یې ستونزمن دي. په هغه حالتونو کې چې ځانګړي تالاشۍ مناسب نه وي، خوشبین تالاشي مرسته کوي.
یوه طریقه ده چې په هغه کې د تار لوستلو په وخت کې د هغې نسخه، چکسم، یا د وروستي ترمیم وخت په پام کې نیول کیږي. دا تاسو ته اجازه درکوي چې ډاډ ترلاسه کړئ چې د ننوتلو بدلولو دمخه د اټومي نسخې بدلون شتون نلري:
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 په ترتیب سره ویل کیږي، مګر که دا افعال غیر بلاک وي او سمدلاسه پایله په فورمه کې بیرته راولي. ، بیا د تلیفونونو ترتیب به د هغه شیبو لخوا ټاکل کیږي کله چې دوی ډیټابیس ته ننوتل:
نتیجه 1 = T1 () // ریښتینې پایلې ژمنې دي
پایله 2 = T2 ()
که اټوميیت ته اړتیا وي (یعنې یا ټول عملیات باید بشپړ شي یا لغوه شي) او د ترتیب مسله وي، نو د T1 او T2 عملیات باید په یوه معامله کې ترسره شي.
د غوښتنلیک په کچه شارډینګ د غوښتنلیک څخه بهر لیږدول کیدی شي
شارډینګ د ډیټابیس په افقی ډول ویشلو طریقه ده. ځینې ډیټابیسونه کولی شي په اوتومات ډول ډاټا په افقی ډول تقسیم کړي، پداسې حال کې چې نور نشي کولی، یا په دې کې خورا ښه نه وي. کله چې د ډیټا معماران / پراختیا کونکي د دې وړتیا لري چې دقیقا وړاندوینه وکړي چې ډیټا ته به څنګه لاسرسی ومومي ، دوی کولی شي ډیټابیس ته د دې کار سپارلو پرځای د کارونکي ځای کې افقی برخې رامینځته کړي. دې پروسې ته "د غوښتنلیک کچه شارډینګ" ویل کیږي (د غوښتنلیک په کچه شارډینګ).
له بده مرغه، دا نوم اکثرا دا غلط فهم رامینځته کوي چې د غوښتنلیک خدماتو کې شارډینګ ژوند کوي. په حقیقت کې، دا د ډیټابیس مخې ته د جلا پرت په توګه پلي کیدی شي. د ډیټا وده او سکیما تکرارونو پورې اړه لري ، د شارډینګ اړتیاوې خورا پیچلې کیدی شي. ځینې ستراتیژۍ ممکن د تکرار کولو وړتیا څخه ګټه پورته کړي پرته لدې چې د غوښتنلیک سرورونو بیا ځای په ځای کړي.
د جوړښت یوه بیلګه په کوم کې چې د غوښتنلیک سرورونه د شارډینګ خدمت څخه جلا شوي
په جلا خدمت کې د شارډینګ حرکت کول د غوښتنلیکونو بیا ځای پرځای کولو اړتیا پرته د مختلف شارډینګ ستراتیژیو کارولو وړتیا پراخه کوي. د غوښتنلیک په کچه د داسې شارډینګ سیسټم یوه بیلګه ده. ویټیس د MySQL لپاره افقی شارډینګ چمتو کوي او پیرودونکو ته اجازه ورکوي چې د MySQL پروتوکول له لارې دې سره وصل شي. سیسټم ډیټا په مختلف MySQL نوډونو کې قطع کوي چې د یو بل په اړه هیڅ نه پوهیږي.
په اتوماتیک ډول وده کول خطرناک کیدی شي
AUTOINCREMENT د ابتدايي کیلي جوړولو لپاره یوه عامه لاره ده. ډیری وختونه داسې پیښې شتون لري کله چې ډیټابیس د ID جنریټرونو په توګه کارول کیږي، او ډیټابیس میزونه لري چې د پیژندونکي تولید لپاره ډیزاین شوي. ډیری دلیلونه شتون لري چې ولې د اتوماتیک زیاتوالي په کارولو سره لومړني کیلي رامینځته کول له مثالي څخه لرې دي:
- په ویشل شوي ډیټابیس کې، د اتوماتیک زیاتوالی یوه جدي ستونزه ده. د ID د جوړولو لپاره، یو نړیوال لاک ته اړتیا ده. پرځای یې، تاسو کولی شئ یو UUID تولید کړئ: دا د مختلف ډیټابیس نوډونو ترمنځ تعامل ته اړتیا نلري. د لاکونو سره د اتوماتیک زیاتوالی کولی شي د شخړې لامل شي او په توزیع شوي حالتونو کې د ننوتلو فعالیت د پام وړ کم کړي. ځینې DBMSs (د مثال په توګه، MySQL) ممکن د ماسټر ماسټر نقل په سمه توګه تنظیم کولو لپاره ځانګړي ترتیب او ډیر احتیاط ته اړتیا ولري. او د تنظیم کولو پرمهال د غلطیو کول اسانه دي ، کوم چې به د ریکارډ ناکامۍ لامل شي.
- ځینې ډیټابیسونه د لومړني کیلي پراساس د تقسیم کولو الګوریتمونه لري. پرله پسې IDs کولی شي د غیر متوقع ګرم ځایونو لامل شي او په ځینو برخو کې بار ډیر کړي پداسې حال کې چې نور بې کاره پاتې کیږي.
- لومړنۍ کیلي په ډیټابیس کې قطار ته د لاسرسي ترټولو ګړندۍ لاره ده. د ریکارډونو پیژندلو لپاره د غوره لارو سره، ترتیب شوي IDs کولی شي په جدولونو کې خورا مهم کالم د بې معنی ارزښتونو څخه ډک بې ګټې کالم ته واړوي. نو، هرکله چې امکان ولري، مهرباني وکړئ په نړیواله کچه یو ځانګړی او طبیعي کلیدي غوره کړئ (د بیلګې په توګه کارن نوم).
مخکې له دې چې د یوې تګلارې په اړه پریکړه وکړئ، په لیست کولو، ویشلو، او شارډینګ باندې د اتوماتیک زیاتیدونکي IDs او UUIDs اغیزې په پام کې ونیسئ.
زاړه معلومات ګټور کیدی شي او تالاشي ته اړتیا نلري
د ملټي ورشن کنورنسی کنټرول (MVCC) د دوامدارۍ ډیری اړتیاوې پلي کوي چې پورته یې په لنډه توګه بحث شوی. ځینې ډیټابیسونه (د مثال په توګه، پوسټګریس، سپنر) د سنیپ شاټونو سره د "فیډ" لیږد لپاره MVCC کاروي — د ډیټابیس زاړه نسخې. د سنیپ شاټ لیږد هم د دوام ډاډ ترلاسه کولو لپاره سریالیز کیدی شي. کله چې د زاړه سنیپ شاټ څخه لوستل کیږي، زاړه ډاټا لوستل کیږي.
د یو څه زاړه ډیټا لوستل ګټور کیدی شي ، د مثال په توګه ، کله چې له ډیټا څخه تحلیلونه رامینځته کول یا د نږدې مجموعي ارزښتونو محاسبه کول.
د میراث ډیټا سره د کار کولو لومړۍ ګټه ټیټ ځنډ دی (په ځانګړي توګه که ډیټابیس په بیلابیلو جغرافیو کې توزیع شوی وي). دوهم دا چې یوازې د لوستلو لیږدونه له بند څخه پاک دي. دا د غوښتنلیکونو لپاره د پام وړ ګټه ده چې ډیر لوستل کیږي، تر هغه چې دوی کولی شي زاړه ډاټا اداره کړي.
د اپلیکیشن سرور د محلي نقل څخه ډاټا لوستل کوي چې د نیټې څخه 5 ثانیې دي، حتی که وروستی نسخه د آرام سمندر په بل اړخ کې شتون ولري
DBMSs په اوتومات ډول زړې نسخې پاکوي او په ځینو مواردو کې تاسو ته اجازه درکوي دا په غوښتنه ترسره کړئ. د مثال په توګه، Postgres کاروونکو ته اجازه ورکوي چې وکړي VACUUM د غوښتنې سره سم، او په دوره توګه دا عملیات په اوتومات ډول ترسره کوي. سپنر د کثافاتو راټولونکی چلوي ترڅو له یو ساعت څخه زاړه عکسونو څخه ځان خلاص کړي.
هر وخت سرچینې د تحریف تابع دي
د کمپیوټر ساینس کې ترټولو غوره ساتل شوی راز دا دی چې ټول وخت APIs دروغ دي. په حقیقت کې، زموږ ماشینونه دقیق اوسني وخت نه پوهیږي. کمپیوټرونه د کوارټز کرسټالونه لري چې د وخت ساتلو لپاره کارول کیږي کمپنونه رامینځته کوي. په هرصورت، دوی کافي دقیق ندي او ممکن د دقیق وخت څخه مخکې / وروسته پاتې وي. بدلون کولی شي هره ورځ 20 ثانیو ته ورسیږي. له همدې امله، زموږ په کمپیوټر کې وخت باید په منظمه توګه د شبکې سره همغږي شي.
د NTP سرورونه د همغږي کولو لپاره کارول کیږي، مګر د همغږي کولو پروسه پخپله د شبکې ځنډ سره مخ ده. حتی په ورته ډیټا مرکز کې د NTP سرور سره همغږي کول یو څه وخت نیسي. دا روښانه ده چې د عامه NTP سرور سره کار کول حتی د لوی تحریف لامل کیدی شي.
اټومي ساعتونه او د دوی د GPS همکاران د اوسني وخت ټاکلو لپاره غوره دي، مګر دوی ګران دي او پیچلي ترتیب ته اړتیا لري، نو دوی نشي کولی په هر موټر کې نصب شي. د دې له امله، د معلوماتو مرکزونه یو اړخیزه طریقه کاروي. اټومي او/یا GPS ساعتونه دقیق وخت ښیي، وروسته له هغه چې دا د ثانوي سرورونو له لارې نورو ماشینونو ته خپریږي. دا پدې مانا ده چې هر ماشین به د دقیق وخت څخه یو مشخص آفسیټ تجربه کړي.
وضعیت د دې حقیقت له امله خراب شوی چې غوښتنلیکونه او ډیټابیسونه اکثرا په مختلف ماشینونو کې موقعیت لري (که نه په مختلف ډیټا مرکزونو کې). پدې توګه ، وخت به نه یوازې د DB نوډونو کې توپیر ولري چې په مختلف ماشینونو کې توزیع شوي. دا به د غوښتنلیک سرور کې هم توپیر ولري.
Google TrueTime یو بشپړ مختلف طریقه اخلي. ډیری خلک پدې باور دي چې پدې لار کې د ګوګل پرمختګ د اټومي او GPS ساعتونو ته د بندیز لیږد لخوا تشریح شوی، مګر دا یوازې د لوی انځور برخه ده. دلته د TrueTime څنګه کار کوي:
- TrueTime دوه مختلف سرچینې کاروي: GPS او اټومي ساعتونه. دا ساعتونه غیر مربوط ناکامي طریقې لري. [د جزیاتو لپاره 5 پاڼه وګورئ - نږدې ژباړه.)نو د دوی ګډ استعمال اعتبار زیاتوي.
- TrueTime یو غیر معمولي API لري. دا د اندازه کولو تېروتنې او ناڅرګندتیا سره د وقفې په توګه وخت بیرته راګرځوي. په وخت کې ریښتینې شیبه د وقفې د پورتنۍ او ښکته سرحدونو تر مینځ موقعیت لري. سپنر، د ګوګل ویشل شوی ډیټابیس، په ساده ډول انتظار کوي تر هغه چې دا خوندي وي چې ووایی چې اوسنی وخت د حد څخه بهر دی. دا میتود په سیسټم کې یو څه ځنډ معرفي کوي ، په ځانګړي توګه که چیرې د ماسټرانو په اړه ناڅرګندتیا لوړه وي ، مګر حتی په نړیواله کچه توزیع شوي وضعیت کې درستیت تضمینوي.
د سپنر برخې TrueTime کاروي، چیرته چې TT.now() وقفه بیرته راګرځوي، نو سپنر په ساده ډول تر هغه وخت پورې خوب کوي چیرې چې دا ډاډه وي چې اوسنی وخت یو ټاکلی وخت تیر شوی.
د اوسني وخت په ټاکلو کې دقت کمول د سپنر عملیاتو په موده کې زیاتوالی او په فعالیت کې کمښت معنی لري. له همدې امله دا مهمه ده چې ترټولو ممکنه دقت وساتل شي حتی که څه هم په بشپړ ډول دقیق ساعت ترلاسه کول ناممکن دي.
ځنډ ډیری معنی لري
که تاسو د لسګونو متخصصینو څخه وپوښتئ چې ځنډ څه شی دی، تاسو به شاید مختلف ځوابونه ترلاسه کړئ. په DBMS کې ځنډ اکثرا د "ډیټابیس ځنډ" په نوم یادیږي او د هغه څه څخه توپیر لري چې د پیرودونکي لخوا پیژندل کیږي. حقیقت دا دی چې پیرودونکي د شبکې ځنډ او د ډیټابیس ځنډ مجموعه ګوري. د ځنډ د ډول جلا کولو وړتیا خورا مهم دی کله چې د مخ پر ودې ستونزو ډیبګ کول. کله چې میټریکونه راټول او ښکاره کړئ، تل هڅه وکړئ چې دواړه ډولونه په پام کې ونیسئ.
د فعالیت اړتیاوې باید د یوې ځانګړې راکړې ورکړې لپاره و ارزول شي
ځینې وختونه د DBMS فعالیت ځانګړتیاوې او د هغې محدودیتونه د لیکلو / لوستلو له لارې او ځنډ سره مشخص شوي. دا د کلیدي سیسټم پیرامیټرو عمومي عمومي کتنه وړاندې کوي، مګر کله چې د نوي DBMS فعالیت ارزونه کوي، یو ډیر جامع طریقه دا ده چې په جلا توګه مهم عملیات (د هرې پوښتنې او/یا لیږد لپاره) ارزونه وکړي. بېلګې:
- په جدول X (د 50 ملیون قطارونو سره) د ټاکل شوي محدودیتونو او په اړونده جدولونو کې د قطار پیډینګ سره د نوي قطار داخلولو په وخت کې throughput او ځنډ ولیکئ.
- د یو ځانګړي کارونکي د ملګرو ملګرو ښودلو کې ځنډ کله چې د ملګرو اوسط شمیر 500 وي.
- د کارونکي له تاریخ څخه د غوره 100 ننوتونو په ترلاسه کولو کې ځنډ کله چې کارونکي په هر ساعت کې د X ننوتلو سره 500 نور کاروونکي تعقیبوي.
ارزونه او تجربه ممکن دا ډول مهمې قضیې شاملې کړي تر هغه چې تاسو ډاډه نه یاست چې ډیټابیس د فعالیت اړتیاوې پوره کوي. د ګوتو ورته قاعده دا ماتول هم په پام کې نیسي کله چې د ځنډ میټریک راټولوي او د SLO ټاکي.
د هر عملیات لپاره میټریک راټولولو پر مهال د لوړ کارډینالیت څخه خبر اوسئ. د لوړ ځواک ډیبګ کولو ډیټا ترلاسه کولو لپاره لاګ ، د پیښې راټولول ، یا توزیع شوي تعقیب وکاروئ. په مقاله کې "» تاسو کولی شئ ځان د ځنډ د ډیبګ کولو میتودونو سره آشنا کړئ.
تړل شوي لیږدونه خطرناک کیدی شي
هر DBMS د نیست شوي لیږدونو ملاتړ نه کوي، مګر کله چې دوی کوي، دا ډول لیږدونه د غیر متوقع غلطیو پایله کیدی شي چې تل یې موندل اسانه ندي (دا باید څرګنده وي چې یو ډول ګډوډي شتون لري).
تاسو کولی شئ د پیرودونکي کتابتونونو په کارولو سره د نیست شوي لیږدونو کارولو څخه مخنیوی وکړئ چې کولی شي دوی کشف او تیر کړي. که چیرې نیست شوي لیږدونه پریښودل نشي، د دوی په پلي کولو کې ځانګړې پاملرنه وکړئ ترڅو د غیر متوقع حالتونو څخه مخنیوی وشي چیرې چې بشپړ شوي لیږدونه په ناڅاپي توګه د نیست شوي اشخاصو له امله لغوه کیږي.
په بیلابیلو پرتونو کې د لیږدونو راټولول کولی شي د غیر متوقع نیست شوي لیږد لامل شي، او د کوډ لوستلو وړتیا له نظره، دا کولی شي د لیکوال په اراده پوهیدل ستونزمن کړي. لاندې پروګرام ته یو نظر وګورئ:
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.لیږدونه باید د غوښتنلیک حالت پورې تړلي نه وي
ځینې وختونه دا د ځینې ارزښتونو بدلولو یا د پوښتنو پیرامیټونو ټیکولو لپاره په معاملو کې د غوښتنلیک حالت کارولو لپاره لیوالتیا ده. د پام وړ مهم ټکی د غوښتنلیک سمه ساحه ده. پیرودونکي ډیری وختونه لیږدونه بیا پیل کوي کله چې د شبکې ستونزې شتون ولري. که چیرې راکړه ورکړه بیا په یو حالت پورې اړه ولري چې د کوم بل پروسې لخوا بدلیږي ، نو دا ممکن د معلوماتو ریس احتمال پورې اړوند غلط ارزښت غوره کړي. لیږدونه باید په غوښتنلیک کې د ډیټا ریس شرایطو خطر په پام کې ونیسي.
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 نوې نسخې کولی شي د پوښتنې پلان کونکي تنظیم کړي، او د ځان تشخیص کولی شي د ډیټابیس تازه کولو کې مرسته وکړي که چیرې نوې نسخه د فعالیت ستونزې رامینځته کړي. ورو د پوښتنو لاګونه، د ځنډ مسلې راپورونه، یا د اجرا کولو وخت احصایې کولی شي د هغو پوښتنو پیژندلو کې مرسته وکړي چې اصلاح ته اړتیا لري.
د پوښتنې پلانر لخوا وړاندې شوي ځینې میترونه ممکن د شور تابع وي (په ځانګړي توګه کله چې د ځنډ یا CPU وخت اټکل کول). د مهالویش کونکو لپاره ښه اضافه د اجرا کولو لارې تعقیب او تعقیب لپاره وسیلې دي. دوی تاسو ته اجازه درکوي چې دا ډول ستونزې تشخیص کړئ (افسوس، ټول DBMSs داسې وسایل نه وړاندې کوي).
آنلاین مهاجرت ستونزمن دی مګر ممکن دی
آنلاین مهاجرت، ژوندی مهاجرت، یا ریښتیني وخت مهاجرت پدې معنی دی چې له یو ډیټابیس څخه بل ډیټابیس ته پرته له ځنډ یا ډیټا فساد څخه حرکت کول. ژوندی مهاجرت د ترسره کولو لپاره اسانه دی که چیرې لیږد په ورته DBMS/انجن کې واقع شي. وضعیت نور هم پیچلی کیږي کله چې د مختلف فعالیت او سکیما اړتیاو سره نوي DBMS ته لیږدول اړین وي.
د آنلاین مهاجرت بیلابیل ماډلونه شتون لري. دلته یو له دوی څخه دی:
- په دواړو ډیټابیسونو کې دوه ځله ننوتل فعال کړئ. په دې مرحله کې نوی ډیټابیس ټول معلومات نلري، مګر یوازې وروستي ډاټا مني. یوځل چې تاسو پدې ډاډه یاست ، تاسو کولی شئ بل ګام ته لاړشئ.
- د دواړو ډیټابیسونو څخه لوستل فعال کړئ.
- سیسټم تنظیم کړئ ترڅو لوستل او لیکل په لومړي سر کې په نوي ډیټابیس کې ترسره شي.
- زاړه ډیټابیس ته د لیکلو مخه ونیسئ پداسې حال کې چې د هغې څخه ډاټا لوستلو ته دوام ورکړئ. پدې مرحله کې، نوی ډیټابیس لاهم د ځینو معلوماتو څخه بې برخې دی. دوی باید د زاړه ډیټابیس څخه کاپي شي.
- زوړ ډیټابیس یوازې د لوستلو وړ دی. له زاړه ډیټابیس څخه ورک شوي ډاټا نوي ته کاپي کړئ. د مهاجرت بشپړیدو وروسته ، نوي ډیټابیس ته لارې بدل کړئ ، او زاړه ودروئ او له سیسټم څخه یې حذف کړئ.
د نورو معلوماتو لپاره، زه د تماس سپارښتنه کوم ، کوم چې د دې ماډل پراساس د سټیپ د مهاجرت ستراتیژي توضیح کوي.
په ډیټابیس کې د پام وړ زیاتوالی د غیر وړاندوینې زیاتوالي ته اړتیا لري
د ډیټابیس وده د دې پیمانه پورې اړوند غیر متوقع ستونزو لامل کیږي. هرڅومره چې موږ د ډیټابیس داخلي جوړښت په اړه پوهیږو ، هومره ښه موږ وړاندوینه کولی شو چې دا به څنګه اندازه شي. په هرصورت، ځینې شیبې لاهم د وړاندوینې لپاره ناممکن دي.
لکه څنګه چې اساس وده کوي ، د ډیټا حجم او د شبکې بینډ ویت اړتیاو په اړه پخوانۍ انګیرنې او توقعات ممکن زوړ شي. دا هغه وخت دی چې د لوی ډیزاین بیاکتنې، په لویه پیمانه عملیاتي پرمختګونو، بیا غور کولو، یا نورو DBMSs ته د احتمالي ستونزو څخه مخنیوي لپاره د مهاجرت پوښتنه راپورته کیږي.
مګر فکر مه کوئ چې د موجوده ډیټابیس داخلي جوړښت عالي پوهه یوازینی شی دی چې اړین دی. نوې ترازو به له دوی سره نوي نامعلوم راوړي. د غیر متوقع درد ټکي، د معلوماتو غیر مساوي توزیع، غیر متوقع بینډ ویت او هارډویر مسلې، تل مخ په زیاتیدونکي ترافیک او د شبکې نوي برخې به تاسو دې ته اړ کړي چې ستاسو د ډیټابیس چلند، د ډیټا ماډل، د ګمارلو ماډل، او د ډیټابیس اندازې بیاکتنه وکړي.
...
په هغه وخت کې چې ما د دې مقالې خپرولو په اړه فکر پیل کړ، زما په اصلي لیست کې لا دمخه پنځه نور توکي وو. بیا یو لوی شمیر راغی د هغه څه په اړه چې نور پوښل کیدی شي. له همدې امله، مقاله لږ تر لږه واضح ستونزو ته اشاره کوي چې اعظمي پاملرنې ته اړتیا لري. په هرصورت، دا پدې معنی نه ده چې موضوع ختمه شوې ده او زه به نور په خپلو راتلونکو موادو کې بیرته راګرځم او په اوسني کې به بدلون ونه کړم.
PS
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «".
سرچینه: www.habr.com