هيلو سڀ! منهنجو نالو Golov Nikolay آهي. اڳي، مون Avito ۾ ڪم ڪيو ۽ ڇهن سالن تائين ڊيٽا پليٽ فارم کي منظم ڪيو، اهو آهي، مون سڀني ڊيٽابيسن تي ڪم ڪيو: تجزياتي (Vertica، ClickHouse)، اسٽريمنگ ۽ OLTP (Redis، Tarantool، VoltDB، MongoDB، PostgreSQL). هن عرصي دوران، مون ڊيٽابيس جي وڏي تعداد سان معاملو ڪيو - بلڪل مختلف ۽ غير معمولي، ۽ انهن جي استعمال جي غير معياري ڪيسن سان.
مان هن وقت ManyChat تي ڪم ڪري رهيو آهيان. ذات ۾، هي هڪ شروعاتي آهي - نئين، امڪاني ۽ تيزيء سان وڌندڙ. ۽ جڏهن مون پهريون ڀيرو ڪمپني ۾ شامل ٿيو، هڪ شاندار سوال پيدا ٿيو: "هاڻي هڪ نوجوان شروعاتي DBMS ۽ ڊيٽابيس مارڪيٽ مان ڇا وٺڻ گهرجي؟"
هن آرٽيڪل ۾، منهنجي رپورٽ جي بنياد تي ، مان هن سوال جو جواب ڏيندس. رپورٽ جو هڪ وڊيو نسخو موجود آهي تي .
عام طور تي ڄاڻايل ڊيٽابيس 2020
اهو 2020 آهي، مون چوڌاري ڏٺو ۽ ٽي قسم جا ڊيٽابيس ڏٺا.
پهريون قسم - کلاسک OLTP ڊيٽابيس: PostgreSQL, SQL Server, Oracle, MySQL. اهي گهڻو وقت اڳ لکيا ويا هئا، پر اڃا تائين لاڳاپيل آهن ڇو ته اهي ڊولپر ڪميونٽي کان تمام واقف آهن.
ٻيو قسم آهي "صفر" کان بنياد. انهن SQL، روايتي ڍانچي ۽ ACID کي ڇڏي، بلٽ ان شارڊنگ ۽ ٻين پرڪشش خصوصيتن کي شامل ڪندي کلاسي نمونن کان پري وڃڻ جي ڪوشش ڪئي. مثال طور، هي آهي Cassandra، MongoDB، Redis يا Tarantool. اهي سڀئي حل مارڪيٽ کي ڪجهه بنيادي طور تي نئين پيش ڪرڻ چاهيندا هئا ۽ انهن جي جڳهه تي قبضو ڪيو ڇو ته اهي ڪجهه خاص ڪمن لاء انتهائي آسان ٿي ويا. مان انهن ڊيٽابيس کي ڇنڊڇاڻ واري اصطلاح NOSQL سان ظاهر ڪندس.
"زيرو" ختم ٿي ويا، اسان کي NOSQL ڊيٽابيس جي عادت پئجي وئي، ۽ دنيا، منهنجي نقطي نظر کان، ايندڙ قدم کنيو. منظم ڊيٽابيس. انهن ڊيٽابيسن ۾ ساڳيو ئي بنيادي آهي جيئن کلاسک OLTP ڊيٽابيسس يا نوان NoSQL. پر انهن کي DBA ۽ DevOps جي ڪا ضرورت ناهي ۽ بادلن ۾ منظم هارڊويئر تي هلندا آهن. هڪ ڊولپر لاءِ، هي ”صرف هڪ بنياد“ آهي جيڪو ڪٿي ڪم ڪري ٿو، پر ڪنهن کي به پرواه ناهي ته اهو سرور تي ڪيئن نصب ٿيل آهي، ڪنهن سرور کي ترتيب ڏنو ۽ ڪير ان کي تازه ڪاري ڪري ٿو.
اهڙي ڊيٽابيس جا مثال:
- AWS RDS PostgreSQL/MySQL لاءِ هڪ منظم ريپر آهي.
- DynamoDB هڪ دستاويز جي بنياد تي ڊيٽابيس جو AWS اينالاگ آهي، جهڙوڪ Redis ۽ MongoDB.
- Amazon Redshift هڪ منظم تجزياتي ڊيٽابيس آهي.
اهي بنيادي طور تي پراڻا ڊيٽابيس آهن، پر هارڊويئر سان ڪم ڪرڻ جي ضرورت کان سواء، منظم ماحول ۾ پيدا ڪيا ويا آهن.
نوٽ. مثال AWS ماحول لاءِ ورتو وڃي ٿو، پر انهن جا اينالاگ Microsoft Azure، Google Cloud، يا Yandex.Cloud ۾ پڻ موجود آهن.
ان بابت نئون ڇا آهي؟ 2020 ۾، هن مان ڪو به نه.
بي سرور تصور
2020 ۾ مارڪيٽ تي ڇا واقعي نئون آهي بي سرور يا بي سرور حل.
مان وضاحت ڪرڻ جي ڪوشش ڪندس ته هن جو مطلب ڇا آهي هڪ باقاعده خدمت يا پس منظر واري ايپليڪيشن جو مثال استعمال ڪندي.
باقاعده پس منظر واري ايپليڪيشن کي ترتيب ڏيڻ لاءِ، اسان سرور خريد ڪري يا ڪرائي تي ڏيون ٿا، ان تي ڪوڊ ڪاپي ڪريون ٿا، آخري پوائنٽ ٻاهر شايع ڪريون ٿا ۽ باقاعدگي سان ڪرائي، بجلي ۽ ڊيٽا سينٽر سروسز لاءِ ادا ڪريون ٿا. هي معياري منصوبو آهي.
ٻيو ڪو طريقو آهي؟ بغير سرور جي خدمتن سان توهان ڪري سگهو ٿا.
هن نقطي جو مرڪز ڇا آهي: ڪو به سرور ناهي، ڪلائوڊ ۾ هڪ مجازي مثال به ڪرائي تي نه آهي. خدمت کي ترتيب ڏيڻ لاءِ، ڪوڊ (فنڪشن) کي مخزن ڏانهن نقل ڪريو ۽ ان کي آخري پوائنٽ تي شايع ڪريو. پوء اسان صرف هن فنڪشن لاء هر ڪال لاء ادا ڪندا آهيون، مڪمل طور تي هارڊويئر کي نظر انداز ڪندي جتي اهو عمل ڪيو ويندو آهي.
مان هن طريقي کي تصويرن سان بيان ڪرڻ جي ڪوشش ڪندس.
ڪلاسيڪل لڳائڻ. اسان وٽ ھڪڙي خدمت آھي ھڪڙي خاص لوڊ سان. اسان ٻه مثال اٿاريون ٿا: جسماني سرور يا مثال AWS ۾. ٻاهرين درخواستن کي انهن مثالن ڏانهن موڪليو ويو آهي ۽ اتي عمل ڪيو ويندو آهي.
جئين توهان تصوير ۾ ڏسي سگهو ٿا، سرورز برابر نه آهن. ھڪڙو 100٪ استعمال ٿيل آھي، اتي ٻه درخواستون آھن، ۽ ھڪڙو صرف 50٪ آھي - جزوي طور تي بيڪار. جيڪڏهن ٽي درخواستون نه اچن، پر 30، ته پوء سڄو سسٽم لوڊ کي منهن ڏيڻ جي قابل نه ٿيندو ۽ سست ٿيڻ شروع ٿي ويندو.
بغير سرور جي مقرري. بي سرور ماحول ۾، اهڙي خدمت ۾ مثال يا سرور نه هوندو آهي. هتي گرم وسيلن جو هڪ خاص تلاءُ آهي - ننڍا تيار ڪيل ڊاکر ڪنٽينرز سان گڏ مقرر ٿيل فنڪشن ڪوڊ. سسٽم خارجي درخواستون وصول ڪري ٿو ۽ انهن مان هر هڪ لاءِ بي سرور فريم ورڪ هڪ ننڍڙو ڪنٽينر کي ڪوڊ سان گڏ ڪري ٿو: اهو هن خاص درخواست تي عمل ڪري ٿو ۽ ڪنٽينر کي ماري ٿو.
ھڪڙي درخواست - ھڪڙو ڪنٽينر وڌايو، 1000 درخواستون - 1000 ڪنٽينر. ۽ هارڊويئر سرورز تي مقرري اڳ ۾ ئي ڪلائوڊ فراهم ڪندڙ جو ڪم آهي. اهو مڪمل طور تي لڪايو ويو آهي سرور کان سواء فريم ورڪ. هن تصور ۾ اسان هر ڪال لاء ادا ڪندا آهيون. مثال طور، هڪ ڪال هڪ ڏينهن آئي - اسان هڪ ڪال لاءِ ادا ڪيو، هڪ ملين في منٽ آيا - اسان هڪ ملين لاءِ ادا ڪيو. يا هڪ سيڪنڊ ۾، اهو پڻ ٿئي ٿو.
بغير سرور جي فنڪشن کي شايع ڪرڻ جو تصور بي رياست سروس لاءِ موزون آهي. ۽ جيڪڏھن توھان کي ضرورت آھي (رياست) اسٽيٽ فل سروس، پوءِ اسان سروس ۾ ڊيٽابيس شامل ڪريون ٿا. انهي صورت ۾، جڏهن اهو رياست سان ڪم ڪرڻ لاء اچي ٿو، هر اسٽيٽ فل فنڪشن صرف ڊيٽابيس مان لکي ٿو ۽ پڙهي ٿو. ان کان علاوه، مضمون جي شروعات ۾ بيان ڪيل ٽن قسمن مان ڪنهن به ڊيٽابيس مان.
انهن سڀني ڊيٽابيس جي عام حد ڇا آهي؟ اهي قيمتون آهن مسلسل استعمال ٿيل ڪلائوڊ يا هارڊويئر سرور (يا ڪيترائي سرور). اهو مسئلو ناهي ته ڇا اسان هڪ کلاسک يا منظم ڊيٽابيس استعمال ڪندا آهيون، ڇا اسان وٽ Devops ۽ هڪ منتظم آهي يا نه، اسان اڃا تائين هارڊويئر، بجلي ۽ ڊيٽا سينٽر رينجر 24/7 لاء ادا ڪندا آهيون. جيڪڏهن اسان وٽ هڪ کلاسک بنياد آهي، اسان ماسٽر ۽ غلام لاء ادا ڪندا آهيون. جيڪڏهن اهو هڪ انتهائي لوڊ ٿيل شارڊ ٿيل ڊيٽابيس آهي، اسان 10، 20 يا 30 سرورز لاء ادا ڪندا آهيون، ۽ اسان مسلسل ادا ڪندا آهيون.
قيمت جي جوڙجڪ ۾ مستقل طور تي محفوظ ڪيل سرورز جي موجودگي کي اڳ ۾ ئي ضروري برائي سمجهيو ويندو هو. روايتي ڊيٽابيس ۾ ٻيون مشڪلاتون پڻ آهن، جهڙوڪ ڪنيڪشن جي تعداد تي حدون، اسڪيلنگ جي پابنديون، جيو ورهايل اتفاق - اهي ڪنهن به طريقي سان ڪجهه ڊيٽابيس ۾ حل ڪري سگهجن ٿيون، پر سڀ هڪ ڀيرو ۽ مثالي طور تي نه.
بي سرور ڊيٽابيس - نظريو
2020 جو سوال: ڇا اهو ممڪن آهي ته ڊيٽابيس سرور کان سواءِ به؟ هرڪو ٻڌو آهي سرور لیس پس منظر جي باري ۾... اچو ته ڪوشش ڪريون ڊيٽابيس کي سرور کان سواءِ؟
اهو عجيب لڳي ٿو، ڇاڪاڻ ته ڊيٽابيس هڪ رياستي خدمت آهي، بلڪل بي سرور انفراسٽرڪچر لاءِ مناسب ناهي. ساڳئي وقت، ڊيٽابيس جي حالت تمام وڏي آهي: گيگا بائيٽ، ٽيرا بائيٽ، ۽ تجزياتي ڊيٽابيس ۾ پڻ پيٽابائيٽس. اهو ايترو آسان ناهي ته ان کي ٿلهي وزن واري ڊڪر ڪنٽينرز ۾ وڌائڻ.
ٻئي طرف، تقريبن سڀني جديد ڊيٽابيس ۾ وڏي مقدار ۾ منطق ۽ اجزاء شامل آهن: ٽرانزيڪشن، سالميت جي همراه، طريقا، لاڳاپا انحصار ۽ تمام گهڻو منطق. ڪافي ڊيٽابيس منطق لاء، هڪ ننڍڙي رياست ڪافي آهي. گيگا بائيٽس ۽ ٽيرابائٽس سڌو سنئون استعمال ڪيا ويندا آهن صرف هڪ ننڍڙو حصو ڊيٽابيس منطق جو سڌو سنئون عمل ڪرڻ ۾ شامل آهي.
ان جي مطابق، خيال آهي: جيڪڏهن منطق جو حصو رياستي عمل جي اجازت ڏئي ٿو، ڇو نه بنياد کي رياستي ۽ بي رياست حصن ۾ ورهايو وڃي.
OLAP حل لاءِ بي سرور
اچو ته ڏسون ته ڪھڙي ريت ھڪڙي ڊيٽابيس کي اسٽيٽ ۽ بي رياست حصن ۾ ڪٽڻ عملي مثالن کي استعمال ڪندي نظر اچي سگھي ٿو.
مثال طور، اسان وٽ هڪ تجزياتي ڊيٽابيس آهي: خارجي ڊيٽا (کاٻي پاسي ڳاڙهي سلنڈر)، هڪ ETL عمل جيڪو ڊيٽا کي ڊيٽابيس ۾ لوڊ ڪري ٿو، ۽ هڪ تجزيه نگار جيڪو SQL سوالن کي ڊيٽابيس ڏانهن موڪلي ٿو. هي هڪ کلاسک ڊيٽا گودام آپريشن اسڪيم آهي.
هن اسڪيم ۾، اي ٽي ايل هڪ ڀيرو مشروط طور تي ڪيو ويندو آهي. پوء توهان کي مسلسل انهن سرورن لاء ادا ڪرڻ جي ضرورت آهي جنهن تي ڊيٽابيس ETL سان ڀريل ڊيٽا سان هلندو آهي، انهي ڪري ته اتي سوالن کي موڪلڻ لاء ڪجهه آهي.
اچو ته AWS Athena Serverless ۾ لاڳو ڪيل متبادل طريقي تي نظر رکون. ڪو به مستقل طور تي وقف ٿيل هارڊويئر ناهي جنهن تي ڊائون لوڊ ڪيل ڊيٽا محفوظ ٿيل هجي. ان جي بدران:
- صارف جمع ڪري ٿو هڪ SQL سوال ايٿينا ڏانهن. Athena optimizer SQL سوال جو تجزيو ڪري ٿو ۽ ڳولهي ٿو ميٽا ڊيٽا اسٽور (Metadata) مخصوص ڊيٽا لاءِ جيڪو سوال کي انجام ڏيڻ لاءِ گهربل آهي.
- اصلاح ڪندڙ، گڏ ڪيل ڊيٽا جي بنياد تي، خارجي ذريعن کان ضروري ڊيٽا کي عارضي اسٽوريج (عارضي ڊيٽابيس) ۾ ڊائون لوڊ ڪري ٿو.
- صارف کان هڪ SQL سوال عارضي اسٽوريج ۾ عمل ڪيو ويندو آهي ۽ نتيجو صارف ڏانهن موٽايو ويندو آهي.
- عارضي اسٽوريج صاف ڪئي وئي آهي ۽ وسيلن کي آزاد ڪيو ويو آهي.
هن فن تعمير ۾، اسان صرف درخواست تي عمل ڪرڻ جي عمل لاء ادا ڪندا آهيون. ڪابه درخواست - ڪابه قيمت.
اهو هڪ ڪم ڪندڙ طريقو آهي ۽ لاڳو ٿئي ٿو نه رڳو ايٿينا سرور ۾، پر ريڊ شفٽ اسپيڪرم (AWS ۾).
Athena مثال ڏيکاري ٿو ته سرور لیس ڊيٽابيس حقيقي سوالن تي ڪم ڪري ٿو ٽينس ۽ سوين ٽيرابائيٽ ڊيٽا سان. سوين ٽيرابائٽس لاءِ سوين سرورن جي ضرورت پوندي، پر اسان کي انھن لاءِ ادا ڪرڻ جي ضرورت ناھي - اسان درخواستن لاءِ ادائيگي ڪندا آھيون. هر درخواست جي رفتار خاص تجزياتي ڊيٽابيس جي مقابلي ۾ (تمام گهٽ) آهي Vertica، پر اسان ادا نه ڪندا آهيون دير جي مدت لاءِ.
اهڙو ڊيٽابيس نادر تجزياتي ايڊهاڪ سوالن لاءِ لاڳو ٿئي ٿو. مثال طور، جڏهن اسان پاڻمرادو فيصلو ڪريون ٿا ته هڪ مفروضي کي جانچڻ لاءِ ڊيٽا جي ڪجهه وڏي مقدار تي. Athena انهن ڪيسن لاء ڀرپور آهي. باقاعده درخواستن لاء، اهڙي سسٽم قيمتي آهي. انهي حالت ۾، ڊيٽا کي ڪيش ڪريو ڪجهه خاص حل ۾.
OLTP حل لاءِ بي سرور
پوئين مثال OLAP (تجزياتي) ڪمن تي نظر اچي ٿو. هاڻي اچو ته OLTP ڪمن کي ڏسو.
اچو ته اسپيبلبل PostgreSQL يا MySQL تصور ڪريون. اچو ته گهٽ ۾ گهٽ وسيلن سان منظم منظم مثال PostgreSQL يا MySQL وڌون. جڏهن مثال وڌيڪ لوڊ حاصل ڪري ٿي، اسان اضافي ريپليڪس کي ڳنڍينداسين جنهن ۾ اسين پڙهڻ واري لوڊ جو حصو ورهائينداسين. جيڪڏهن ڪا به درخواست يا لوڊ نه آهي، اسان نقل بند ڪريون ٿا. پهريون مثال ماسٽر آهي، ۽ باقي replicas آهن.
اهو خيال هڪ ڊيٽابيس ۾ لاڳو ڪيو ويو آهي Aurora Serverless AWS. اصول سادو آهي: ٻاهرين ايپليڪيشنن کان درخواستون قبول ڪيون وينديون آهن پراکسي فليٽ. لوڊ وڌائڻ کي ڏسي، اهو ڪمپيوٽنگ وسيلن کي مختص ڪري ٿو اڳ-گرم ٿيل گهٽ ۾ گهٽ مثالن کان - ڪنيڪشن جيترو جلدي ٿي سگهي ٺاهيو وڃي. نااهل ڪرڻ جا واقعا ساڳيءَ طرح ٿين ٿا.
Aurora جي اندر Aurora Capacity Unit، ACU جو تصور آهي. هي آهي (مشروط طور) هڪ مثال (سرور). هر مخصوص ACU هڪ ماسٽر يا غلام ٿي سگهي ٿو. هر ظرفيت واري يونٽ کي پنهنجي RAM، پروسيسر ۽ گهٽ ۾ گهٽ ڊسڪ آهي. ان مطابق، ھڪڙو ماسٽر آھي، باقي پڙھيل صرف نقل آھن.
انهن Aurora ظرفيت يونٽن جو تعداد هلندڙ آهي هڪ ترتيب ڏيڻ وارو پيٽرول. گھٽ ۾ گھٽ مقدار ھڪڙي يا صفر ٿي سگھي ٿو (ھن صورت ۾، ڊيٽابيس ڪم نه ڪندو آھي جيڪڏھن ڪو درخواستون نه آھن).
جڏهن بنيادي درخواستون وصول ڪري ٿي، پراکسي فليٽ Aurora CapacityUnits وڌائيندو آهي، سسٽم جي ڪارڪردگي وسيلن کي وڌائيندو آهي. وسيلن کي وڌائڻ ۽ گھٽائڻ جي صلاحيت سسٽم کي "جگل" وسيلن جي اجازت ڏئي ٿي: خودڪار طور تي انفرادي ACUs ڏيکاري ٿو (انهن کي نئين سان تبديل ڪرڻ) ۽ واپس ڪيل وسيلن جي سڀني موجوده تازه ڪارين کي رول آئوٽ ڪريو.
Aurora Serverless بنياد پڙھڻ جي لوڊ کي ماپ ڪري سگھي ٿو. پر دستاويز اهو سڌو سنئون نه چوندا آهن. اهو محسوس ڪري سگھي ٿو ته اهي هڪ گهڻائي ماسٽر کڻندا. ڪو به جادو ناهي.
هي ڊيٽابيس غير متوقع رسائي سان سسٽم تي وڏي رقم خرچ ڪرڻ کان بچڻ لاءِ مناسب آهي. مثال طور، جڏهن MVP يا مارڪيٽنگ ڪاروباري ڪارڊ سائيٽن ٺاهڻ، اسان عام طور تي هڪ مستحڪم لوڊ جي اميد نه ڪندا آهيون. ان جي مطابق، جيڪڏهن ڪا رسائي نه آهي، اسان مثالن لاء ادا نه ڪندا آهيون. جڏهن اڻڄاتل لوڊ ٿئي ٿي، مثال طور ڪانفرنس يا اشتهاري مهم کان پوءِ، ماڻهن جو هجوم سائيٽ جو دورو ڪري ٿو ۽ لوڊ ڊرامائي طور تي وڌي ٿو، Aurora Serverless خود بخود هي لوڊ کڻندو آهي ۽ جلدي غائب وسيلن (ACU) کي ڳنڍيندو آهي. پوءِ ڪانفرنس گذري ٿي، هرڪو پروٽوٽائپ جي باري ۾ وساري ٿو، سرورز (ACU) اونداهو ٿي وڃن ٿا، ۽ قيمتون صفر ٿي وڃن ٿيون - آسان.
اهو حل مستحڪم هاء لوڊ لاء مناسب ناهي ڇو ته اهو لکڻ جي لوڊ کي ماپ نٿو ڪري. اهي سڀئي ڪنيڪشن ۽ وسيلن جا منسلڪ نام نهاد "اسڪيل پوائنٽ" تي واقع ٿين ٿا - وقت ۾ هڪ نقطو جڏهن ڊيٽابيس کي ٽرانزيڪشن يا عارضي جدولن سان سهڪار نه ڪيو وڃي. مثال طور، هڪ هفتي اندر اسڪيل پوائنٽ نه ٿي سگھي ٿي، ۽ بنيادي طور تي ساڳئي وسيلن تي ڪم ڪري ٿو ۽ صرف نه ٿي سگهي ٿو وڌائي يا معاهدو.
ڪو به جادو ناهي - اهو باقاعده PostgreSQL آهي. پر مشين کي شامل ڪرڻ ۽ انهن کي ختم ڪرڻ جو عمل جزوي طور تي خودڪار آهي.
بي ترتيب ڊيزائن
Aurora Serverless هڪ پراڻو ڊيٽابيس آهي جيڪو ڪلائوڊ لاءِ ٻيهر لکيو ويو آهي ته جيئن سرور بيس جي ڪجهه فائدن مان فائدو وٺن. ۽ ھاڻي مان توھان کي ٻڌايان ٿو بنيادي طور تي، جيڪو اصل ۾ ڪلائوڊ لاءِ لکيو ويو آھي، سرور جي بغير-سرور-بي-ڊزائن لاءِ. اهو فوري طور تي ترقي ڪئي وئي بغير تصور جي ته اهو جسماني سرور تي هلندو.
هن بنياد کي Snowflake سڏيو ويندو آهي. ان ۾ ٽي اهم بلاڪ آهن.
پهريون هڪ ميٽاداٽا بلاڪ آهي. هي هڪ تيز ميموري سروس آهي جيڪا سيڪيورٽي، ميٽا ڊيٽا، ٽرانزيڪشن، ۽ سوال جي اصلاح سان مسئلن کي حل ڪري ٿي (کاٻي پاسي جي تصوير ۾ ڏيکاريل آهي).
ٻيو بلاڪ حسابن لاءِ ورچوئل ڪمپيوٽنگ ڪلسٽرز جو هڪ سيٽ آهي (مثال ۾ نيري حلقن جو هڪ سيٽ آهي).
ٽيون بلاڪ S3 تي ٻڌل ڊيٽا اسٽوريج سسٽم آهي. S3 AWS ۾ بي ڊي ايميشن بيس آبجیکٹ اسٽوريج آهي، ڪاروبار لاءِ اهڙي قسم جي ڊائمشن بيس ڊروپباڪس.
اچو ته ڏسو ته برف فلڪ ڪيئن ڪم ڪري ٿو، هڪ سرد شروعات کي فرض ڪندي. اهو آهي، اتي هڪ ڊيٽابيس آهي، ڊيٽا ان ۾ لوڊ ڪئي وئي آهي، ڪو به هلندڙ سوال نه آهي. ان جي مطابق، جيڪڏهن ڊيٽابيس ڏانهن ڪا به درخواست نه آهي، ته پوء اسان تيز رفتار ان-ميموري ميٽاداٽا سروس (پهريون بلاڪ) کي وڌايو آهي. ۽ اسان وٽ S3 اسٽوريج آهي، جتي ٽيبل ڊيٽا محفوظ ڪئي وئي آهي، جنهن کي ورهايو ويو آهي نام نهاد micropartitions. سادگي لاءِ: جيڪڏهن ٽيبل ۾ ٽرانزيڪشن شامل آهن، ته پوءِ micropartitions ٽرانزيڪشن جا ڏينهن آهن. هر روز هڪ الڳ micropartition آهي، هڪ الڳ فائل. ۽ جڏهن ڊيٽابيس هن موڊ ۾ هلندي آهي، توهان صرف ڊيٽا جي قبضي واري جاء لاء ادا ڪندا آهيو. ان کان علاوه، في سيٽ جي شرح تمام گهٽ آهي (خاص طور تي اهم ڪمپريشن جي حساب سان). ميٽا ڊيٽا سروس پڻ مسلسل ڪم ڪري ٿي، پر توهان کي سوالن کي بهتر ڪرڻ لاء تمام گهڻو وسيلن جي ضرورت ناهي، ۽ خدمت سمجهي سگهجي ٿو شيئر ويئر.
هاڻي اچو ته تصور ڪريون ته هڪ صارف اسان جي ڊيٽابيس تي آيو ۽ هڪ SQL سوال موڪليو. SQL سوال فوري طور تي پروسيسنگ لاء ميٽا ڊيٽا سروس ڏانهن موڪليو ويو آهي. ان جي مطابق، هڪ درخواست حاصل ڪرڻ تي، هي خدمت درخواست جو تجزيو ڪري ٿو، دستياب ڊيٽا، صارف جي اجازتن ۽، جيڪڏهن سڀ ڪجهه ٺيڪ آهي، درخواست جي پروسيسنگ لاء هڪ منصوبو ٺاهي ٿو.
اڳيون، خدمت ڪمپيوٽنگ ڪلستر جي شروعات شروع ڪري ٿي. هڪ ڪمپيوٽنگ ڪلستر سرورز جو هڪ ڪلستر آهي جيڪو حساب سان انجام ڏئي ٿو. اھو آھي، اھو ھڪڙو ڪلستر آھي جنھن ۾ 1 سرور، 2 سرور، 4، 8، 16، 32 شامل آھن - جيترو توھان چاھيو. توهان هڪ درخواست اڇلائي ۽ هن ڪلستر جي لانچ کي فوري طور تي شروع ٿئي ٿو. اهو واقعي سيڪنڊن وٺندو آهي.
اڳيون، ڪلستر شروع ٿيڻ کان پوء، توهان جي درخواست تي عمل ڪرڻ لاء مائڪرو پارٽيشنز کي S3 کان ڪلستر ۾ نقل ٿيڻ شروع ڪيو. اهو آهي، اچو ته تصور ڪريو ته هڪ SQL سوال تي عمل ڪرڻ لاء توهان کي ضرورت آهي ٻه ڀاڱا هڪ ٽيبل مان ۽ هڪ ٻئي کان. انهي حالت ۾، صرف ٽي ضروري ورهاڱي ڪلستر ڏانهن نقل ڪيا ويندا، ۽ نه سڀئي ٽيبل مڪمل طور تي. اهو ئي سبب آهي، ۽ خاص طور تي ڇاڪاڻ ته هر شيء هڪ ڊيٽا سينٽر جي اندر واقع آهي ۽ تمام تيز چينلن سان ڳنڍيل آهي، منتقلي جو سڄو عمل تمام جلدي ٿئي ٿو: سيڪنڊن ۾، تمام گهٽ منٽن ۾، جيستائين اسان ڪجهه خوفناڪ درخواستن بابت ڳالهائي رهيا آهيون. ان جي مطابق، مائڪروپارٽيشنز کي ڪمپيوٽنگ ڪلستر ۾ نقل ڪيو ويو آهي، ۽، مڪمل ٿيڻ تي، SQL سوال هن ڪمپيوٽنگ ڪلستر تي عمل ڪيو ويندو آهي. هن درخواست جو نتيجو ٿي سگهي ٿو هڪ لڪير، ڪيترائي سٽون يا هڪ ٽيبل - اهي ٻاهرئين طور تي صارف ڏانهن موڪليا ويا آهن ته جيئن هو ان کي ڊائون لوڊ ڪري، ان کي پنهنجي BI اوزار ۾ ڏيکاري، يا ڪنهن ٻئي طريقي سان استعمال ڪري.
هر SQL سوال نه رڳو اڳئين لوڊ ٿيل ڊيٽا مان مجموعا پڙهي سگهي ٿو، پر ڊيٽابيس ۾ نئين ڊيٽا کي لوڊ / ٺاهي پڻ. اهو آهي، اهو هڪ سوال ٿي سگهي ٿو، مثال طور، هڪ ٻئي ٽيبل ۾ نوان رڪارڊ داخل ڪري ٿو، جيڪو ڪمپيوٽنگ ڪلستر تي نئين ورهاڱي جي ظاهر ٿيڻ جي ڪري ٿو، جيڪو، موڙ ۾، خودڪار طور تي هڪ واحد S3 اسٽوريج ۾ محفوظ ڪيو ويو آهي.
مٿي بيان ڪيل منظرنامو، صارف جي اچڻ کان وٺي ڪلسٽر جي اٿڻ تائين، ڊيٽا لوڊ ڪرڻ، سوالن تي عمل ڪرڻ، نتيجا حاصل ڪرڻ، ورچوئل ڪمپيوٽنگ ڪلسٽر، ورچوئل گودام استعمال ڪرڻ جي منٽن جي شرح تي ادا ڪئي ويندي آهي. قيمت AWS زون ۽ ڪلستر جي سائيز جي لحاظ کان مختلف ٿي سگھي ٿي، پر سراسري طور تي اھو ڪجھ ڊالر في ڪلاڪ آھي. چار مشينن جو هڪ ڪلستر ٻه ڀيرا قيمتي آهي ٻن مشينن جي ڪلستر جي ڀيٽ ۾، ۽ اٺن مشينن جو ڪلستر اڃا به ٻه ڀيرا قيمتي آهي. 16 جا اختيار، 32 مشينون موجود آهن، درخواستن جي پيچيدگي تي منحصر آهي. پر توهان صرف انهن منٽن لاءِ ادا ڪندا آهيو جڏهن ڪلسٽر اصل ۾ هلندي آهي، ڇاڪاڻ ته جڏهن ڪا به درخواست نه هوندي آهي، توهان هڪ قسم جا پنهنجا هٿ بند ڪندا آهيو، ۽ 5-10 منٽن جي انتظار کان پوءِ (هڪ ترتيب ڏيڻ وارو پيٽرول) اهو پنهنجو پاڻ ٻاهر نڪري ويندو، وسيلن کي آزاد ڪريو ۽ آزاد ٿيو.
هڪ مڪمل طور تي حقيقي منظر آهي جڏهن توهان هڪ درخواست موڪليندا آهيو، ڪلسٽر پاپ اپ ٿيندو آهي، نسبتا ڳالهائڻ، هڪ منٽ ۾، اهو هڪ ٻيو منٽ ڳڻيندو آهي، پوء بند ٿيڻ لاء پنج منٽ، ۽ توهان هن ڪلستر جي آپريشن جي ست منٽن لاء ادا ڪيو، ۽ مهينن ۽ سالن لاءِ نه.
هڪ واحد صارف سيٽنگ ۾ Snowflake استعمال ڪندي بيان ڪيل پهريون منظر. هاڻي اچو ته تصور ڪريو ته ڪيترائي صارف آهن، جيڪي حقيقي منظر جي ويجهو آهن.
اچو ته اسان وٽ ڪيترائي تجزيه نگار ۽ ٽيبلو رپورٽون آهن جيڪي مسلسل اسان جي ڊيٽابيس کي وڏي تعداد ۾ سادي تجزياتي SQL سوالن سان بمباري ڪن ٿيون.
ان کان علاوه، اچو ته چئو ته اسان وٽ ايجاد ڪندڙ ڊيٽا سائنسدان آهن جيڪي ڊيٽا سان خوفناڪ شيون ڪرڻ جي ڪوشش ڪري رهيا آهن، ڏهن ٽيرا بائيٽس سان هلائڻ، ڊيٽا جي اربين ۽ ٽريلين قطارن جو تجزيو ڪيو.
مٿي بيان ڪيل ٻن قسمن جي ڪم لوڊ لاءِ، Snowflake توهان کي اجازت ڏئي ٿو ته مختلف ظرفيت جا ڪيترائي آزاد ڪمپيوٽنگ ڪلسٽرز. ان کان علاوه، اهي ڪمپيوٽنگ ڪلستر آزاد طور تي ڪم ڪن ٿا، پر عام مسلسل ڊيٽا سان.
روشني جي سوالن جي وڏي تعداد لاء، توهان 2-3 ننڍا ڪلستر بلند ڪري سگهو ٿا، تقريبن 2 مشينون هر هڪ. اهو رويو لاڳو ڪري سگهجي ٿو، ٻين شين جي وچ ۾، خودڪار سيٽنگون استعمال ڪندي. تنهن ڪري توهان چئو ٿا، "برف جي ٽڪري، هڪ ننڍڙو ڪلستر بلند ڪريو. جيڪڏهن ان تي لوڊ هڪ خاص پيٽرولر کان مٿي وڌي وڃي، ساڳئي سيڪنڊ، ٽيون وڌايو. جڏهن لوڊ گهٽجڻ شروع ٿئي، اضافي کي وسايو." ان ڪري ته ڪيترا به تجزيه نگار اچن ۽ رپورٽون ڏسڻ شروع ڪن، هر ڪنهن وٽ ڪافي وسيلا آهن.
ساڳئي وقت، جيڪڏهن تجزيه نگار ننڊ ۾ آهن ۽ ڪو به رپورٽون نه ڏسي، ڪلستر مڪمل طور تي اونداهي ٿي سگهي ٿو، ۽ توهان انهن لاء ادا ڪرڻ بند ڪيو.
ساڳئي وقت، ڳري سوالن لاء (ڊيٽا سائنسدانن کان)، توهان 32 مشينن لاء هڪ تمام وڏو ڪلستر وڌائي سگهو ٿا. هي ڪلسٽر پڻ ادا ڪيو ويندو صرف انهن منٽن ۽ ڪلاڪن لاءِ جڏهن توهان جي وڏي درخواست اتي هلي رهي آهي.
مٿي بيان ڪيل موقعو توهان کي ورهائڻ جي اجازت ڏئي ٿو نه رڳو 2، پر ڪم لوڊ جا وڌيڪ قسم ڪلسٽرن ۾ (ETL، نگراني، رپورٽ مواد، ...).
اچو ته Snowflake کي مختصر ڪريون. بنيادي طور تي هڪ خوبصورت خيال ۽ قابل عمل عمل کي گڏ ڪري ٿو. ManyChat تي، اسان Snowflake استعمال ڪندا آهيون سڀني ڊيٽا جو تجزيو ڪرڻ لاءِ جيڪو اسان وٽ آهي. اسان وٽ ٽي ڪلستر نه آھن، مثال طور، پر 5 کان 9 تائين، مختلف سائزن جا. اسان وٽ روايتي 16-مشين، 2-مشين، ۽ ڪجھ ڪمن لاءِ سپر-ننڍي 1-مشينون آھن. اهي ڪاميابي سان لوڊ ورهائي رهيا آهن ۽ اسان کي تمام گهڻو بچائڻ جي اجازت ڏين ٿا.
ڊيٽابيس ڪاميابيءَ سان پڙھڻ ۽ لکڻ جي لوڊ کي گھٽائي ٿو. اهو هڪ تمام وڏو فرق آهي ۽ ساڳئي ”ارورا“ جي مقابلي ۾ هڪ وڏي پيش رفت آهي، جنهن صرف پڙهڻ جي لوڊشيڊنگ ڪئي. Snowflake توهان کي انهن ڪمپيوٽنگ ڪلسٽرن سان توهان جي لکڻ جي ڪم جي لوڊ کي ماپڻ جي اجازت ڏئي ٿي. اهو آهي، جيئن مون ذڪر ڪيو آهي، اسان ڪيترن ئي ڪلستر استعمال ڪندا آهيون ManyChat ۾، ننڍڙا ۽ سپر ننڍا ڪلستر خاص طور تي ETL لاءِ، ڊيٽا لوڊ ڪرڻ لاءِ استعمال ٿيندا آهن. ۽ تجزيه نگار اڳ ۾ ئي وچولي ڪلستر تي رهن ٿا، جيڪي بلڪل متاثر نه آهن ETL لوڊ، تنهنڪري اهي تمام جلدي ڪم ڪن ٿا.
ان جي مطابق، ڊيٽابيس OLAP ڪمن لاء مناسب آهي. بهرحال، بدقسمتي سان، اهو اڃا تائين OLTP ڪم لوڊ لاء لاڳو ناهي. پهرين، هي ڊيٽابيس ڪالمنر آهي، سڀني ايندڙ نتيجن سان. ٻيو، طريقو خود، جڏهن هر درخواست لاء، جيڪڏهن ضروري هجي ته، توهان هڪ ڪمپيوٽنگ ڪلستر کي وڌايو ۽ ان کي ڊيٽا سان ٻوڏايو، بدقسمتي سان، OLTP لوڊ ڪرڻ لاء ڪافي تيز نه آهي. OLAP ڪمن لاءِ سيڪنڊن جو انتظار ڪرڻ معمول آھي، پر OLTP ڪمن لاءِ اھو ناقابل قبول آھي؛ 100 ms بھتر ھوندو، يا 10 ms بھتر ھوندو.
نتيجو
هڪ سرور کان سواءِ ڊيٽابيس کي ڊيٽابيس کي رياستي ۽ غير رياستي حصن ۾ ورهائڻ سان ممڪن آهي. توهان شايد محسوس ڪيو هوندو ته مٿين سڀني مثالن ۾، رياستي حصو آهي، نسبتا ڳالهائڻ، S3 ۾ مائڪرو-پارٽيشنز کي محفوظ ڪرڻ، ۽ اسٽيٽ لیس بهتر آهي، ميٽا ڊيٽا سان ڪم ڪندي، سيڪيورٽي مسئلن کي هٿي ڏيڻ، جيڪي آزاد هلڪو اسٽيٽ بيس سروسز طور اٿاري سگهجن ٿيون.
SQL سوالن تي عمل ڪرڻ کي پڻ سمجھي سگھجي ٿو لائيٽ اسٽيٽ سروسز جيڪي بغير سرور موڊ ۾ پاپ اپ ڪري سگھن ٿيون، جھڙوڪ Snowflake ڪمپيوٽنگ ڪلسٽرز، صرف ضروري ڊيٽا ڊائون لوڊ ڪريو، سوال تي عمل ڪريو ۽ "ٻاھر وڃو."
بي سرور پيداوار جي سطح ڊيٽابيس اڳ ۾ ئي استعمال لاء موجود آهن، اهي ڪم ڪري رهيا آهن. اهي بي سرور ڊيٽابيس اڳ ۾ ئي OLAP ڪمن کي سنڀالڻ لاءِ تيار آهن. بدقسمتي سان، OLTP ڪمن لاءِ اهي استعمال ڪيا ويندا آهن... nuances سان، ڇاڪاڻ ته اتي حدون آهن. هڪ پاسي، هي هڪ مائنس آهي. پر، ٻئي طرف، هي هڪ موقعو آهي. شايد پڙهندڙن مان ڪو هڪ OLTP ڊيٽابيس کي مڪمل طور تي سرور کان سواءِ، ارورا جي حدن کان سواءِ هڪ طريقو ڳولي سگهندو.
مون کي اميد آهي ته توهان ان کي دلچسپ محسوس ڪيو. بي سرور مستقبل آهي :)
جو ذريعو: www.habr.com