سلام، د Khabrovsk اوسیدونکو. د کورس په لومړي ګروپ کې ټولګي نن پیل کیږي . په دې اړه، موږ غواړو تاسو ته ووایو چې په دې کورس کې د پرانیستې ویبینار څنګه ترسره شو.
В موږ د هغو ننګونو په اړه خبرې وکړې چې د بادل او کبرنیټس په دوره کې د SQL ډیټابیسونه ورسره مخ دي. په ورته وخت کې، موږ وګورو چې څنګه د SQL ډیټابیسونه د دې ننګونو تر اغیز لاندې تطابق او تغیر کوي.
ویبینار ترسره شو په EPAM سیسټمونو کې د ګوګل کلاوډ تمرین تحویلي مدیر.
کله چې ونې کوچنۍ وې ...
لومړی، راځئ چې په یاد ولرو چې د DBMS انتخاب څنګه د تیرې پیړۍ په پای کې پیل شو. په هرصورت، دا به ستونزمن نه وي، ځکه چې په دې ورځو کې د DBMS انتخاب پیل او پای ته ورسید سينه_پوښ.
د 90 لسیزې په وروستیو کې او د 2 لسیزې په لومړیو کې، په اصل کې هیڅ انتخاب نه و کله چې د صنعتي پیمانه وړ ډیټابیسونو خبره راځي. هو، دلته د IBM DBXNUMX، Sybase او ځینې نور ډیټابیسونه وو چې راغلل او لاړل، مګر په عموم کې دوی د اوریکل شالید په وړاندې د پام وړ ندي. په دې اساس، د هغه وخت د انجینرانو مهارتونه په یو ډول یوازینۍ انتخاب پورې تړلي وو چې شتون یې درلود.
اوریکل DBA باید وکوالی شي:
- د توزیع کټ څخه اوریکل سرور نصب کړئ؛
- د اوریکل سرور تنظیم کړئ:
- init.ora;
- listener.ora;
- جوړول:
- د میز ځایونه
- سکیمونه
- کاروونکي
- بیک اپ او بیا رغونه ترسره کړئ؛
- څارنه ترسره کول؛
- د غوره غوښتنو سره معامله وکړئ.
په ورته وخت کې، د اوریکل DBA څخه کومه ځانګړې اړتیا نه وه:
- د دې وړتیا ولرئ چې د ډیټا ذخیره کولو او پروسس کولو لپاره مطلوب DBMS یا نور ټیکنالوژي غوره کړئ؛
- د لوړ شتون او افقی پیمانه چمتو کول (دا تل د DBA مسله نه وه)؛
- د موضوع ساحه، زیربنا، د غوښتنلیک جوړښت، OS ښه پوهه؛
- د ډیټا بارول او پورته کول، د مختلفو DBMSs ترمنځ ډاټا لیږدول.
په عموم کې، که موږ په دې ورځو کې د انتخاب په اړه خبرې وکړو، دا د 80 لسیزې په وروستیو کې د شوروي پلورنځي انتخاب سره ورته دی:
زموږ وخت
له هغه وخت راهیسې، البته، ونې وده کړې، نړۍ بدله شوې، او دا یو څه داسې وګرځید:
د DBMS بازار هم بدل شوی، لکه څنګه چې د ګارټینر وروستي راپور څخه په واضح ډول لیدل کیدی شي:
او دلته باید یادونه وشي چې بادل، چې شهرت یې وده کوي، خپل ځای نیولی دی. که موږ ورته ګارټینر راپور ولولئ، نو موږ به لاندې پایلې وګورو:
- ډیری پیرودونکي بادل ته د غوښتنلیکونو لیږدولو په لاره کې دي.
- نوې ټیکنالوژي لومړی په بادل کې ښکاره کیږي او دا حقیقت ندی چې دوی به هیڅکله غیر بادل زیربنا ته لاړ شي.
- د تادیې په څیر د تادیې نرخ ماډل عام شوی. هرڅوک غواړي یوازې د هغه څه لپاره پیسې ورکړي چې دوی یې کاروي، او دا حتی یو رجحان نه دی، مګر یوازې د حقیقت بیان دی.
اوس څه؟
نن موږ ټول په بادل کې یو. او هغه پوښتنې چې زموږ لپاره راپورته کیږي د انتخاب پوښتنې دي. او دا خورا لوی دی ، حتی که موږ یوازې د DBMS ټیکنالوژیو انتخاب په اړه وغږیږو آن پریمیسس فارمیټ کې. موږ اداره شوي خدمات او SaaS هم لرو. په دې توګه، انتخاب یوازې هر کال ډیر ستونزمن کیږي.
د انتخاب پوښتنو سره سره، هم شتون لري محدود عوامل:
- نرخ. ډیری ټیکنالوژي لاهم پیسې لګوي؛
- مهارتونه. که موږ د وړیا سافټویر په اړه وغږیږو، نو د مهارتونو پوښتنه راپورته کیږي، ځکه چې وړیا سافټویر د خلکو څخه کافي وړتیا ته اړتیا لري څوک چې دا ځای په ځای کوي او چلوي؛
- فعال. ټول خدمات چې په کلاوډ کې شتون نلري او جوړ شوي، ووایه، حتی په ورته پوسټګریس کې، د پوسټګریس آن پریمیسس په څیر ورته ځانګړتیاوې لري. دا یو اړین فکتور دی چې باید پیژندل او پوه شي. سربیره پردې، دا فکتور د یو واحد DBMS د ځینو پټو وړتیاوو په اړه د پوهې په پرتله خورا مهم کیږي.
اوس د DA/DE څخه څه تمه کیږي:
- د موضوع ساحه او د غوښتنلیک جوړښت ښه پوهه؛
- د مناسب DBMS ټیکنالوژۍ په سمه توګه غوره کولو وړتیا، په لاس کې د دندې په پام کې نیولو سره؛
- د موجوده محدودیتونو په شرایطو کې د ټاکل شوي ټیکنالوژۍ پلي کولو لپاره د غوره میتود غوره کولو وړتیا؛
- د معلوماتو لیږد او مهاجرت ترسره کولو وړتیا؛
- د ټاکل شوي حلونو پلي کولو او چلولو وړتیا.
لاندې مثال د GCP پر بنسټ ښیي چې څنګه د ډیټا سره کار کولو لپاره د یو یا بل ټیکنالوژۍ انتخاب د دې جوړښت پورې اړه لري:
مهرباني وکړئ په یاد ولرئ چې PostgreSQL په سکیما کې نه دی شامل شوی، او دا ځکه چې دا د اصطلاحاتو لاندې پټ دی کلاوډ SQL. او کله چې موږ کلاوډ ایس کیو ایل ته ورسیږو، موږ اړتیا لرو چې بیا انتخاب وکړو:
دا باید په پام کې ونیول شي چې دا انتخاب تل روښانه نه وي، نو د غوښتنلیک پراختیا کونکي ډیری وختونه د الهام لخوا لارښوونه کیږي.
ټول:
- هرڅومره چې تاسو لاړشئ ، هومره د انتخاب پوښتنه راپورته کیږي. او حتی که تاسو یوازې GCP، اداره شوي خدماتو او SaaS ته وګورئ، بیا د RDBMS ځینې یادونه یوازې په څلورم ګام کې ښکاري (او هلته سپنر نږدې دی). برسیره پردې، د PostgreSQL انتخاب په پنځم ګام کې ښکاري، او د هغې تر څنګ د MySQL او SQL سرور هم شتون لري، دا دی دلته هرڅه شتون لري، مګر تاسو باید غوره کړئ.
- موږ باید د ازمایښتونو شالید پروړاندې د محدودیتونو په اړه هیر نکړو. اساسا هرڅوک سپنر غواړي، مګر دا ګران دی. د پایلې په توګه، یو عادي غوښتنه داسې ښکاري: "مهرباني وکړئ موږ ته سپنر جوړ کړئ مګر د کلاوډ ایس کیو ایل قیمت لپاره ، تاسو مسلکي یاست!"
څه باید وکړو؟
پرته له دې چې د حتمي حقیقت ادعا وکړو، راځئ چې لاندې ووایو:
موږ باید د زده کړې په اړه خپله تګلاره بدله کړو:
- د DBAs په څیر تدریس کولو کې هیڅ معنی شتون نلري؛
- د یو محصول پوهه نور بس نه ده؛
- مګر د یوې کچې په لسګونو پیژندل ناممکن دي.
تاسو اړتیا لرئ نه یوازې پوه شئ چې محصول څومره دی، مګر:
- د هغې د غوښتنلیک قضیه کارول؛
- د ځای پرځای کولو مختلف میتودونه؛
- د هرې میتود ګټې او زیانونه؛
- ورته او بدیل محصولات د خبرتیا او غوره انتخاب کولو لپاره او تل د پیژندل شوي محصول په ګټه نه وي.
تاسو دې ته هم اړتیا لرئ چې د ډیټا مهاجرت کولو وړتیا ولرئ او د ETL سره د ادغام په اساسی اصولو پوه شئ.
اصلي قضیه
په تیرو وختونو کې، دا اړینه وه چې د ګرځنده اپلیکیشن لپاره یو پس منظر جوړ کړئ. په هغه وخت کې چې په دې باندې کار پیل شو، د شاتنۍ برخه لا دمخه جوړه شوې وه او د تطبیق لپاره چمتو وه، او پراختیایی ټیم په دې پروژه شاوخوا دوه کاله تیر کړل. لاندې دندې ټاکل شوې وې:
- CI/CD جوړول؛
- د جوړښت بیاکتنه؛
- دا ټول په عمل کې واچوئ.
غوښتنلیک پخپله مایکرو خدمتونه و ، او د Python/Jjango کوډ له سکریچ څخه او مستقیم په GCP کې رامینځته شوی. لکه څنګه چې د نښه کونکو لیدونکو لپاره، داسې انګیرل کیده چې دوه سیمې به وي - متحده ایالات او EU، او ټرافیک د نړیوال بار بیلانس له لارې ویشل شوی و. ټول کاري بارونه او د کار بار محاسبه په ګوګل کوبرنیټ انجن کې روانه ده.
د معلوماتو لپاره، درې جوړښتونه شتون لري:
- د بادل ذخیره؛
- ډیټاسټور
- کلاوډ SQL (PostgreSQL).
یو شاید حیران شي چې ولې کلاوډ ایس کیو ایل غوره شوی؟ د ریښتیا ویلو لپاره، دا ډول پوښتنې په وروستیو کلونو کې د یو ډول ناڅاپه وقفې سبب شوي - داسې احساس شتون لري چې خلک د اړیکو ډیټابیسونو په اړه شرمیدلي، مګر بیا هم دوی په فعاله توګه د دوی کارولو ته دوام ورکوي؛-).
زموږ د قضیې لپاره، کلاوډ SQL د لاندې دلیلونو لپاره غوره شوی و:
- لکه څنګه چې یادونه وشوه، اپلیکیشن د جینګو په کارولو سره رامینځته شوی، او دا د SQL ډیټابیس څخه د Python شیانو (Jjango ORM) ته د دوامداره ډیټا نقشه کولو لپاره ماډل لري.
- چوکاټ پخپله د DBMSs کافي محدود لیست ملاتړ کوي:
- PostgreSQL;
- ماریا ډی بی
- MySQL;
- اوریکل؛
- SQLite.
په دې اساس، PostgreSQL د دې لیست څخه نه بلکه په شعوري ډول غوره شوی و (ښه، دا د اوریکل انتخاب نه دی، واقعیا).
څه ورک وو:
- غوښتنلیک یوازې په 2 سیمو کې ځای په ځای شوی و، او دریم یې په پلانونو (آسیا) کې څرګند شوی؛
- ډیټابیس د شمالي امریکا په سیمه (ایووا) کې موقعیت درلود؛
- د پیرودونکي په برخه کې د احتمال په اړه اندیښنې شتون درلود د لاسرسي ځنډ له اروپا او آسیا څخه او خنډونه په خدمت کې د DBMS بند وخت په صورت کې.
د دې حقیقت سره سره چې جینګو پخپله کولی شي د څو ډیټابیسونو سره په موازي توګه کار وکړي او په لوستلو او لیکلو یې وویشي ، په غوښتنلیک کې دومره لیکل شتون نلري (له 90٪ څخه ډیر لوستل کیږي). او په عموم کې، او په عمومي توګه، که دا ممکنه وه په اروپا او آسیا کې د اصلي اډې لوستلو نقل، دا به یو جوړجاړی حل وي. ښه، په دې کې څه پیچلي دي؟
ستونزه دا وه چې پیرودونکي نه غوښتل د مدیریت شوي خدماتو او کلاوډ SQL په کارولو سره پریږدي. او د کلاوډ SQL ظرفیتونه اوس مهال محدود دي. کلاوډ SQL د لوړ شتون (HA) او لوستلو نقل (RR) ملاتړ کوي ، مګر ورته RR یوازې په یوه سیمه کې ملاتړ کیږي. په امریکایی سیمه کې د ډیټابیس رامینځته کولو سره ، تاسو نشئ کولی په اروپایی سیمه کې د کلاوډ ایس کیو ایل په کارولو سره د لوستلو نقل جوړ کړئ ، که څه هم پوسټګریس پخپله تاسو د دې کولو مخه نه نیسي. د ګوګل د کارمندانو سره اړیکه هیڅ ځای ته نه وه رسیدلې او په ژمنو سره پای ته ورسیده "موږ ستونزه پوهیږو او کار کوو، یوه ورځ به ستونزه حل شي."
که موږ د کلاوډ SQL وړتیاوې په لنډه توګه لیست کړو، نو دا به داسې ښکاري:
1. لوړ شتون (HA):
- په یوه سیمه کې؛
- د ډیسک نقل له لارې؛
- PostgreSQL انجنونه نه کارول کیږي؛
- اتوماتیک او لاسي کنټرول ممکن - ناکامي / ناکامي؛
- کله چې بدل شي، DBMS د څو دقیقو لپاره شتون نلري.
2. نقل ولولئ (RR):
- په یوه سیمه کې؛
- ګرم سټینډبای؛
- د PostgreSQL سټرینګ نقل.
سربیره پردې، لکه څنګه چې دودیز دی، کله چې د ټیکنالوژۍ غوره کول تاسو تل د ځینو سره مخ کیږئ محدودیتونه:
- پیرودونکي نه غوښتل چې ادارې رامینځته کړي او IaaS وکاروي ، پرته د GKE له لارې؛
- پیرودونکی نه غواړي د ځان خدمت PostgreSQL/MySQL ځای په ځای کړي؛
- ښه، په عموم کې، د ګوګل سپنر به خورا مناسب وي که دا د دې قیمت لپاره نه وي، په هرصورت، Django ORM نشي کولی د دې سره کار وکړي، مګر دا یو ښه شی دی.
د وضعیت په پام کې نیولو سره، پیرودونکي یوه تعقیبي پوښتنه ترلاسه کړه: "ایا تاسو کولی شئ ورته یو څه ترسره کړئ چې دا د ګوګل سپنر په څیر وي، مګر د جینګو ORM سره هم کار کوي؟"
د حل انتخاب نمبر 0
لومړی شی چې ذهن ته راغی:
- په CloudSQL کې پاتې شئ؛
- د سیمو تر منځ به په هیڅ ډول جوړ شوی نقل نه وي؛
- هڅه وکړئ د PostgreSQL لخوا موجوده کلاوډ SQL ته نقل ضمیمه کړئ؛
- د PostgreSQL مثال په یو ځای او یو ډول لانچ کړئ ، مګر لږترلږه ماسټر ته لاس مه ورکوئ.
افسوس، دا معلومه شوه چې دا نشي ترسره کیدی، ځکه چې کوربه ته لاسرسی نشته (دا په بشپړه توګه په یوه بله پروژه کې دی) - pg_hba او داسې نور، او د سوپر یوزر لاندې هیڅ لاسرسی شتون نلري.
د حل انتخاب نمبر 1
د نورو انعکاس او پخوانیو شرایطو په پام کې نیولو وروسته، د فکر ریل یو څه بدل شو:
- موږ لاهم هڅه کوو چې په کلاوډ ایس کیو ایل کې پاتې شو ، مګر موږ مای ایس کیو ایل ته روان یو ، ځکه چې د مای ایس کیو ایل لخوا کلاوډ ایس کیو ایل یو بهرنی ماسټر لري ، کوم چې:
- د بهرني MySQL لپاره پراکسي ده؛
- د MySQL مثال په څیر ښکاري؛
- د نورو بادلونو یا آن پریمیسس څخه د معلوماتو لیږدولو لپاره اختراع شوی.
څرنګه چې د MySQL نقل ترتیب کول کوربه ته لاسرسي ته اړتیا نلري، په اصل کې هرڅه کار کوي، مګر دا خورا بې ثباته او ناامنه وه. او کله چې موږ نور لاړو، دا په بشپړه توګه ډارونکی شو، ځکه چې موږ ټول جوړښت د ټرافورم سره ځای په ځای کړی و، او ناڅاپه معلومه شوه چې بهرنی ماسټر د ټیرفارم لخوا ملاتړ نه کوي. هو، ګوګل یو CLI لري، مګر د ځینو دلیلونو لپاره هر څه دلته هر وخت کار کوي - کله ناکله دا رامینځته کیږي، ځینې وختونه دا ندي جوړ شوي. شاید ځکه چې CLI د بهرنیو معلوماتو مهاجرت لپاره اختراع شوی و، نه د نقلونو لپاره.
په حقیقت کې ، پدې مرحله کې دا څرګنده شوه چې کلاوډ ایس کیو ایل هیڅ مناسب ندی. لکه څنګه چې دوی وايي، موږ هر هغه څه وکړل چې موږ یې کولی شو.
د حل انتخاب نمبر 2
څرنګه چې دا ممکنه نه وه چې د کلاوډ SQL چوکاټ کې پاتې شي، موږ هڅه وکړه چې د موافقتنامې حل لپاره اړتیاوې چمتو کړو. اړتیاوې په لاندې ډول دي:
- په Kubernetes کې کار کول، د سرچینو او ظرفیتونو اعظمي ګټه اخیستنه د Kubernetes (DCS، ...) او GCP (LB، ...)؛
- په بادل کې د HA پراکسي په څیر د غیر ضروري شیانو له یوې ډلې څخه د ballast نشتوالی؛
- په اصلي HA سیمه کې د PostgreSQL یا MySQL چلولو وړتیا؛ په نورو سیمو کې - د اصلي سیمې د RR څخه HA او د هغې کاپي (د اعتبار لپاره)؛
- ملټي ماسټر (زه نه غواړم له هغه سره اړیکه ونیسم، مګر دا خورا مهم نه و)
.
د دغو غوښتنو په پایله کې، مخمناسب DBMS او پابند انتخابونه:
- مای ایس کیو ایل ګیلیرا؛
- کاکروچ ډي بي;
- د PostgreSQL وسیلې
:
- pgpool-II;
– پټروني
MySQL ګیلیرا
د MySQL Galera ټیکنالوژي د کوډرشپ لخوا رامینځته شوې او د InnoDB لپاره پلگ ان دی. ځانګړتیاوې:
- څو ماسټر
- همغږي نقل
- له هر نوډ څخه لوستل؛
- هر نوډ ته ثبت کول؛
- د HA میکانیزم جوړ شوی؛
- د Bitnami څخه د هیلم چارټ شتون لري.
کاکروچډ بي
د تفصیل له مخې، شی بالکل بم دی او د خلاصې سرچینې پروژه ده چې په ګو کې لیکل شوې. اصلي ګډون کوونکی د کاکروچ لابراتوار دی (د ګوګل څخه د خلکو لخوا تاسیس شوی). دا اړونده DBMS په اصل کې د توزیع کولو لپاره ډیزاین شوی و (د بکس څخه د افقی اندازه کولو سره) او د غلطۍ زغمونکی. د دې شرکت لیکوالانو د "NoSQL حلونو سره پیژندل شوي افقی لاسرسي سره د SQL فعالیت بډایه ترکیب" هدف په ګوته کړ.
یو ښه بونس د پوسټ ګریس اتصال پروتوکول ملاتړ دی.
pgpool
دا په PostgreSQL کې اضافه ده، په حقیقت کې، یو نوی اداره چې ټولې اړیکې نیسي او پروسس کوي. دا خپل د بار توازن او پارسر لري، د BSD جواز لاندې جواز لري. دا کافي فرصتونه چمتو کوي ، مګر یو څه ویره ښکاري ، ځکه چې د نوي وجود شتون ممکن د ځینې اضافي سفرونو سرچینه شي.
پټروني
دا وروستی شی دی چې زما سترګې پرې راوتلې، او لکه څنګه چې دا معلومه شوه، بې ګټې نه ده. پټروني د خلاصې سرچینې افادیت دی، کوم چې په اصل کې د Python ډیمون دی چې تاسو ته اجازه درکوي په اتوماتيک ډول د مختلف ډول نقل او اتوماتیک رول سویچنګ سره د PostgreSQL کلسترونه وساتئ. خبره ډیره په زړه پوري شوه، ځکه چې دا د کیوبر سره ښه مدغم کیږي او هیڅ نوي ادارې نه معرفي کوي.
تاسو په پای کې څه غوره کړل؟
انتخاب اسانه نه و:
- کاکروچډ بي - اور، مګر تیاره؛
- MySQL ګیلیرا - هم بد نه دی، دا په ډیری ځایونو کې کارول کیږي، مګر MySQL؛
- pgpool - ډیری غیر ضروري ادارې، نو د بادل او K8s سره یوځای کول؛
- پټروني - د K8s سره عالي ادغام ، هیڅ غیر ضروري نهادونه ، د GCP LB سره ښه مدغم کیږي.
په دې توګه، انتخاب د Patroni په غاړه شو.
موندنو
دا د لنډیز لپاره وخت دی. هو، د معلوماتي ټکنالوجۍ زیربنا نړۍ د پام وړ بدلون موندلی، او دا یوازې پیل دی. او که مخکې بادل یوازې یو بل ډول زیربنا و، اوس هر څه توپیر لري. سربیره پردې ، په ورېځو کې نوښتونه په دوامداره توګه څرګندیږي ، دوی به څرګند شي او شاید ، دوی به یوازې په ورېځو کې څرګند شي او یوازې بیا به د پیل کولو هڅو په واسطه ، آن پریمیسس ته لیږدول کیږي.
لکه څنګه چې د SQL لپاره، SQL به ژوند وکړي. دا پدې مانا ده چې تاسو اړتیا لرئ PostgreSQL او MySQL وپیژنئ او د دوی سره کار کولو وړ اوسئ ، مګر حتی خورا مهم دا دی چې د دوی سم کارولو وړ اوسئ.
سرچینه: www.habr.com