سلام و ټولو ته! زما نوم ګولوف نیکولای دی. مخکې، ما په Avito کې کار کړی او د شپږو کلونو لپاره د ډیټا پلیټ فارم اداره کړی، دا دی، ما په ټولو ډیټابیسونو کې کار کړی: تحلیلي (ورټیکا، کلیک هاؤس)، سټیمینګ او OLTP (Redis، Tarantool، VoltDB، MongoDB، PostgreSQL). د دې وخت په جریان کې، ما د ډیری ډیټابیسونو سره معامله وکړه - خورا مختلف او غیر معمولي، او د دوی د کارولو غیر معیاري قضیې سره.
زه اوس مهال په ManyChat کې کار کوم. په اصل کې، دا یو پیل دی - نوی، هوښیار او په چټکۍ سره وده کوي. او کله چې زه په لومړي ځل شرکت کې شامل شوم، یوه کلاسیک پوښتنه راپورته شوه: "اوس یو ځوان پیل باید د DBMS او ډیټابیس بازار څخه څه واخلي؟"
په دې مقاله کې، زما د راپور پر بنسټ ، زه به دې پوښتنې ته ځواب ووایم. د راپور یوه ویډیو نسخه شتون لري .
په عام ډول پیژندل شوي ډیټابیسونه 2020
دا 2020 دی، ما شاوخوا وکتل او درې ډوله ډیټابیسونه مې ولیدل.
لومړی ډول - د کلاسیک OLTP ډیټابیسونه: PostgreSQL, SQL Server, Oracle, MySQL. دوی ډیر وخت دمخه لیکل شوي، مګر لاهم اړونده دي ځکه چې دوی د پراختیا کونکي ټولنې سره ډیر پیژندل شوي دي.
دوهم ډول دی له "صفر" څخه اډې. دوی هڅه وکړه چې د SQL، دودیزو جوړښتونو او ACID پریښودلو، د جوړ شوي شارډینګ او نورو زړه راښکونکو ځانګړتیاو په اضافه کولو سره د کلاسیک نمونو څخه لیرې شي. د مثال په توګه، دا کیسیندرا، مونګو ډی بی، ریډیس یا ترانټول دی. دا ټول حلونه غوښتل بازار ته یو څه په بنسټیز ډول نوي وړاندیز وکړي او د دوی ځای یې نیولی ځکه چې دوی د ځینې کارونو لپاره خورا اسانه و. زه به دا ډیټابیسونه د چترۍ اصطلاح NOSQL سره په نښه کړم.
"صفر" پای ته ورسید، موږ د NOSQL ډیټابیسونو سره عادت شو، او نړۍ، زما له نظره، بل ګام پورته کړ - ته اداره شوي ډیټابیسونه. دا ډیټابیسونه د کلاسیک OLTP ډیټابیسونو یا نوي NoSQL ډیټابیسونو په څیر ورته اصلي لري. مګر دوی DBA او DevOps ته اړتیا نلري او په بادلونو کې منظم هارډویر پرمخ وړي. د پراختیا کونکي لپاره ، دا "یوازې یو اساس" دی چې په کوم ځای کې کار کوي ، مګر هیڅ څوک پروا نه کوي چې دا څنګه په سرور کې نصب شوی ، چا سرور تنظیم کړی او څوک یې تازه کوي.
د دې ډول ډیټابیسونو بیلګې:
- AWS RDS د PostgreSQL/MySQL لپاره اداره شوی ریپر دی.
- DynamoDB د سند پراساس ډیټابیس AWS انلاګ دی ، د Redis او MongoDB سره ورته.
- Amazon Redshift یو منظم تحلیلي ډیټابیس دی.
دا اساسا زاړه ډیټابیسونه دي ، مګر په منظم چاپیریال کې رامینځته شوي ، پرته له هارډویر سره کار کولو اړتیا.
نوټ. مثالونه د AWS چاپیریال لپاره اخیستل شوي، مګر د دوی انلاګونه په مایکروسافټ Azure، Google Cloud، یا Yandex.Cloud کې هم شتون لري.
په دې اړه څه نوي دي؟ په 2020 کې، له دې څخه هیڅ یو.
بې سروره مفهوم
هغه څه چې په 2020 کې په بازار کې واقعیا نوي دي بې سرور یا بې سرور حلونه دي.
زه به هڅه وکړم چې دا تشریح کړم چې دا د منظم خدمت یا پس منظر غوښتنلیک مثال په کارولو سره څه معنی لري.
د منظم بیک انډ غوښتنلیک پلي کولو لپاره، موږ یو سرور اخلو یا کرایه کوو، کوډ یې کاپي کوو، د پای ټکی بهر خپروو او په منظمه توګه د کرایې، بریښنا او ډاټا مرکز خدماتو لپاره پیسې ورکوو. دا معیاري سکیم دی.
بله کومه لاره شته؟ د بې سرور خدماتو سره تاسو کولی شئ.
د دې تګلارې تمرکز څه دی: هیڅ سرور شتون نلري، حتی په بادل کې د مجازی مثال کرایه هم شتون نلري. د خدمت ځای په ځای کولو لپاره، کوډ (دندې) ذخیره ته کاپي کړئ او پای ټکی ته یې خپور کړئ. بیا موږ په ساده ډول دې فنکشن ته د هر کال لپاره تادیه کوو ، په بشپړ ډول هغه هارډویر له پامه غورځوو چیرې چې دا اجرا کیږي.
زه به هڅه وکړم چې دا طریقه د انځورونو سره روښانه کړم.
کلاسیک ځای پرځای کول. موږ د یو ځانګړي بار سره خدمت لرو. موږ دوه مثالونه پورته کوو: فزیکي سرورونه یا په AWS کې مثالونه. بهرنۍ غوښتنې دې مواردو ته لیږل کیږي او هلته پروسس کیږي.
لکه څنګه چې تاسو په انځور کې لیدلی شئ، سرورونه په مساوي توګه نه ویشل شوي. یو یې 100٪ کارول شوی، دوه غوښتنې شتون لري، او یو یې یوازې 50٪ دی - یو څه بې کاره. که درې غوښتنې نه وي، مګر 30، نو ټول سیسټم به د بار سره مقابله ونه کړي او ورو به پیل شي.
بې سروره ګمارنه. په بې سرور چاپیریال کې، دا ډول خدمت مثالونه یا سرورونه نلري. د ګرمو سرچینو یو ځانګړی حوض شتون لري - د ځای پرځای شوي فنکشن کوډ سره کوچني چمتو شوي ډاکر کانټینرونه. سیسټم بهرنۍ غوښتنې ترلاسه کوي او د هر یو لپاره بې سرور چوکاټ د کوډ سره یو کوچنی کانټینر پورته کوي: دا دا ځانګړې غوښتنه پروسس کوي او کانټینر وژني.
یوه غوښتنه - یو کانټینر پورته شوی، 1000 غوښتنې - 1000 کانټینرونه. او په هارډویر سرورونو کې ګمارل دمخه د کلاوډ چمتو کونکي کار دی. دا په بشپړ ډول د سرور پرته چوکاټ لخوا پټ دی. پدې مفهوم کې موږ د هر تلیفون لپاره پیسې ورکوو. د مثال په توګه، په ورځ کې یو تلیفون راغی - موږ د یوې تلیفون لپاره پیسې ورکړې، په یوه دقیقه کې یو ملیون راغلی - موږ د یو ملیون لپاره پیسې ورکړې. یا په یوه ثانیه کې، دا هم پیښیږي.
د بې سرور فعالیت خپرولو مفهوم د بې ریاست خدمت لپاره مناسب دی. او که تاسو د (دولت) دولتي خدمت ته اړتیا لرئ، نو موږ خدمت ته ډیټابیس اضافه کوو. په دې حالت کې، کله چې دا د دولت سره کار کولو ته راځي، هر دولتي فعالیت په ساده ډول د ډیټابیس څخه لیکي او لوستل کیږي. سربیره پردې، د مقالې په پیل کې تشریح شوي د دریو ډولونو څخه د هر یو ډیټابیس څخه.
د دې ټولو ډیټابیسونو ګډ محدودیت څه دی؟ دا د دوامداره کارول شوي بادل یا هارډویر سرور (یا څو سرورونو) لګښتونه دي. دا مهمه نده چې ایا موږ کلاسیک یا اداره شوي ډیټابیس کاروو ، ایا موږ ډیوپس او مدیر لرو یا نه ، موږ لاهم د هارډویر ، بریښنا او ډیټا سینټر کرایه 24/7 لپاره تادیه کوو. که موږ کلاسیک اساس ولرو، موږ د بادار او غلام لپاره پیسې ورکوو. که دا یو ډیر بار شوی شارډ ډیټابیس وي، موږ د 10، 20 یا 30 سرورونو لپاره پیسې ورکوو، او موږ په دوامداره توګه پیسې ورکوو.
د لګښت په جوړښت کې د دایمي خوندي شوي سرورونو شتون دمخه د یو اړین شر په توګه پیژندل شوی و. دودیز ډیټابیسونه نور مشکلات هم لري، لکه د اړیکو شمیر محدودیتونه، د پیمانه محدودیتونه، د جیو ویشل شوي توافق - دا په یو څه ډول په ځینو ډیټابیسونو کې حل کیدی شي، مګر ټول په یوځل او په مثالي توګه نه.
بې سرور ډیټابیس - تیوري
د 2020 پوښتنه: ایا دا ممکنه ده چې د ډیټابیس سرور هم بې جوړ کړئ؟ هرڅوک د بې سرور بیک اینډ په اړه اوریدلي دي ... راځئ هڅه وکړو چې ډیټابیس سرور بې برخې کړو؟
دا عجيب ښکاري، ځکه چې ډیټابیس یو بشپړ خدمت دی، د بې سرور زیربنا لپاره خورا مناسب نه دی. په ورته وخت کې، د ډیټابیس حالت خورا لوی دی: ګیګابایټ، ټیرابایټ، او په تحلیلي ډیټابیسونو کې حتی پیټابایټ. دا دومره اسانه نده چې دا د سپک وزن لرونکي ډاکر کانټینرونو کې پورته کړئ.
له بلې خوا، نږدې ټول عصري ډیټابیسونه په لوی مقدار کې منطق او اجزا لري: راکړې ورکړې، بشپړتیا همغږي، پروسیجرونه، ارتباطي انحصار او ډیری منطق. د ډیری ډیټابیس منطق لپاره ، یو کوچنی حالت کافي دی. ګیګابایټس او ټرابیټ په مستقیم ډول د ډیټابیس منطق یوازې د یوې کوچنۍ برخې لخوا کارول کیږي چې په مستقیم ډول د پوښتنو اجرا کولو کې ښکیل دي.
په همدې اساس، نظر دا دی: که د منطق یوه برخه د بې ریاسته اعدام اجازه ورکړي، نو ولې بنسټ په دولتي او بې دولت برخو ویشل نه شي.
د OLAP حلونو لپاره بې سرور
راځئ وګورو چې د ډیټابیس په دولتي او بې ریاسته برخو ویشل ممکن د عملي مثالونو کارولو په څیر ښکاري.
د مثال په توګه، موږ یو تحلیلي ډیټابیس لرو: بهرنۍ ډاټا (په چپ اړخ کې سور سلنډر)، د ETL پروسه چې ډیټابیس ته ډاټا باروي، او یو شنونکی چې ډیټابیس ته د SQL پوښتنې لیږي. دا د کلاسیک ډیټا ګودام عملیات سکیم دی.
په دې سکیم کې، ETL په مشروط ډول یو ځل ترسره کیږي. بیا تاسو اړتیا لرئ په دوامداره توګه د سرورونو لپاره تادیه وکړئ چیرې چې ډیټابیس د ETL سره ډک شوي ډیټا سره پرمخ ځي ، نو د پوښتنو لیږلو لپاره یو څه شتون لري.
راځئ چې په AWS ایتینا سرورلیس کې پلي شوي بدیل چلند وګورو. دلته د تل لپاره وقف شوي هارډویر شتون نلري چې ډاونلوډ شوي معلومات پکې زیرمه شوي وي. د دې پر ځای:
- کارونکي اتینا ته د SQL پوښتنه وړاندې کوي. د ایتینا اصلاح کونکی د SQL پوښتنې تحلیل کوي او د پوښتنې اجرا کولو لپاره اړین ځانګړي ډیټا لپاره د میټاډاټا سټور (میټاډاټا) لټوي.
- اصلاح کوونکی، د راټولو شویو معلوماتو پر بنسټ، اړین معلومات د بهرنیو سرچینو څخه لنډمهاله ذخیره (موقتي ډیټابیس) ته ډاونلوډ کوي.
- د کارونکي څخه د SQL پوښتنه په لنډمهاله ذخیره کې اجرا کیږي او پایله یې کارونکي ته بیرته ورکول کیږي.
- لنډمهاله ذخیره پاکه شوې او سرچینې خوشې کیږي.
په دې جوړښت کې، موږ یوازې د غوښتنې پلي کولو پروسې لپاره پیسې ورکوو. هیڅ غوښتنه نشته - هیڅ لګښت نشته.
دا یوه کاري تګلاره ده او نه یوازې په اتینا سرورلیس کې پلي کیږي ، بلکه په ریډ شفټ سپیکٹرم (په AWS کې) کې هم پلي کیږي.
د ایتینا بیلګه ښیې چې د سرور بې ډیټابیس په ریښتیني پوښتنو باندې د لسګونو او سلګونو تیرابیټ ډیټا سره کار کوي. په سلګونو ټیرابیټ به په سلګونو سرورونو ته اړتیا ولري، مګر موږ د دوی لپاره پیسې نه ورکوو - موږ د غوښتنو لپاره پیسې ورکوو. د هرې غوښتنې سرعت د ځانګړي تحلیلي ډیټابیسونو لکه ورټیکا په پرتله (ډیر) ټیټ دی ، مګر موږ د کم وخت مودې لپاره تادیه نه کوو.
دا ډول ډیټابیس د نادر تحلیلي اډ-هاک پوښتنو لپاره د تطبیق وړ دی. د مثال په توګه، کله چې موږ په ناڅاپي ډول پریکړه کوو چې د ځینې لوی مقدار ډیټا په اړه فرضیه ازموینه وکړو. ایتینا د دې قضیو لپاره مناسب دی. د منظم غوښتنو لپاره، دا ډول سیسټم ګران دی. په دې حالت کې، ډاټا په یو ځانګړي حل کې زیرمه کړئ.
د OLTP حلونو لپاره بې سرور
مخکینی مثال د OLAP (تحلیلی) کارونو ته کتل. اوس راځئ چې د OLTP دندې وګورو.
راځئ چې د توزیع وړ PostgreSQL یا MySQL تصور وکړو. راځئ چې د لږترلږه سرچینو سره منظم منظم مثال پوسټګری ایس کیو ایل یا مای ایس کیو ایل پورته کړو. کله چې مثال ډیر بار ترلاسه کوي، موږ به اضافي نقلونه وصل کړو چې موږ به د لوستلو بار برخه وویشو. که چیرې غوښتنې یا بار شتون ونلري ، موږ عکسونه بند کوو. لومړی مثال ماسټر دی، او پاتې یې نقلونه دي.
دا مفکوره په ډیټابیس کې پلي کیږي چې د Aurora Serverless AWS په نوم یادیږي. اصل ساده دی: د بهرني غوښتنلیکونو غوښتنې د پراکسي بیړۍ لخوا منل کیږي. د بار زیاتوالي په لیدو سره ، دا د دمخه تودوخې لږترلږه مثالونو څخه کمپیوټري سرچینې تخصیص کوي - اړیکه څومره ژر چې امکان ولري رامینځته کیږي. غیر فعال کول په ورته ډول پیښیږي.
د اورورا دننه د اورورا ظرفیت واحد، ACU مفهوم شتون لري. دا (په مشروط ډول) یو مثال (سرور) دی. هر ځانګړی ACU کیدای شي ماسټر یا غلام وي. د ظرفیت هر واحد خپل RAM، پروسیسر او لږترلږه ډیسک لري. په دې اساس، یو یې ماسټر دی، پاتې نور یوازې نقلونه لوستل کیږي.
د دې اورورا ظرفیت واحدونو شمیر چې روان دي د ترتیب وړ پیرامیټر دی. لږترلږه مقدار یو یا صفر کیدی شي (په دې حالت کې، ډیټابیس کار نه کوي که چیرې غوښتنې شتون نلري).
کله چې بیس غوښتنې ترلاسه کوي، پراکسي بیړۍ د اورورا ظرفیت واحدونه لوړوي، د سیسټم فعالیت سرچینې زیاتوي. د سرچینو د زیاتوالي او کمولو وړتیا سیسټم ته اجازه ورکوي چې سرچینې "جګل" کړي: په اوتومات ډول انفرادي ACUs ښکاره کوي (د نوي سره ځای په ځای کول) او بیرته اخیستل شوي سرچینو ته ټول اوسني تازه معلومات وړاندې کوي.
د اورورا سرور بېس بیس کولی شي د لوستلو بار اندازه کړي. مګر اسناد دا مستقیم نه وايي. دا ممکن داسې احساس وکړي چې دوی کولی شي څو ماسټر پورته کړي. هیڅ جادو نشته.
دا ډیټابیس د غیر متوقع لاسرسي سره سیسټمونو کې د لوی مقدار پیسو مصرف کولو څخه مخنیوي لپاره مناسب دی. د مثال په توګه، کله چې د MVP یا بازار موندنې سوداګریز کارت سایټونه رامینځته کوي، موږ معمولا د باثباته بار تمه نه کوو. په دې اساس، که چیرې لاسرسی شتون ونلري، موږ د مثالونو لپاره پیسې نه ورکوو. کله چې غیر متوقع بار پیښ شي ، د مثال په توګه د کنفرانس یا اعلاناتو کمپاین وروسته ، د خلکو ډیری سایټ ته مراجعه کوي او بار په ډراماتیک ډول ډیریږي ، اورورا سرورلیس په اوتومات ډول دا بار اخلي او په چټکۍ سره ورک شوي سرچینې (ACU) سره وصل کوي. بیا کنفرانس تیریږي ، هرڅوک د پروټوټایپ په اړه هیر کوي ، سرورونه (ACU) تیاره کیږي ، او لګښتونه صفر ته راټیټیږي - مناسب.
دا حل د مستحکم لوړ بار لپاره مناسب ندی ځکه چې دا د لیکلو بار اندازه نه کوي. دا ټولې اړیکې او د منابعو منحل کول د "پیمانې نقطې" په نوم پیژندل کیږي - په هغه وخت کې چې ډیټابیس د لیږد یا لنډمهاله میزونو لخوا نه ملاتړ کیږي. د مثال په توګه، د یوې اونۍ په اوږدو کې د پیمانه نقطه ممکن نه وي، او اساس په ورته سرچینو کار کوي او په ساده ډول نشي کولی پراخ یا قرارداد وکړي.
هیڅ جادو نشته - دا منظم PostgreSQL دی. مګر د ماشینونو اضافه کولو او د دوی منحل کولو پروسه یو څه اتومات ده.
د ډیزاین له مخې بې سرور
اورورا سرورلیس یو زوړ ډیټابیس دی چې د بادل لپاره بیا لیکل شوی ترڅو د سرور لیس ځینې ګټو څخه ګټه پورته کړي. او اوس زه به تاسو ته د بیس په اړه ووایم، کوم چې په اصل کې د بادل لپاره لیکل شوی و، د سرور بې طریقې لپاره - د سرور بې ډیزاین ډیزاین. دا سمدلاسه د دې انګیرنې پرته رامینځته شوی چې دا به په فزیکي سرورونو کې پرمخ ځي.
دا اډه د Snowflake په نوم یادیږي. دا درې کلیدي بلاکونه لري.
لومړی د میټاډاټا بلاک دی. دا یو ګړندی په حافظه کې خدمت دی چې د امنیت ، میټاډاټا ، لیږدونو ، او د پوښتنو اصلاح کولو مسلې حل کوي (په کیڼ اړخ کې ښودل شوي).
دوهم بلاک د محاسبې لپاره د مجازی کمپیوټر کلسترونو سیټ دی (په مثال کې د نیلي حلقو سیټ شتون لري).
دریم بلاک د S3 پر بنسټ د معلوماتو ذخیره کولو سیسټم دی. S3 په AWS کې د ابعاد پرته څیز ذخیره ده ، د سوداګرۍ لپاره د ابعاد پرته ډراپ باکس په څیر.
راځئ وګورو چې سنو فلیک څنګه کار کوي ، د سړه پیل په توګه. دا دی، یو ډیټابیس شتون لري، ډاټا په دې کې بار شوې، هیڅ ډول پوښتنې شتون نلري. په دې اساس، که چیرې ډیټابیس ته هیڅ ډول غوښتنې شتون ونلري، نو موږ د میموري میټاډاټا چټک خدمت (لومړی بلاک) پورته کړی. او موږ د S3 ذخیره لرو، چیرې چې د میز ډاټا ذخیره کیږي، په تش په نامه مایکرو پارټیشنونو ویشل شوي. د سادګۍ لپاره: که چیرې جدول راکړې ورکړې ولري، نو مایکرو پارټیشنونه د معاملو ورځې دي. هره ورځ جلا مایکرو پارټیشن دی، یو جلا فایل. او کله چې ډیټابیس پدې حالت کې کار کوي ، تاسو یوازې د ډیټا لخوا نیول شوي ځای لپاره تادیه کوئ. سربیره پردې، د هرې څوکۍ نرخ خورا ټیټ دی (په ځانګړي توګه د پام وړ کمپریشن په پام کې نیولو سره). د میټاډاټا خدمت هم په دوامداره توګه کار کوي، مګر تاسو د پوښتنو غوره کولو لپاره ډیرو سرچینو ته اړتیا نلرئ، او خدمت د شریکولو په توګه ګڼل کیدی شي.
اوس راځئ تصور وکړو چې یو کارن زموږ ډیټابیس ته راغلی او د SQL پوښتنه یې لیږلې. د SQL پوښتنه سمدلاسه د پروسس لپاره میټاډاټا خدمت ته لیږل کیږي. په دې اساس، د غوښتنې په ترلاسه کولو سره، دا خدمت غوښتنه تحلیلوي، موجود معلومات، د کارونکي اجازې او، که هرڅه سم وي، د غوښتنې پروسس کولو لپاره یو پالن جوړوي.
بیا، خدمت د کمپیوټري کلستر پیل پیل کوي. د کمپیوټینګ کلستر د سرورونو کلستر دی چې محاسبه ترسره کوي. دا دی، دا یو کلستر دی چې کولی شي 1 سرور، 2 سرورونه، 4، 8، 16، 32 ولري - څومره چې تاسو غواړئ. تاسو یوه غوښتنه وغورځوئ او د دې کلستر لانچ سمدلاسه پیل کیږي. دا واقعیا ثانیې وخت نیسي.
بیا، وروسته له دې چې کلستر پیل شو، ستاسو د غوښتنې پروسس کولو لپاره اړین مایکرو پارټیشنونه د S3 څخه کلستر ته کاپي کیږي. دا دی ، راځئ تصور وکړو چې د SQL پوښتنې اجرا کولو لپاره تاسو د یو میز څخه دوه برخې ته اړتیا لرئ او یو له دوهم څخه. په دې حالت کې، یوازې درې اړین برخې به کلستر ته کاپي شي، او ټول میزونه په بشپړه توګه نه وي. له همدې امله ، او دقیقا ځکه چې هرڅه په یو ډیټا مرکز کې موقعیت لري او د خورا ګړندي چینلونو لخوا وصل شوي ، د لیږد ټوله پروسه خورا ګړندۍ پیښیږي: په ثانیو کې ، په ندرت سره په دقیقو کې ، پرته لدې چې موږ د ځینې شیطاني غوښتنو په اړه وغږیږو. په دې اساس، مایکرو پارټیشنونه د کمپیوټري کلستر ته کاپي شوي، او د بشپړیدو سره سم، د SQL پوښتنې په دې کمپیوټري کلستر کې اجرا کیږي. د دې غوښتنې پایله کیدای شي یوه کرښه، څو لینونه یا میز وي - دوی په بهر کې کارونکي ته لیږل کیږي ترڅو هغه کولی شي دا ډاونلوډ کړي، دا په خپل BI وسیله کې ښکاره کړي، یا په بل ډول یې وکاروي.
هره SQL پوښتنه نه یوازې د پخوانیو بار شوي ډیټا څخه مجموعه لوستلی شي ، بلکه په ډیټابیس کې نوي ډیټا بار / تولید هم کولی شي. دا ، دا یوه پوښتنه کیدی شي چې د مثال په توګه ، نوي ریکارډونه بل میز ته داخلوي ، کوم چې د کمپیوټر کلستر کې د نوي برخې ظهور لامل کیږي ، کوم چې په پایله کې ، په اتوماتيک ډول په یو واحد S3 ذخیره کې خوندي کیږي.
پورته بیان شوې سناریو، د کاروونکي له رارسیدو څخه د کلستر لوړولو پورې، د معلوماتو بارولو، د پوښتنو پلي کول، د پایلو ترلاسه کول، د پورته شوي مجازی کمپیوټر کلستر، مجازی ګودام کارولو دقیقو لپاره په نرخ کې تادیه کیږي. نرخ د AWS زون او کلستر اندازې پورې اړه لري، مګر په اوسط ډول دا په یو ساعت کې څو ډالر دي. د څلورو ماشینونو کلستر د دوو ماشینونو د کلستر په پرتله دوه چنده ګران دی، او د اتو ماشینونو کلستر اوس هم دوه چنده ګران دی. د 16، 32 ماشینونو اختیارونه شتون لري، د غوښتنو پیچلتیا پورې اړه لري. مګر تاسو یوازې د هغه دقیقو لپاره پیسې ورکوئ کله چې کلستر واقعیا روان وي ، ځکه چې کله غوښتنه شتون نلري ، تاسو ډول ډول خپل لاسونه لرې کوئ ، او د 5-10 دقیقو انتظار وروسته (د ترتیب وړ پیرامیټر) به پخپله خلاص شي ، سرچینې خلاص کړئ او وړیا شئ.
یو بشپړ ریښتینی سناریو هغه ده کله چې تاسو غوښتنه واستوئ، کلستر پاپ اپ کیږي، په نسبتا خبرې کولو سره، په یوه دقیقه کې، دا د بلې دقیقې لپاره حساب کوي، بیا د بندولو لپاره پنځه دقیقې، او تاسو د دې کلستر د اوو دقیقو عملیاتو لپاره پیسې ورکوئ، او نه د میاشتو او کلونو لپاره.
لومړۍ سناریو چې د یو واحد کارونکي ترتیب کې د سنو فلیک په کارولو سره تشریح شوې. اوس راځئ چې تصور وکړو چې ډیری کاروونکي شتون لري، کوم چې اصلي سناریو ته نږدې دی.
راځئ چې ووایو موږ ډیری شنونکي او جدول راپورونه لرو چې په دوامداره توګه زموږ ډیټابیس د لوی شمیر ساده تحلیلي SQL پوښتنو سره بمباروي.
سربیره پردې ، راځئ چې ووایو چې موږ اختراع شوي ډیټا ساینس پوهان لرو چې هڅه کوي د ډیټا سره شیطاني شیان ترسره کړي ، په لسګونو ټرابیټ سره کار وکړي ، د ملیاردونو او ملیاردونو ډیټا قطارونه تحلیل کړي.
د پورته ذکر شوي دوه ډوله کاري بار لپاره، سنو فلیک تاسو ته اجازه درکوي د مختلف ظرفیتونو ډیری خپلواک کمپیوټري کلسترونه پورته کړئ. سربیره پردې، دا کمپیوټري کلسترونه په خپلواکه توګه کار کوي، مګر د ګډ ثابت معلوماتو سره.
د لوی شمیر روښانه پوښتنو لپاره، تاسو کولی شئ 2-3 کوچني کلسترونه پورته کړئ، تقریبا 2 ماشینونه هر یو. دا چلند د نورو شیانو په مینځ کې د اتوماتیک ترتیباتو په کارولو سره پلي کیدی شي. نو تاسو ووایاست، "د واورې فلیک، یو کوچنی کلستر پورته کړئ. که چیرې په دې باندې بار له یو ځانګړي پیرامیټر څخه پورته شي ، ورته ورته دوهم ، دریم لوړ کړئ. کله چې بار په کمیدو پیل شي، اضافي اور مړ کړئ. نو مهمه نده چې څومره شنونکي راشي او د راپورونو په لټه کې شي، هرڅوک کافي سرچینې لري.
په ورته وخت کې، که شنونکي ویده وي او هیڅوک راپورونه نه ګوري، کلسترونه ممکن په بشپړه توګه تیاره شي، او تاسو د دوی لپاره پیسې ورکول بند کړئ.
په ورته وخت کې، د درنو پوښتنو لپاره (د ډیټا ساینس پوهانو څخه)، تاسو کولی شئ د 32 ماشینونو لپاره یو خورا لوی کلستر پورته کړئ. دا کلستر به یوازې د هغه دقیقو او ساعتونو لپاره تادیه شي کله چې ستاسو لوی غوښتنه هلته روانه وي.
پورته بیان شوي فرصت تاسو ته اجازه درکوي چې نه یوازې 2، بلکې د کار بار نور ډولونه په کلسترونو ویشئ (ETL، څارنه، د راپور مادي کول، ...).
راځئ چې د Snowflake لنډیز وکړو. بیس یو ښکلی نظر او د کار وړ تطبیق سره یوځای کوي. په ManyChat کې، موږ د ټولو معلوماتو تحلیل لپاره Snowflake کاروو چې موږ یې لرو. موږ درې کلسترونه نلرو، لکه څنګه چې په مثال کې، مګر له 5 څخه تر 9 پورې، د مختلفو اندازو. موږ د ځینو دندو لپاره دودیز 16 ماشینونه، 2 ماشینونه، او همدارنګه خورا کوچني 1 ماشینونه لرو. دوی په بریالیتوب سره بار توزیع کوي او موږ ته اجازه راکوي چې ډیر خوندي کړو.
ډیټابیس په بریالیتوب سره د لوستلو او لیکلو بار اندازه کوي. دا د ورته "ارورا" په پرتله خورا لوی توپیر او لوی پرمختګ دی ، کوم چې یوازې د لوستلو بار لري. سنو فلیک تاسو ته اجازه درکوي د دې کمپیوټري کلسترونو سره ستاسو د لیکلو کاري بار اندازه کړئ. دا، لکه څنګه چې ما یادونه وکړه، موږ په ManyChat کې ډیری کلسترونه کاروو، کوچني او خورا کوچني کلسترونه په عمده توګه د ETL لپاره کارول کیږي، د ډیټا بارولو لپاره. او شنونکي لا دمخه په متوسط کلسترونو کې ژوند کوي، کوم چې په بشپړ ډول د ETL بار لخوا اغیزمن شوي ندي، نو دوی ډیر چټک کار کوي.
په دې اساس، ډیټابیس د OLAP دندو لپاره مناسب دی. په هرصورت، له بده مرغه، دا لاهم د OLTP کاري بارونو لپاره د تطبیق وړ ندي. لومړی، دا ډیټابیس کالم دی، د ټولو راتلونکو پایلو سره. دوهم، پخپله طریقه، کله چې د هرې غوښتنې لپاره، که اړتیا وي، تاسو د کمپیوټر کلستر پورته کړئ او د معلوماتو سره یې سیلاب کړئ، له بده مرغه، د OLTP بار کولو لپاره لاهم ګړندی ندی. د OLAP دندو لپاره د ثانیو انتظار کول عادي خبره ده، مګر د OLTP دندو لپاره دا د منلو وړ نه ده؛ 100 ms به غوره وي، یا 10 ms به هم ښه وي.
نتیجه
بې سرور ډیټابیس د ډیټابیس په بې ریاسته او دولتي برخو ویشلو سره ممکن دی. تاسو شاید لیدلي وي چې په پورتنیو ټولو مثالونو کې، Stateful برخه ده، په نسبي ډول خبرې کول، په S3 کې د مایکرو پارشنونو ذخیره کول، او Stateless د اصلاح کونکی دی، د میټاډاټا سره کار کوي، د امنیتي مسلو اداره کول چې د خپلواک کم وزن لرونکي بې ریاست خدماتو په توګه راپورته کیدی شي.
د SQL پوښتنو اجرا کول د سپک ریاست خدماتو په توګه هم پیژندل کیدی شي چې کولی شي د سرور بې لارې حالت کې پاپ اپ شي ، لکه د سنو فلیک کمپیوټري کلسترونو په څیر ، یوازې اړین معلومات ډاونلوډ کړئ ، پوښتنه اجرا کړئ او "باهر لاړ شئ."
د سرور بې تولید کچې ډیټابیسونه دمخه د کارونې لپاره شتون لري ، دوی کار کوي. دا بې سرور ډیټابیسونه دمخه د OLAP دندو اداره کولو لپاره چمتو دي. له بده مرغه، د OLTP دندو لپاره دوی کارول کیږي ... د باریکیو سره، ځکه چې محدودیتونه شتون لري. له یوې خوا، دا یو منفي دی. مګر، له بلې خوا، دا یو فرصت دی. شاید یو لوستونکی به د اورورا محدودیتونو پرته د OLTP ډیټابیس په بشپړ ډول بې سرور کولو لپاره لاره ومومي.
زه هیله لرم چې تاسو یې په زړه پورې ومومئ. بې سرور راتلونکی دی 🙂
سرچینه: www.habr.com