NewSQL = NoSQL+ACID

تر دې وروستیو پورې، Odnoklassniki په ریښتیني وخت کې پروسس شوي شاوخوا 50 TB ډیټا په SQL سرور کې زیرمه کړي. د داسې حجم لپاره، د SQL DBMS په کارولو سره د ګړندي او د اعتماد وړ، او حتی د معلوماتو مرکز ناکامۍ-زغم وړ لاسرسي چمتو کول تقریبا ناممکن دي. عموما، په داسې قضیو کې، د NoSQL ذخیره کولو څخه یو کارول کیږي، مګر هرڅه NoSQL ته لیږدول کیدی نشي: ځینې ادارې د ACID لیږد تضمین ته اړتیا لري.

دا موږ د NewSQL ذخیره کارولو ته لاره هواره کړه، دا یو DBMS دی چې د NoSQL سیسټمونو غلط برداشت، اندازه کولو او فعالیت چمتو کوي، مګر په ورته وخت کې د ACID ساتل د کلاسیک سیسټمونو سره آشنا دي. د دې نوي ټولګي لږ کار صنعتي سیسټمونه شتون لري، نو موږ دا ډول سیسټم پخپله پلي کړو او په سوداګریزو عملیاتو کې یې واچوو.

دا څنګه کار کوي او څه پیښ شوي - د کټ لاندې ولولئ.

نن ورځ، د Odnoklassniki میاشتني لیدونکي له 70 ملیون څخه ډیر ځانګړي لیدونکي دي. موږ موږ په غوره پنځو کې یو په نړۍ کې ترټولو لوی ټولنیز شبکې، او د شلو سایټونو څخه چې کاروونکي یې ډیر وخت تیروي. د OK زیربنا خورا لوړ بارونه اداره کوي: په هر مخ کې له یو ملیون څخه ډیر HTTP غوښتنې/sec. د 8000 څخه د زیاتو ټوټو د سرور بیړۍ برخې یو بل ته نږدې موقعیت لري - د مسکو په څلورو ډیټا مرکزونو کې ، کوم چې د دوی ترمینځ د 1 ms څخه لږ د شبکې ځنډ ته اجازه ورکوي.

موږ له 2010 راهیسې کاسیندرا کاروو، د 0.6 نسخه سره پیل کیږي. نن ورځ په لسګونو کلسترونه په فعالیت کې دي. ترټولو ګړندی کلستر په هره ثانیه کې له 4 ملیون څخه ډیر عملیات پروسس کوي ، او ترټولو لوی 260 TB ذخیره کوي.

په هرصورت، دا ټول عادي NoSQL کلسترونه دي چې د ذخیره کولو لپاره کارول کیږي کمزوری همغږی شوی ډاټا موږ غوښتل د اصلي دوامداره ذخیره ځای په ځای کړو، د مایکروسافټ SQL سرور، کوم چې د Odnoklassniki له تاسیس راهیسې کارول شوی. په ذخیره کې د 300 څخه ډیر د SQL سرور معیاري نسخه ماشینونه شامل وو، کوم چې د 50 TB ډیټا لري - سوداګریزې ادارې. دا ډاټا د ACID معاملو د یوې برخې په توګه تعدیل شوي او اړتیا لري لوړ دوام.

د SQL سرور نوډونو په اوږدو کې د معلوماتو توزیع کولو لپاره، موږ عمودی او افقی دواړه کاروو تقسیم کول (شیډینګ). په تاریخي توګه، موږ یو ساده ډیټا شارډینګ سکیم کارولی: هره اداره د نښه سره تړلې وه - د ادارې ID فعالیت. د ورته نښې سره ادارې په ورته SQL سرور کې ځای په ځای شوي. د ماسټر تفصیل اړیکه پلي شوې ترڅو د اصلي او ماشوم ریکارډونو نښه تل سره سمون ولري او په ورته سرور کې موقعیت ولري. په ټولنیز شبکه کې، نږدې ټول ریکارډونه د کارونکي په استازیتوب تولید شوي - پدې معنی چې د کاروونکي ټول معلومات په یو فعال سب سیسټم کې په یو سرور کې زیرمه شوي. دا دی، د سوداګرۍ لیږد تقریبا تل د یو SQL سرور څخه جدولونه شامل دي، کوم چې دا ممکنه کړې چې د محلي ACID لیږدونو په کارولو سره د معلوماتو ثبات یقیني کړي، پرته له دې چې کارولو ته اړتیا ولري. ورو او بې اعتباره ویشل شوي ACID لیږدونه.

د شارډینګ څخه مننه او د SQL ګړندی کولو لپاره:

• موږ بهرني کلیدي خنډونه نه کاروو، ځکه چې کله د ادارې ID شارډ کول ممکن په بل سرور کې واقع وي.
• موږ په DBMS CPU کې د اضافي بار له امله ذخیره شوي پروسیجرونه او محرکونه نه کاروو.
• موږ د پورتنیو ټولو او د ډیسک څخه ډیری تصادفي لوستلو له امله JOINs نه کاروو.
• د راکړې ورکړې بهر، موږ د ځنډونو کمولو لپاره د لوستلو غیر ژمن انزوا کچه کاروو.
• موږ یوازې لنډ لیږدونه ترسره کوو (په اوسط ډول له 100 ms څخه لنډ).
• موږ د ډیری ډډ لاکونو له امله څو قطار تازه کول او حذف نه کاروو - موږ په یو وخت کې یوازې یو ریکارډ تازه کوو.
• موږ تل یوازې په شاخصونو کې پوښتنې ترسره کوو - زموږ لپاره د بشپړ میز سکین پلان سره یوه پوښتنه د ډیټابیس ډیرول او د ناکامۍ لامل کیږي.

دې ګامونو موږ ته اجازه راکړه چې د SQL سرورونو څخه نږدې اعظمي فعالیت وخورئ. په هرصورت، ستونزې ورځ تر بلې زیاتې شوې. راځئ چې دوی وګورو.

د SQL سره ستونزې

• له هغه ځایه چې موږ پخپله لیکل شوي شارډینګ کارولی ، نو د نوي شارډونو اضافه کول په لاسي ډول د مدیرانو لخوا ترسره شوي. دا ټول وخت، د توزیع وړ ډیټا نقلونه د غوښتنو خدمت نه وو.
• لکه څنګه چې په جدول کې د ریکارډونو شمیر وده کوي، د داخلولو او ترمیم سرعت کمیږي؛ کله چې په موجوده جدول کې شاخصونه اضافه کیږي، سرعت د فکتور لخوا راټیټیږي؛ د شاخصونو رامینځته کول او بیا رامینځته کول د کم وخت سره پیښیږي.
• په تولید کې د SQL سرور لپاره د وینډوز لږ مقدار درلودل د زیربنا مدیریت ستونزمن کوي

خو اصلي ستونزه دا ده

د خطا زغم

د کلاسیک SQL سرور ضعیف غلط زغم لري. راځئ چې ووایو تاسو یوازې یو ډیټابیس سرور لرئ، او دا په هرو دریو کلونو کې یو ځل ناکام کیږي. د دې وخت په جریان کې سایټ د 20 دقیقو لپاره ښکته دی، کوم چې د منلو وړ دی. که تاسو 64 سرورونه لرئ، نو بیا سایټ په هرو دریو اونیو کې یو ځل ښکته کیږي. او که تاسو 200 سرورونه لرئ، نو بیا سایټ هره اونۍ کار نه کوي. دا ستونزه ده.

د SQL سرور د غلطۍ زغم ښه کولو لپاره څه کیدی شي؟ ويکيپېډيا موږ ته د جوړولو بلنه راکوي ډیر موجود کلستر: چیرې چې د هرې برخې د ناکامۍ په صورت کې یو بیک اپ شتون لري.

دا د قیمتي تجهیزاتو بیړۍ ته اړتیا لري: ډیری نقلونه، آپټیکل فایبر، شریک ذخیره، او د زیرمو شاملول د اعتبار وړ کار نه کوي: شاوخوا 10٪ سویچنګ د اصلي نوډ شاته د ریل په څیر د بیک اپ نوډ ناکامۍ سره پای ته رسیږي.

مګر د داسې خورا شتون لرونکي کلستر اصلي زیان د صفر شتون دی که چیرې د ډیټا مرکز چې پکې موقعیت لري ناکام شي. Odnoklassniki څلور د معلوماتو مرکزونه لري، او موږ اړتیا لرو چې په یوه کې د بشپړې ناکامۍ په صورت کې عملیات ډاډمن کړو.

د دې لپاره موږ کولی شو وکاروو ملټي ماسټر نقل په SQL سرور کې جوړ شوی. دا حل د سافټویر لګښت له امله خورا ګران دی او د نقل سره د پیژندل شوي ستونزو سره مخ دی - د غیر متوقع نقل سره د لیږد ځنډ او د غیر متناسب نقل سره د نقلونو پلي کولو کې ځنډ (او په پایله کې له لاسه تللي بدلونونه). متل دی لاسي شخړې حل دا اختیار زموږ لپاره په بشپړ ډول د تطبیق وړ نه کوي.

دا ټولې ستونزې یو بنسټیز حل ته اړتیا لري، او موږ یې په تفصیل سره تحلیل پیل کړل. دلته موږ اړتیا لرو د هغه څه سره اشنا شو چې د SQL سرور په عمده ډول ترسره کوي - لیږدونه.

ساده معامله

راځئ چې ساده معامله په پام کې ونیسو، د پلي شوي SQL پروګرامر له نظره: په البم کې د عکس اضافه کول. البومونه او عکسونه په مختلفو پلیټونو کې ساتل کیږي. البوم د عامه عکس کاونټر لري. بیا دا ډول معامله په لاندې مرحلو ویشل کیږي:

1. موږ البم د کیلي په واسطه لاک کوو.
2. د عکس په میز کې یو ننوتل جوړ کړئ.
3. که عکس عامه حیثیت ولري ، نو البم ته د عامه عکس کاونټر اضافه کړئ ، ریکارډ تازه کړئ او معامله وکړئ.

یا په سیډوکوډ کې:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

موږ ګورو چې د سوداګرۍ ترټولو عام سناریو د ډیټابیس څخه د غوښتنلیک سرور حافظې ته د معلوماتو لوستل دي ، یو څه بدل کړئ او نوي ارزښتونه بیرته ډیټابیس ته خوندي کړئ. معمولا په داسې معامله کې موږ ډیری ادارې، څو میزونه تازه کوو.

کله چې د راکړې ورکړې اجرا کول، د بل سیسټم څخه د ورته معلوماتو همغږي بدلون ممکن واقع شي. د مثال په توګه، انټیسپیم ممکن پریکړه وکړي چې کاروونکي یو څه شکمن دی او له همدې امله د کارونکي ټول عکسونه باید نور عامه نه وي، دوی باید د اعتدال لپاره واستول شي، دا پدې مانا ده چې photo.status یو څه بل ارزښت ته بدلول او د اړوندو شمیرو خلاصول. په ښکاره ډول، که چیرې دا عملیات د غوښتنلیک د اتومیکیت تضمین او د سیالۍ بدلونونو جلا کولو پرته ترسره شي، لکه څنګه چې اسيد، بیا به پایله هغه څه نه وي چې اړتیا ورته وي - یا به د عکس کاونټر غلط ارزښت وښیې ، یا ټول عکسونه به د اعتدال لپاره ونه لیږل شي.

ډیری ورته کوډونه، په یوه معامله کې د مختلفو سوداګریزو ادارو لاسوهنه، د اوډنوکلاسنیکي په ټول وجود کې لیکل شوي. له NoSQL څخه د مهاجرت تجربې پراساس د پیښې مطابقت موږ پوهیږو چې ترټولو لوی ننګونه (او د وخت پانګه اچونه) د کوډ رامینځته کولو څخه راځي ترڅو د ډیټا ثبات ساتلو لپاره. له همدې امله، موږ د نوي ذخیره کولو اصلي اړتیا په پام کې نیولې چې د غوښتنلیک منطق لپاره د ریښتینې ACID لیږد لپاره چمتو کول وي.

نور، لږ مهم نه، اړتیاوې وې:

• که چیرې د معلوماتو مرکز ناکام شي، نو نوي ذخیره کې لوستل او لیکل دواړه باید شتون ولري.
• د اوسني پرمختګ سرعت ساتل. دا ، کله چې د نوي ذخیره کولو سره کار کوئ ، د کوډ مقدار باید نږدې ورته وي؛ په ذخیره کې باید هیڅ اضافه کولو ته اړتیا ونلري ، د شخړو د حل لپاره الګوریتم رامینځته کړي ، د ثانوي شاخصونو ساتل ، او داسې نور.
• د نوي ذخیره کولو سرعت باید خورا لوړ وي، دواړه کله چې د معلوماتو لوستلو او د لیږد پروسس کولو په وخت کې، چې دا په مؤثره توګه معنی لري چې په اکاډمیک ډول سخت، نړیوال، مګر ورو حلونه، لکه د مثال په توګه، د تطبیق وړ ندي. دوه مرحلې ژمنې.
• په الوتنه کې اتوماتیک اندازه کول.
• د منظم ارزانه سرورونو کارول ، پرته د بهرني هارډویر پیرود ته اړتیا.
• د شرکت پراختیا کونکو لخوا د ذخیره کولو پراختیا امکان. په بل عبارت، لومړیتوب د ملکیت یا خلاصې سرچینې حلونو ته ورکړل شوی و، په غوره توګه په جاوا کې.

پریکړې، پریکړې

د ممکنه حلونو تحلیل کول، موږ دوه ممکنه جوړښت انتخابونو ته ورسیدو:

لومړی دا دی چې کوم SQL سرور واخلئ او د اړتیا وړ غلطی زغم، د پیمانه کولو میکانیزم، د ناکامۍ کلستر، د شخړو حل او توزیع شوي، معتبر او چټک ACID لیږد پلي کړئ. موږ دا اختیار خورا غیر معمولي او د کار کولو په توګه درجه بندي کړ.

دوهم اختیار دا دی چې د پلي شوي پیمانه کولو سره د چمتو شوي NoSQL ذخیره واخلئ، د ناکامۍ کلستر، د شخړې حل، او پخپله لیږد او SQL پلي کړئ. په لومړي نظر کې، حتی د SQL پلي کولو دنده، د ACID لیږدونو یادونه نه کول، د داسې کار په څیر ښکاري چې کلونه وخت ونیسي. مګر بیا موږ پوه شو چې د SQL فیچر سیټ چې موږ یې په عمل کې کاروو د ANSI SQL څخه لرې دی Cassandra CQL د ANSI SQL څخه لرې. CQL ته حتی نږدې لید لید ، موږ پوهیږو چې دا هغه څه ته نږدې و چې موږ ورته اړتیا لرو.

Cassandra او CQL

نو، د Cassandra په اړه څه په زړه پورې دي، دا کوم وړتیاوې لري؟

لومړی، دلته تاسو کولی شئ جدولونه جوړ کړئ چې د مختلف ډیټا ډولونو ملاتړ کوي؛ تاسو کولی شئ په لومړني کیلي کې SELECT یا UPDATE وکړئ.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

د ریپلیکا ډیټا ثبات یقیني کولو لپاره ، کاسندرا کاروي د نصاب تګلاره. په ساده حالت کې، دا پدې مانا ده چې کله د ورته قطار درې نقلونه د کلستر په مختلفو نوډونو کې ځای پر ځای شي، لیکنه بریالۍ ګڼل کیږي که چیرې د نوډونو اکثریت (یعنې له دریو څخه دوه) د دې لیکلو عملیات بریالیتوب تایید کړي. . د قطار ډاټا ثابته ګڼل کیږي که چیرې، د لوستلو په وخت کې، ډیری نوډونه رایه شوي وي او دوی یې تایید کړي. په دې توګه، د دریو نقلونو سره، د بشپړ او فوري معلوماتو ثبات تضمین کیږي که یو نوډ ناکام شي. دې تګلارې موږ ته اجازه راکړه چې حتی خورا معتبر سکیم پلي کړو: تل ټولو دریو عکسونو ته غوښتنې واستوئ ، د دوه ګړندي ځواب په تمه. په دې قضیه کې د دریم عکس العمل ناوخته ځواب رد شوی. یو نوډ چې په ځواب ویلو کې ناوخته وي ممکن جدي ستونزې ولري - بریکونه ، په JVM کې د کثافاتو راټولول ، په لینکس کرنل کې د مستقیم حافظې بیرته ترلاسه کول ، د هارډویر ناکامي ، له شبکې څخه جلا کیدل. په هرصورت، دا په هیڅ ډول د پیرودونکي عملیات یا ډاټا اغیزه نه کوي.

هغه طریقه چې کله موږ له دریو نوډونو سره اړیکه ونیسو او د دوو څخه ځواب ترلاسه کړو ویل کیږي اټکل: د اضافي نقلونو لپاره غوښتنه حتی مخکې لدې چې دا "لیږي" لیږل کیږي.

د Cassandra بله ګټه Batchlog دی، یو میکانیزم چې ډاډ ورکوي چې د بدلونونو یوه ډله چې تاسو یې کوئ یا په بشپړه توګه پلي شوي یا په بشپړ ډول نه پلي کیږي. دا موږ ته اجازه راکوي چې A په ACID کې حل کړو - د بکس څخه بهر اټومي.

په کاسندرا کې راکړې ورکړې ته ترټولو نږدې شی په نوم یادیږي "د لږ وزن راکړې ورکړې". مګر دوی د "اصلي" ACID معاملو څخه لرې دي: په حقیقت کې، دا یو فرصت دی CAS یوازې د یو ریکارډ څخه ډاټا باندې، د توافق په کارولو سره د درانه وزن Paxos پروتوکول په کارولو سره. له همدې امله، د داسې معاملو سرعت ټیټ دی.

هغه څه چې موږ په Cassandra کې ورک وو

نو، موږ باید په Cassandra کې د ACID اصلي لیږدونه پلي کړو. د کوم په کارولو سره موږ کولی شو په اسانۍ سره د کلاسیک DBMS دوه نورې اسانتیاوې پلي کړو: دوامداره ګړندي شاخصونه ، کوم چې موږ ته اجازه راکوي چې د ډیټا انتخاب نه یوازې د لومړني کیلي لخوا ترسره کړو ، او د مونوټونیک اتوماتیک زیاتیدونکي IDs منظم جنریټر.

C*یو

په دې توګه یو نوی DBMS زیږیدلی C*یود سرور نوډونو درې ډولونه لري:

• ذخیره - (نږدې) معیاري کاسیندرا سرورونه چې په محلي ډیسکونو کې د معلوماتو ذخیره کولو مسؤل دي. لکه څنګه چې د معلوماتو بار او حجم وده کوي، د دوی مقدار په اسانۍ سره لسګونو او سلګونو ته لیږدول کیدی شي.
• د راکړې ورکړې همغږي کوونکي - د معاملو اجرا کول ډاډمن کوي.
• پیرودونکي د غوښتنلیک سرورونه دي چې سوداګریز عملیات پلي کوي او لیږد پیل کوي. په زرګونو داسې پیرودونکي شتون لري.

د ټولو ډولونو سرورونه د یو عام کلستر برخه ده، د یو بل سره د خبرو اترو لپاره د داخلي Cassandra پیغام پروتوکول وکاروئ او خفه د کلستر معلوماتو تبادلې لپاره. د زړه بټ سره، سرورونه د دوه اړخیزو ناکامیو په اړه زده کوي، د یو واحد ډیټا سکیما ساتي - میزونه، د دوی جوړښت او نقل؛ د ویشلو سکیم، کلستر ټوپولوژي، او نور.

مراجعین

د معیاري ډرایورونو پرځای، د فایټ مراجع حالت کارول کیږي. دا ډول نوډ معلومات نه ذخیره کوي، مګر کولی شي د غوښتنې اجرا کولو لپاره د همغږي کونکي په توګه عمل وکړي، دا دی، پیرودونکي پخپله د خپلو غوښتنو همغږي کوونکي په توګه کار کوي: دا د ذخیره کولو نقلونو پوښتنه کوي او شخړې حل کوي. دا نه یوازې د معیاري ډرایور په پرتله خورا معتبر او ګړندی دی ، کوم چې د ریموټ همغږي کونکي سره اړیکې ته اړتیا لري ، بلکه تاسو ته اجازه درکوي د غوښتنو لیږد کنټرول کړئ. په پیرودونکي کې د خلاص شوي لیږد څخه بهر ، غوښتنې ذخیره کولو ته لیږل کیږي. که چیرې پیرودونکي لیږد خلاص کړي، نو د لیږد دننه ټولې غوښتنې د لیږد همغږي کونکي ته لیږل کیږي.

C* یو د لیږد همغږي کونکی

همغږي کونکی هغه څه دي چې موږ د C*one لپاره له پیل څخه پلي کړي. دا د معاملو اداره کولو، تالاشۍ، او هغه ترتیب چې په کوم کې چې لیږد پلي کیږي مسؤلیت لري.

د هر خدمت شوي لیږد لپاره، همغږي کوونکی یو مهال ویش رامینځته کوي: هر راتلونکی لیږد د تیر لیږد څخه لوی دی. څرنګه چې د کاسندرا د شخړو د حل سیسټم د مهال ویش پر بنسټ والړ دی (د دوه متضاد ریکارډونو څخه، یو د وروستي مهال ویش سره اوسنی ګڼل کیږي)، شخړه به تل د راتلونکي لیږد په ګټه حل شي. په دې توګه موږ پلي کړل د لامپورټ ساعت - په ویشل شوي سیسټم کې د شخړو د حل لپاره ارزانه لاره.

قلفونه

د انزوا د یقیني کولو لپاره، موږ پریکړه وکړه چې ترټولو ساده طریقه وکاروو - د ریکارډ لومړنۍ کیلي پراساس نا امیدي تالاشۍ. په بل عبارت، په یوه معامله کې، یو ریکارډ باید لومړی بند شي، یوازې بیا لوستل، تعدیل، او خوندي شوي. یوازې د بریالي ژمنې وروسته یو ریکارډ خلاص کیدی شي ترڅو سیالي کونکي لیږدونه وکاروي.

د دې ډول تالاشۍ پلي کول په غیر توزیع شوي چاپیریال کې ساده دي. په ویشل شوي سیسټم کې، دوه اصلي اختیارونه شتون لري: یا په کلستر کې توزیع شوي تالاشۍ پلي کړئ، یا لیږدونه توزیع کړئ ترڅو هغه لیږدونه چې ورته ریکارډ پکې شامل وي تل د ورته همغږي کونکي لخوا خدمت کیږي.

څرنګه چې زموږ په قضیه کې ډاټا دمخه په SQL کې د محلي لیږد ګروپونو ترمنځ ویشل شوي، پریکړه وشوه چې د محلي لیږد ګروپونه همغږي کونکو ته وټاکئ: یو همغږي کوونکی ټول لیږدونه د 0 څخه تر 9 پورې د ټوکنونو سره ترسره کوي، دویم - د 10 څخه تر 19 پورې ټوکن سره، او همداسی پسی. د پایلې په توګه، هر همغږي کونکي مثالونه د لیږد ګروپ ماسټر کیږي.

بیا لاکونه د همغږي کونکي په حافظه کې د banal HashMap په شکل پلي کیدی شي.

همغږي کوونکي ناکامي

څرنګه چې یو همغږي کوونکی په ځانګړې توګه د معاملو یوې ډلې ته خدمت کوي، نو دا خورا مهمه ده چې ژر تر ژره د هغې د ناکامۍ حقیقت وټاکئ ترڅو د لیږد د اجرا کولو دوهمه هڅه وخت پای ته ورسیږي. د دې ګړندي او باوري کولو لپاره ، موږ په بشپړ ډول وصل شوي کورم د غوږ بیټ پروتوکول کارولی:

د معلوماتو هر مرکز لږترلږه دوه همغږي کونکي نوډونه کوربه کوي. په دوره توګه، هر همغږي کوونکی نورو همغږي کونکو ته د زړه ضربان پیغام لیږي او د هغې د فعالیت په اړه دوی ته خبر ورکوي، او همدارنګه د زړه ضربان پیغامونه په وروستي ځل په کلستر کې له کوم همغږي کونکي څخه ترلاسه شوي.

د نورو څخه ورته معلومات د دوی د زړه د ټکان پیغامونو د یوې برخې په توګه ترلاسه کول، هر همغږي کوونکی د ځان لپاره پریکړه کوي چې کوم کلستر نوډونه کار کوي او کوم نه دي، د نصاب اصولو لخوا الرښوونه کیږي: که نوډ ایکس په کلستر کې د ډیری نوډونو څخه د نورمال په اړه معلومات ترلاسه کړي. د نوډ Y څخه د پیغامونو رسید، بیا، Y کار کوي. او برعکس، هرڅومره ژر چې اکثریت د نوډ Y څخه د ورک شوي پیغامونو راپور ورکوي، بیا Y انکار کړی. دا په زړه پورې ده چې که چیرې کورم نوډ ایکس ته خبر ورکړي چې دا نور له دې څخه پیغامونه نه ترلاسه کوي، نو نوډ ایکس به پخپله ځان ناکام ګڼي.

د زړه ضربان پیغامونه د لوړې فریکونسۍ سره لیږل کیږي، په هره ثانیه کې شاوخوا 20 ځله، د 50 ms مودې سره. په جاوا کې، دا ستونزمنه ده چې د 50 ms دننه د غوښتنلیک ځواب تضمین کړئ ځکه چې د کثافاتو راټولونکي لخوا رامینځته شوي وقفې د پرتلې اوږدوالي له امله. موږ د G1 کثافاتو راټولونکي په کارولو سره د دې ځواب وخت ترلاسه کولو توان درلود، کوم چې موږ ته اجازه راکوي چې د GC وقفې مودې لپاره هدف مشخص کړو. په هرصورت، ځینې وختونه، په ندرت سره، راټولونکی د 50 ms څخه ډیر ودروي، کوم چې کولی شي د غلط غلطی کشف لامل شي. د دې څخه د مخنیوي لپاره، همغږي کوونکي د ریموټ نوډ د ناکامۍ راپور نه ورکوي کله چې د هغې څخه د زړه ضربان لومړی پیغام ورک شي، یوازې هغه وخت چې څو یې په پرله پسې ډول ورک شوي وي. په دې توګه موږ په 200 کې د همغږي کونکي نوډ ناکامي کشف کړو. اغلی.

مګر دا کافي ندي چې ژر تر ژره پوه شي چې کوم نوډ فعالیت بند کړی. موږ باید پدې اړه یو څه وکړو.

ریزرویشن

په کلاسیک سکیم کې شامل دي، د ماسټر ناکامۍ په صورت کې، د یوې په کارولو سره نوې ټاکنې پیل کول فیشني نړیوال الګوریتم په هرصورت، دا ډول الګوریتمونه د وخت په همغږۍ او پخپله د ټاکنو پروسې اوږدوالي سره ښه پیژندل شوي ستونزې لري. موږ وکولای شو چې په بشپړ وصل شوي شبکه کې د همغږي کونکي بدیل سکیم په کارولو سره د داسې اضافي ځنډونو مخه ونیسو:

راځئ چې ووایو موږ غواړو په 50 ګروپ کې معامله اجرا کړو. راځئ چې دمخه د بدیل سکیم وټاکو، دا دی، کوم نوډونه به د اصلي همغږي کونکي د ناکامۍ په صورت کې په 50 ګروپ کې لیږدونه اجرا کړي. زموږ هدف د ډیټا مرکز ناکامۍ په صورت کې د سیسټم فعالیت ساتل دي. راځئ چې وټاکو چې لومړی ریزرو به د بل ډیټا مرکز څخه نوډ وي، او دویمه زیرمه به د دریم څخه نوډ وي. دا سکیم یو ځل غوره شوی او نه بدلیږي تر هغه چې د کلستر ټوپولوژي بدله شي، دا تر هغه چې نوي نوډونه ورته ننوځي (کوم چې په ندرت سره پیښیږي). د نوي فعال ماسټر غوره کولو طرزالعمل که چیرې زوړ ناکام شي تل به په لاندې ډول وي: لومړی ریزرو به فعال ماسټر شي، او که چیرې دا کار ودروي، دویم ریزرو به فعال ماسټر شي.

دا سکیم د نړیوال الګوریتم په پرتله خورا باوري دی، ځکه چې د نوي ماسټر فعالولو لپاره دا د زاړه ناکامۍ ټاکلو لپاره کافي دی.

مګر پیرودونکي به څنګه پوه شي چې کوم ماسټر اوس کار کوي؟ په 50 ms کې زرګونو پیرودونکو ته د معلوماتو لیږل ناممکن دي. یو حالت ممکن دی کله چې یو پیرودونکی د لیږد خلاصولو لپاره غوښتنه واستوي، تر اوسه نه پوهیږي چې دا ماسټر نور کار نه کوي، او غوښتنه به وخت پای ته ورسیږي. د دې پیښې مخنیوي لپاره ، پیرودونکي په قیاس سره د ګروپ ماسټر او د هغه دواړو زیرمو ته په یوځل کې د لیږد خلاصولو غوښتنه لیږي ، مګر یوازې هغه څوک چې دا مهال فعال ماسټر دی دې غوښتنې ته به ځواب ووایی. پیرودونکی به ټول راتلونکی اړیکي یوازې د فعال ماسټر سره د لیږد دننه ترسره کړي.

د بیک اپ ماسټرانو ځای د لیږد لپاره غوښتنې ترلاسه کړې چې د دوی نه دي د نا زیږیدلي معاملو په کتار کې ، چیرې چې دوی د یو څه وخت لپاره زیرمه شوي. که چیرې فعال ماسټر مړ شي، نو نوی ماسټر پروسس کوي چې د هغې کتار څخه د معاملو خلاصولو غوښتنه کوي او پیرودونکي ته ځواب ورکوي. که چیرې پیرودونکي دمخه د زاړه ماسټر سره معامله پرانستلې وي ، نو بیا دوهم ځواب له پامه غورځول کیږي (او په څرګنده توګه ، دا ډول معامله به بشپړ نشي او د پیرودونکي لخوا به تکرار شي).

معامله څنګه کار کوي

راځئ چې ووایو یو پیرودونکي همغږي کونکي ته غوښتنه لیږلې ترڅو د داسې او داسې یوې ادارې لپاره د داسې او داسې لومړني کیلي سره معامله پرانیزي. همغږي کوونکی دا اداره بندوي او په حافظه کې یې د تالاشۍ میز کې ځای په ځای کوي. که اړتیا وي، همغږي کوونکی دا اداره د ذخیره کولو څخه لولي او پایله شوي ډاټا د لیږد په حالت کې د همغږۍ په حافظه کې ذخیره کوي.

کله چې یو پیرودونکی غواړي په یوه معامله کې ډیټا بدل کړي، دا همغږي کوونکي ته د ادارې د تعدیل لپاره غوښتنه لیږي، او همغږي کوونکی نوی ډیټا د لیږد حالت جدول کې په حافظه کې ځای په ځای کوي. دا ثبت کول بشپړوي - ذخیره کولو ته هیڅ ثبت نه کیږي.

کله چې یو پیرودونکی د فعال لیږد د یوې برخې په توګه د خپل بدل شوي ډاټا غوښتنه کوي، همغږي کوونکي په لاندې ډول عمل کوي:

• که ID لا دمخه په راکړه ورکړه کې وي، نو بیا ډاټا د حافظې څخه اخیستل کیږي؛
• که ID په حافظه کې نه وي، نو بیا ورک شوي ډاټا د ذخیره کولو نوډونو څخه لوستل کیږي، د هغه سره یوځای شوي چې دمخه په حافظه کې دي، او پایله یې پیرودونکي ته ورکول کیږي.

پدې توګه ، پیرودونکي کولی شي خپل بدلونونه ولولي ، مګر نور پیرودونکي دا بدلونونه نه ګوري ، ځکه چې دوی یوازې د همغږي کونکي په حافظه کې زیرمه شوي؛ دوی لاهم په کاسندرا نوډونو کې ندي.

کله چې پیرودونکي ژمنې لیږي ، هغه حالت چې د خدمت په حافظه کې و د همغږي کونکي لخوا په ننوتل شوي بیچ کې خوندي کیږي ، او د کاسندرا ذخیره ته د ننوتل شوي بست په توګه لیږل کیږي. پلورنځي هر څه اړین کوي ​​ترڅو ډاډ ترلاسه کړي چې دا کڅوړه په اتومي ډول (په بشپړ ډول) پلي شوې ، او همغږي کونکي ته ځواب بیرته راولي ، څوک چې تالاشۍ خوشې کوي او پیرودونکي ته د لیږد بریا تاییدوي.

او د رول بیک کولو لپاره ، همغږي کونکی یوازې د لیږد حالت لخوا نیول شوې حافظه خلاصولو ته اړتیا لري.

د پورته پرمختګونو په پایله کې، موږ د ACID اصول پلي کړل:

• اتومي. دا یو تضمین دی چې هیڅ معامله به په سیسټم کې په جزوي توګه ثبت نشي؛ یا به د هغې ټولې فرعي عملیات بشپړ شي، یا هیڅ یو به بشپړ نشي. موږ په کاسندرا کې د ننوتلو بست له لارې دې اصول ته غاړه کیږدو.
• تسلسل. هر بریالی لیږد، د تعریف له مخې، یوازې معتبر پایلې ثبتوي. که، د راکړې ورکړې پرانستلو او د عملیاتو برخه ترسره کولو وروسته، دا معلومه شوه چې پایله یې ناسمه ده، یو رول بیک ترسره کیږي.
• انزوا. کله چې یوه معامله اجرا کیږي، همغږي لیږدونه باید د هغې پایلې اغیزه ونکړي. سیالي کونکي معاملې په همغږي کونکي کې د نا امیدۍ لاکونو په کارولو سره جلا کیږي. د لیږد څخه بهر لوستلو لپاره، د جلا کولو اصول د لوستلو ژمنې کچې کې لیدل کیږي.
• دوام. په ټیټو کچو کې د ستونزو په پام کې نیولو پرته - د سیسټم بلیک آوټ، د هارډویر ناکامي - په بریالیتوب سره بشپړ شوي لیږد لخوا رامینځته شوي بدلونونه باید وساتل شي کله چې عملیات بیا پیل شي.

د شاخصونو لخوا لوستل

راځئ یو ساده جدول واخلو:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

دا یو ID (لومړنۍ کیلي)، مالک او د ترمیم نیټه لري. تاسو اړتیا لرئ یو خورا ساده غوښتنه وکړئ - د مالک په اړه ډاټا د بدلون نیټې سره "د وروستۍ ورځې لپاره" غوره کړئ.

SELECT *
WHERE owner=?
AND modified>?

د دې لپاره چې دا ډول پوښتنې ګړندي پروسس شي ، په کلاسیک SQL DBMS کې تاسو اړتیا لرئ د کالمونو (مالک ، تعدیل) لخوا شاخص جوړ کړئ. موږ دا په اسانۍ سره کولی شو، ځکه چې موږ اوس د ACID تضمین لرو!

شاخصونه په C*XNUMX کې

د عکسونو سره د سرچینې میز شتون لري په کوم کې چې د ریکارډ ID لومړنۍ کلیدي ده.

د شاخص لپاره، C*one یو نوی جدول جوړوي چې د اصلي کاپي وي. کیلي د شاخص بیان ته ورته ده، او پدې کې د سرچینې میز څخه د ریکارډ لومړنۍ کیلي هم شامله ده:

اوس د "وروستۍ ورځې لپاره مالک" پوښتنه د بل جدول څخه د انتخاب په توګه بیا لیکل کیدی شي:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

د سرچینې جدول عکسونو او د شاخص جدول i1 کې د معلوماتو دوام په اوتومات ډول د همغږي کونکي لخوا ساتل کیږي. یوازې د ډیټا سکیما پراساس ، کله چې بدلون ترلاسه شي ، همغږي کونکی بدلون نه یوازې په اصلي جدول کې ، بلکه په کاپيونو کې هم رامینځته کوي او ذخیره کوي. د شاخص په میز کې هیڅ اضافي کړنې نه ترسره کیږي، لاګونه نه لوستل کیږي، او هیڅ قفل نه کارول کیږي. دا د شاخصونو اضافه کول تقریبا هیڅ سرچینې نه مصرفوي او په حقیقت کې د تعدیلاتو پلي کولو سرعت باندې هیڅ اغیزه نلري.

د ACID په کارولو سره، موږ وکولی شو د SQL په څیر شاخصونه پلي کړو. دوی ثابت، د توزیع وړ، ګړندي، د کمپوز وړ، او د CQL پوښتنې په ژبه کې جوړ شوي دي. د غوښتنلیک کوډ کې هیڅ بدلون ته اړتیا نشته ترڅو د شاخصونو ملاتړ وکړي. هرڅه د SQL په څیر ساده دي. او تر ټولو مهم، شاخصونه د اصلي لیږد میز ته د تعدیلاتو د اجرا سرعت اغیزه نه کوي.

څه پیښ شو

موږ درې کاله دمخه C * One ته وده ورکړه او په سوداګریزو عملیاتو کې مو پیل کړه.

په پای کې مو څه ترلاسه کړل؟ راځئ چې دا د عکس پروسس کولو او ذخیره کولو فرعي سیسټم مثال په کارولو سره ارزونه وکړو ، په ټولنیز شبکه کې د ډیټا یو له خورا مهم ډولونو څخه. موږ پخپله د عکسونو د جسدونو په اړه خبرې نه کوو، مګر د هر ډول میټا معلوماتو په اړه. اوس Odnoklassniki شاوخوا 20 ملیارد داسې ریکارډونه لري، سیسټم په هره ثانیه کې 80 زره لوستل شوي غوښتنې پروسس کوي، په هره ثانیه کې تر 8 زره ACID لیږدونه د ډیټا ترمیم سره تړاو لري.

کله چې موږ د نقل کولو فکتور = 1 (مګر په RAID 10 کې) سره SQL وکاروو ، د عکس میټینفارمیشن د 32 ماشینونو په خورا موجود کلستر کې زیرمه شوی و چې د مایکروسافټ ایس کیو ایل سرور چلوي (پلس 11 بیک اپ). د بیک اپ ذخیره کولو لپاره 10 سرورونه هم ځانګړي شوي. ټول 50 ګران موټر. په ورته وخت کې، سیسټم په درجه بندي شوي بار کې کار کوي، پرته له ریزرو.

نوي سیسټم ته د مهاجرت وروسته، موږ د نقل کولو فکتور = 3 ترلاسه کړ - په هر ډیټا مرکز کې یوه کاپي. سیسټم د 63 کاسندرا ذخیره کولو نوډونو او 6 همغږي کونکي ماشینونه لري ، د ټولټال 69 سرورونو لپاره. مګر دا ماشینونه خورا ارزانه دي، د دوی ټول لګښت د SQL سیسټم لګښت شاوخوا 30٪ دی. په ورته وخت کې، بار په 30٪ کې ساتل کیږي.

د C*4,5 په معرفي کولو سره، ځنډ هم کم شوی: په SQL کې، د لیکلو عملیات شاوخوا 1,6 ms ونیول. په C*40 کې - شاوخوا 2 ms. د راکړې ورکړې موده په اوسط ډول له 2 ms څخه کمه ده، ژمنه په 99 ms کې بشپړه شوې، د لوستلو او لیکلو موده په اوسط ډول 3 ms ده. 3,1 فیصده - یوازې 100-XNUMX ms، د وخت پای ته رسیدو شمیر XNUMX ځله کم شوی - دا ټول د قیاس پراخه کارولو له امله.

تر دې دمه ، د SQL سرور ډیری نوډونه بند شوي؛ نوي محصولات یوازې د C * One په کارولو سره رامینځته کیږي. موږ په خپل کلاوډ کې د کار کولو لپاره C * One تطبیق کړ یو بادل، کوم چې دا ممکنه کړې چې د نوي کلسترونو ځای په ځای کول ګړندي کړي ، تنظیمات ساده کړي او اتومات عملیات وکړي. د سرچینې کوډ پرته، دا کول به خورا ستونزمن او پیچلي وي.

اوس موږ کلاوډ ته زموږ د نورو ذخیره کولو تاسیساتو لیږدولو باندې کار کوو - مګر دا یو بشپړ مختلف کیسه ده.

سرچینه: www.habr.com