دوی وايي چې په ژوند کې هرڅه لږ تر لږه یو ځل هڅه کول ارزښت لري. او که تاسو د اړونده DBMSs سره کار کولو عادت یاست ، نو دا په عمل کې د NoSQL سره آشنا کیدو ارزښت لري ، لومړی ، لږترلږه د عمومي پراختیا لپاره. اوس، د دې ټکنالوجۍ د چټک پرمختګ له امله، د دې موضوع په اړه ډیری متضاد نظرونه او تودوخې بحثونه شتون لري، کوم چې په ځانګړې توګه دلچسپي زیاتوي.
که تاسو د دې ټولو شخړو جوهر ته پام وکړئ، تاسو به وګورئ چې دوی د غلط چلند له امله رامینځته شوي. هغه څوک چې د NoSQL ډیټابیسونه په سمه توګه کاروي چیرې چې دوی ورته اړتیا لري مطمین دي او د دې حل څخه ټولې ګټې ترلاسه کوي. او تجربه کونکي چې پدې ټیکنالوژۍ باندې د درملنې په توګه تکیه کوي چیرې چې دا په هیڅ ډول د تطبیق وړ ندي مایوسه شوي ، د پام وړ ګټې ترلاسه کولو پرته د اړوند ډیټابیس ځواک له لاسه ورکړی.
زه به تاسو ته د کاسندرا DBMS پراساس د حل پلي کولو کې زموږ د تجربې په اړه ووایم: هغه څه چې موږ ورسره مخ وو، موږ څنګه له سختو شرایطو څخه راووتو، ایا موږ د NoSQL کارولو څخه ګټه پورته کولی شو او چیرې چې موږ اضافي هڅې/فنډونه پانګونه کړې وه .
لومړنۍ دنده د داسې سیسټم جوړول دي چې په یو ډول ذخیره کې تلیفونونه ثبت کړي.
د سیسټم عملیاتي اصول په لاندې ډول دي. ان پټ کې د ځانګړي جوړښت سره فایلونه شامل دي چې د زنګ جوړښت تشریح کوي. غوښتنلیک بیا ډاډ ورکوي چې دا جوړښت په مناسبو کالمونو کې زیرمه شوی. په راتلونکي کې ، خوندي شوي تلیفونونه د پیرودونکو لپاره د ترافیک مصرف په اړه معلوماتو ښودلو لپاره کارول کیږي (چارجونه ، تلیفونونه ، د بیلانس تاریخ).
دا خورا روښانه ده چې ولې دوی کاسندرا غوره کړه - هغه د ماشین ټوپک په څیر لیکي ، په اسانۍ سره د توزیع وړ او د خطا زغمونکې ده.
نو، دا هغه څه دي چې موږ ته یې تجربه راکړه
هو، ناکامه نوډ یوه تراژیدي نه ده. دا د کاسندرا د خطا زغم جوهر دی. خو یو نوډ ژوندی کیدی شي او په ورته وخت کې په فعالیت کې رنځ پیل کړي. لکه څنګه چې دا معلومه شوه، دا سمدلاسه د ټول کلستر فعالیت اغیزه کوي.
کاسندرا به ستاسو ساتنه ونه کړي چیرې چې اوریکل تاسو د خپلو خنډونو سره خوندي کړي. او که د غوښتنلیک لیکوال مخکې له دې نه پوهیدلی، نو بیا هغه ډبل چې د کاسندرا لپاره راغلی د اصلي څخه بد نه دی. یوځل چې دا راشي ، موږ به یې دننه کړو.
IB د بکس څخه بهر وړیا Cassandra په کلکه ناخوښه کړه: د کارونکي عملونو ننوتل شتون نلري ، د حقونو توپیر نلري. د زنګونو په اړه معلومات د شخصي معلوماتو په توګه ګڼل کیږي، دا پدې مانا ده چې د غوښتنې / بدلولو ټولې هڅې باید د راتلونکي پلټنې احتمال سره لاسلیک شي. همچنان ، تاسو اړتیا لرئ د مختلف کاروونکو لپاره په مختلف کچو کې د جلا حقونو اړتیا څخه خبر اوسئ. یو ساده عملیاتي انجینر او یو عالي اډمین چې کولی شي په آزاده توګه ټول کلیدي ځای حذف کړي مختلف رولونه ، مختلف مسؤلیتونه او وړتیاوې دي. د لاسرسي د حقونو د داسې توپیر پرته ، د معلوماتو ارزښت او بشپړتیا به سمدلاسه د هرډول ثبات کچې په پرتله ګړندي پوښتنې ته راشي.
موږ دا په پام کې نه نیولې چې تلیفونونه د مختلف شرایطو لپاره جدي تحلیلونو او دوره ایز نمونې اخیستلو ته اړتیا لري. څرنګه چې ټاکل شوي ریکارډونه بیا باید حذف شي او بیا لیکل شي (د دندې د یوې برخې په توګه، موږ باید د ډیټا تازه کولو پروسې ملاتړ وکړو کله چې ډاټا په پیل کې زموږ لوپ ته په غلط ډول داخل شو)، کاسیندرا دلته زموږ ملګری ندی. کاسندرا د خنزیر بانک په څیر دی - دا د شیانو اچول اسانه دي ، مګر تاسو پدې کې حساب نشئ کولی.
موږ د ازموینې زونونو ته د معلوماتو لیږدولو کې ستونزې سره مخ شو (5 نوډونه په ازموینه کې د 20 په پرتله په پروم کې). په دې حالت کې، ډمپ نشي کارول کیدی.
کیسندرا ته د غوښتنلیک لیکلو ډیټا سکیما تازه کولو کې ستونزه. یو رول بیک به ډیر لوی قبر ډبرې رامینځته کړي ، کوم چې کولی شي په غیر متوقع لارو کې د تولید زیان لامل شي.. کیسینډرا د ثبت کولو لپاره مطلوبه ده، او د لیکلو دمخه ډیر فکر نه کوي، هر هغه عملیات چې په دې کې موجود ډاټا لري هم ثبت کول دي. دا دی، د غیر ضروري ړنګولو سره، موږ به په ساده ډول حتی نور ریکارډونه تولید کړو، او یوازې ځینې به یې د قبرونو سره په نښه شي.
د ننوتلو په وخت کې د وخت پای. Cassandra په ثبت کې ښکلې ده، مګر ځینې وختونه راتلونکی جریان کولی شي هغه د پام وړ حیران کړي. دا پیښیږي کله چې غوښتنلیک د ډیری ریکارډونو شاوخوا چکر پیل کوي کوم چې د کوم دلیل لپاره نشي داخل کیدی. او موږ به یو ریښتیني DBA ته اړتیا ولرو څوک چې د سست پوښتنو لپاره د gc.log ، سیسټم او ډیبګ لاګونو څارنه وکړي ، د کمپریشن پاتې کیدو میټریکونه.
په یوه کلستر کې د ډیټا څو مرکزونه. له کوم ځای څخه لوستل او چیرته لیکل؟
شاید په لوستلو او لیکلو ویشل شي؟ او که داسې وي، ایا د لیکلو یا لوستلو لپاره غوښتنلیک ته نږدې DC شتون لري؟ او ایا موږ به د ریښتیني ویشل شوي مغز سره پای ته ورسیږو که چیرې موږ د غلط دوام کچه غوره کړو؟ دلته ډیری پوښتنې شتون لري، ډیری نامعلوم ترتیبات، امکانات چې تاسو واقعیا غواړئ ورسره ټینکر وکړئ.
موږ څنګه پریکړه وکړه
د نوډ د ډوبیدو څخه د مخنیوي لپاره، SWAP غیر فعال شوی و. او اوس، که د حافظې نشتوالی وي، نوډ باید ښکته شي او د لوی جی سی وقفې رامینځته نشي.
نو، موږ نور په ډیټابیس کې په منطق تکیه نه کوو. د غوښتنلیک پراختیا کونکي خپل ځان ته روزنه ورکوي او په خپل کوډ کې په فعاله توګه احتیاطي تدابیر نیول پیل کوي. د معلوماتو ذخیره کولو او پروسس کولو مثالی روښانه جلا کول.
موږ د DataStax څخه ملاتړ اخیستی. د بکس شوي کاسیندرا پراختیا لا دمخه بنده شوې ده (وروستی ژمنه په فبروري 2018 کې وه). په ورته وخت کې، ډیټاسټیکس غوره خدمت وړاندې کوي او د موجوده IP حلونو لپاره لوی شمیر تعدیل شوي او تطبیق شوي حلونه وړاندې کوي.
زه دا هم غواړم په یاد ولرئ چې کاسندرا د انتخاب پوښتنو لپاره خورا اسانه ندي. البته، CQL د کاروونکو لپاره یو لوی ګام دی (د Trift په پرتله). مګر که تاسو ټولې ډیپارټمنټونه ولرئ چې د ورته مناسب شمولیت سره عادت شوي ، د هرې ساحې لخوا وړیا فلټر کول او د پوښتنو اصلاح کولو وړتیاوې ، او دا څانګې د شکایتونو او حادثو حل کولو لپاره کار کوي ، نو د کاسندرا حل دوی ته دښمنانه او احمق ښکاري. او موږ پریکړه وکړه چې څنګه زموږ همکاران باید نمونې جوړ کړي.
موږ دوه اختیارونه په پام کې نیولي. په لومړي اختیار کې، موږ نه یوازې په C* کې، بلکې په آرشیف شوي اوریکل ډیټابیس کې هم زنګونه لیکو. یوازې، د C* برعکس، دا ډیټابیس یوازې د روانې میاشتې لپاره تلیفونونه ذخیره کوي (د قضیو د ریچارج کولو لپاره کافي کال ذخیره ژوره). دلته موږ سمدلاسه لاندې ستونزه ولیدله: که موږ په همغږي ډول ولیکئ ، نو موږ د C* ټولې ګټې له لاسه ورکوو چې د ګړندي ننوتلو سره تړاو لري؛ که موږ په غیر متناسب ډول ولیکئ ، هیڅ تضمین شتون نلري چې ټول اړین تلیفونونه په بشپړ ډول اوریکل ته رسیدلي. یو پلس شتون درلود، مګر یو لوی: د عملیاتو لپاره ورته پیژندل شوی PL/SQL جوړونکی پاتې دی، د بیلګې په توګه موږ په عملي توګه د "Facade" بڼه پلي کوو. یو بدیل اختیار. موږ یو میکانیزم پلي کوو چې له C* څخه تلیفونونه پورته کوي، په اوریکل کې د اړونده جدولونو څخه د بډای کولو لپاره ځینې ډاټا راوباسي، د پایلې نمونې سره یوځای کیږي او موږ ته پایله راکوي، کوم چې موږ بیا په یو ډول کاروو (بیا بیرته راګرځول، تکرار، تحلیل، ستاینه). زیانونه: پروسه خورا څو مرحلې ده، او سربیره پردې، د عملیاتي کارمندانو لپاره هیڅ انٹرفیس شتون نلري.
په نهایت کې ، موږ په دوهم اختیار کې میشت شو. اپاچی سپارک د بیلابیلو جارونو څخه د نمونې لپاره کارول کیده. د میکانیزم جوهر د جاوا کوډ ته راټیټ شوی، کوم چې د ټاکل شوي کیلي (پیرودونکي، د زنګ وخت - د برخې کیلي) په کارولو سره، د C* څخه ډاټا راوباسي، او همدارنګه د کوم بل ډیټابیس څخه د غني کولو لپاره اړین معلومات. له هغې وروسته دا دوی په خپل حافظه کې یوځای کیږي او پایله یې په پایله شوي جدول کې ښیې. موږ د چنګک په اړه ویب مخ رسم کړ او دا د کارونې وړ وګرځید.
کله چې د صنعتي ازموینې ډیټا تازه کولو ستونزه حل کول ، موږ بیا څو حلونه په پام کې ونیول. دواړه د Sstloader له لارې لیږد او د ټیسټ زون کې د کلسټر ویشلو اختیار په دوه برخو کې ، چې هر یو یې په بدیل سره ورته کلستر پورې اړه لري د پروموشنل سره ، پدې توګه د دې لخوا ځواکمن کیږي. کله چې د ازموینې تازه کول ، پلان شوي و چې دوی بدل کړئ: هغه برخه چې په ازموینه کې کار کوي پاکه شوې او تولید ته داخله شوې ، او بله په جلا توګه د معلوماتو سره کار پیل کوي. په هرصورت، د بیا فکر کولو وروسته، موږ په ډیر منطقي توګه هغه ډاټا ارزونه وکړه چې د لیږد ارزښت لري، او پوه شو چې تلیفونونه پخپله د ازموینې لپاره یو متضاد ارګان دی، که اړتیا وي، ژر تر ژره تولید کیږي، او دا د پروموشنل ډیټا سیټ دی چې د لیږد لپاره هیڅ ارزښت نلري. ازموینه د ذخیره کولو ډیری شیان شتون لري چې د حرکت وړ دي، مګر دا په حقیقت کې یو څو میزونه دي، او ډیر دروند ندي. له همدې امله موږ د حل په توګه، سپارک بیا د ژغورنې لپاره راغی، د کوم په مرسته چې موږ لیکلي او په فعاله توګه د میزونو، پروم-ټیسټ ترمنځ د معلوماتو لیږدولو لپاره د سکریپټ کارول پیل کړل.
زموږ اوسنۍ ګمارنې پالیسي موږ ته اجازه راکوي چې پرته له رول بیک کار وکړو. د پرومو څخه دمخه، یو لازمي ازموینه شتون لري، چیرې چې غلطي دومره ګرانه نه ده. د ناکامۍ په صورت کې، تاسو کولی شئ تل د قضیې ځای پریږدئ او له پیل څخه ټوله سکیم رول کړئ.
د کیسیندرا دوامداره شتون ډاډ ترلاسه کولو لپاره ، تاسو dba ته اړتیا لرئ او نه یوازې هغه. هرڅوک چې د غوښتنلیک سره کار کوي باید پوه شي چې چیرې او څنګه اوسني وضعیت ته ګوري او څنګه په وخت سره ستونزې تشخیص کړي. د دې کولو لپاره، موږ په فعاله توګه د DataStax OpsCenter څخه کار اخلو (د کاري بارونو اداره او څارنه)، د کاسندرا ډرایور سیسټم میټریکونه (C* ته د لیکلو لپاره د مهال ویش شمیر، د C* څخه د لوستلو لپاره د وخت پای شمیر، اعظمي ځنډ، او نور)، د عملیاتو څارنه د غوښتنلیک پخپله، د کاسندرا سره کار کول.
کله چې موږ د تیرې پوښتنې په اړه فکر وکړ، موږ پوهیږو چې زموږ اصلي خطر چیرته دی. دا د ډیټا ښودلو فارمونه دي چې د ډیری خپلواکو پوښتنو څخه ډیټا ذخیره کولو ته ښیې. پدې توګه موږ کولی شو خورا متناسب معلومات ترلاسه کړو. مګر دا ستونزه به هماغسې اړونده وي که موږ یوازې د ډیټا مرکز سره کار وکړو. نو دلته ترټولو معقول شی دا دی ، البته ، د دریمې ډلې غوښتنلیک کې د معلوماتو لوستلو لپاره د بیچ فنکشن رامینځته کول ، کوم چې به ډاډ ترلاسه کړي چې ډاټا په یو وخت کې ترلاسه کیږي. لکه څنګه چې د فعالیت په شرایطو کې د لوستلو او لیکلو ویش لپاره، دلته موږ د دې خطر له امله ودرول شو چې د DCs ترمنځ د اړیکو له لاسه ورکولو سره، موږ کولی شو د دوو کلسترونو سره پای ته ورسوو چې په بشپړ ډول یو له بل سره متناسب دي.
په پایله کې، د اوس لپاره د EACH_QUORUM لیکلو لپاره د دوام په کچه ودرول شو، د لوستلو لپاره - LOCAL_QUORUM
لنډ تاثرات او پایلې
د عملیاتي مالتړ او د لا پراختیا لپاره د امکاناتو له نظره د پایلې حل ارزولو لپاره، موږ پریکړه وکړه چې په دې اړه فکر وکړو چې دا ډول پرمختګ چیرته پلي کیدی شي.
د بیټ څخه سم ، بیا د برنامو لپاره د معلوماتو نمرې کول لکه "کله چې مناسب وي تادیه کړئ" (موږ معلومات په C* کې بار کوو ، د سپارک سکریپټونو په کارولو سره محاسبه) ، د ساحې له مخې راټولولو سره د ادعاګانو حساب کول ، د رول ذخیره کول او د رول پراساس د کارونکي لاسرسي حقونه محاسبه کول. میٹرکس
لکه څنګه چې تاسو لیدلی شئ، ذخیره پراخه او متنوع ده. او که موږ د NoSQL د ملاتړو/مخالفینو کمپ غوره کړو، نو بیا به موږ د ملاتړ کونکو سره یوځای شو، ځکه چې موږ خپلې ګټې ترلاسه کړې، او دقیقا هغه ځای چې موږ تمه درلوده.
حتی د بکس څخه بهر د کاسندرا اختیار په ریښتیني وخت کې افقی اندازه کولو ته اجازه ورکوي ، په بشپړ ډول بې درده په سیسټم کې د ډیټا ډیریدو مسله حل کوي. موږ وتوانیدو چې په جلا سرکټ کې د کال مجموعو محاسبه کولو لپاره خورا لوړ بار میکانیزم حرکت وکړو ، او د غوښتنلیک سکیما او منطق هم جلا کړو ، پخپله ډیټابیس کې د ګمرکي کارونو او شیانو لیکلو ناوړه عمل څخه خلاصون ترلاسه کړو. موږ فرصت ترلاسه کړ چې غوره کړو او تنظیم کړو، ګړندی کولو لپاره، کوم DCs به موږ محاسبه ترسره کړو او په کومو کې به موږ ډاټا ثبت کړو، موږ خپل ځان د انفرادي نوډونو او په مجموع کې د DC د دواړو پیښو په وړاندې بیمه کړو.
په نویو پروژو کې زموږ د جوړښت پلي کول، او مخکې له دې چې یو څه تجربه ولري، زه غواړم سمدلاسه پورته بیان شوي لنډیزونه په پام کې ونیسم، او د ځینو غلطیو مخه ونیسم، ځینې ګړندۍ کونجونه اسانه کړئ چې په پیل کې مخنیوی نشي کولی.
د مثال په توګه، د کاسندرا تازه معلومات په وخت سره تعقیب کړئځکه چې یو شمیر ستونزې چې موږ ترلاسه کړې دمخه پیژندل شوي او حل شوي.
پخپله ډیټابیس او سپارک دواړه په ورته نوډونو کې مه مه اچوئ (یا په کلکه د منلو وړ سرچینو کارولو مقدار سره تقسیم کړئ)، ځکه چې سپارک کولی شي د تمې څخه ډیر OP وخوري، او موږ به ژر تر ژره زموږ د لیست څخه ستونزه 1 ترلاسه کړو.
د پروژې د ازموینې په مرحله کې د څارنې او عملیاتي وړتیا ښه کول. په پیل کې، زموږ د حل ټول احتمالي پیرودونکي څومره چې ممکنه وي په پام کې ونیسئ، ځکه چې دا هغه څه دي چې د ډیټابیس جوړښت به په پای کې تکیه وکړي.
د احتمالي اصلاح کولو لپاره پایله لرونکي سرکټ څو ځله وګرځوئ. هغه ساحې غوره کړئ چې سریالیز کیدی شي. په دې پوهیږو چې کوم اضافي جدولونه باید په سمه توګه او غوره توګه په پام کې ونیول شي، او بیا د غوښتنې په وخت کې اړین معلومات چمتو کړئ (د مثال په توګه، د دې په نظر کې نیولو سره چې موږ کولی شو ورته ډیټا په مختلفو جدولونو کې ذخیره کړو، د مختلفو ماتولو حساب په پام کې نیولو سره. مختلف معیارونه، موږ کولی شو د لوستلو غوښتنو لپاره د پام وړ CPU وخت خوندي کړو).
خراب ندی سمدستي د TTL ضمیمه کولو او پخوانیو معلوماتو پاکولو لپاره چمتو کړئ.
کله چې د کاسندرا څخه ډاټا ډاونلوډ کړئ د غوښتنلیک منطق باید د FETCH په اصولو کار وکړي، ترڅو ټول قطارونه په یوځل حافظه کې نه پورته کیږي، مګر په بستونو کې غوره شوي.
دا مشوره ورکول کیږي مخکې له دې چې د پروژې تشریح شوي حل ته لیږدول شي د یو لړ حادثو ازموینو په ترسره کولو سره د سیسټم غلطی زغم چیک کړئ، لکه په یو ډیټا مرکز کې د معلوماتو ضایع کول ، د یوې ټاکلې مودې لپاره د خراب شوي ډیټا بیا رغونه ، د معلوماتو مرکزونو ترمینځ د شبکې ورکیدل. دا ډول ازموینې به نه یوازې یو چا ته اجازه ورکړي چې د وړاندیز شوي جوړښت ګټې او زیانونه و ارزوي ، بلکه د انجینرانو لپاره چې دوی یې ترسره کوي ښه تودوخې تمرین هم چمتو کوي ، او ترلاسه شوي مهارتونه به له اړتیا څخه لرې وي که چیرې د سیسټم ناکامي په تولید کې بیا تولید شي.
که موږ د مهمو معلوماتو سره کار وکړو (لکه د بل کولو لپاره ډاټا، د پیرودونکي پور محاسبه)، نو دا د وسیلو په اړه هم د پام وړ ارزښت لري چې د DBMS ځانګړتیاو له امله رامینځته شوي خطرونه کم کړي. د مثال په توګه، د نوډسینک افادیت (Datastax) څخه کار واخلئ، په ترتیب سره یې د کارولو لپاره غوره ستراتیژي جوړه کړه د دوام لپاره، په Cassandra کې ډیر بار مه جوړوئ او دا یوازې په ټاکلې موده کې د ځینې میزونو لپاره وکاروئ.
د شپږ میاشتې ژوند وروسته کیسیندرا ته څه پیښیږي؟ په عموم کې، هیڅ حل شوي ستونزې شتون نلري. موږ د کومې جدي پیښې یا معلوماتو ضایع کیدو ته هم اجازه نه ورکوو. هو، موږ باید د ځینو ستونزو د جبران کولو په اړه فکر وکړو چې مخکې نه و رامینځته شوی، مګر په پای کې دا زموږ د معمارۍ حل خورا باد نه کړ. که تاسو غواړئ او د نوي څه هڅه کولو څخه ډارېږئ، او په ورته وخت کې نه غواړئ چې ډیر مایوسه شئ، نو د دې حقیقت لپاره چمتو اوسئ چې هیڅ شی وړیا نه دی. تاسو باید پوه شئ، په اسنادو کې ژوره مطالعه وکړئ او د زاړه میراث حل په پرتله خپل انفرادي ریک راټول کړئ، او هیڅ تیوري به تاسو ته مخکې له مخکې نه ووایي چې کوم ریک ستاسو په تمه دی.
سرچینه: www.habr.com