سلام، ساکنین خابروفسک. کلاس های گروه اول دوره از امروز شروع می شود . در همین راستا می خواهیم از نحوه برگزاری وبینار باز این دوره به شما بگوییم.
В ما در مورد چالش هایی که پایگاه داده های SQL در عصر ابرها و Kubernetes با آن روبرو هستند صحبت کردیم. در همان زمان، ما به نحوه انطباق و جهش پایگاه داده های SQL تحت تأثیر این چالش ها نگاه کردیم.
وبینار برگزار شد ، Google Cloud Practice Delivery Manager در EPAM Systems.
وقتی درخت ها کوچک بودند...
ابتدا بیایید به یاد بیاوریم که چگونه انتخاب DBMS در پایان قرن گذشته آغاز شد. با این حال، این کار دشواری نخواهد بود، زیرا انتخاب یک DBMS در آن روزها شروع شد و به پایان رسید وحی.
در اواخر دهه 90 و اوایل دهه 2، اساساً هیچ انتخابی در مورد پایگاه داده های مقیاس پذیر صنعتی وجود نداشت. بله، IBM DBXNUMX، Sybase و برخی پایگاه داده های دیگر بودند که آمدند و رفتند، اما در کل در پس زمینه اوراکل چندان قابل توجه نبودند. بر این اساس، مهارت مهندسان آن دوران به نوعی با تنها انتخابی که وجود داشت گره خورده بود.
Oracle DBA باید بتواند:
- سرور Oracle را از کیت توزیع نصب کنید.
- سرور اوراکل را پیکربندی کنید:
- init.ora;
- listener.ora;
- ايجاد كردن:
- فضاهای جدولی؛
- طرح ها
- کاربران؛
- انجام پشتیبان گیری و بازیابی
- انجام نظارت؛
- رسیدگی به درخواست های غیربهینه
در همان زمان، هیچ نیاز خاصی از Oracle DBA وجود نداشت:
- قادر به انتخاب DBMS بهینه یا سایر فناوری ها برای ذخیره و پردازش داده ها باشند.
- در دسترس بودن بالا و مقیاس پذیری افقی را فراهم می کند (این همیشه یک مسئله DBA نبود).
- دانش خوب از حوزه موضوعی، زیرساخت، معماری برنامه، سیستم عامل؛
- بارگیری و بارگیری داده ها، انتقال داده ها بین DBMS های مختلف.
به طور کلی، اگر در مورد انتخاب در آن روزها صحبت کنیم، شبیه به انتخاب یک فروشگاه شوروی در اواخر دهه 80 است:
وقت ما
از آن به بعد، البته، درختان رشد کردند، جهان تغییر کرد و چیزی شبیه به این شد:
بازار DBMS نیز تغییر کرده است، همانطور که از آخرین گزارش گارتنر به وضوح مشاهده می شود:
و در اینجا لازم به ذکر است که ابرهایی که محبوبیت آنها در حال افزایش است، جایگاه آنها را اشغال کرده است. اگر همین گزارش گارتنر را بخوانیم، نتایج زیر را خواهیم دید:
- بسیاری از مشتریان در مسیر انتقال اپلیکیشن ها به فضای ابری هستند.
- فناوری‌های جدید ابتدا در فضای ابری ظاهر می‌شوند و این یک واقعیت نیست که هرگز به زیرساخت‌های غیر ابری منتقل شوند.
- مدل قیمت‌گذاری پرداختی رایج شده است. همه می خواهند فقط برای چیزی که استفاده می کنند پول بپردازند، و این حتی یک روند نیست، بلکه صرفاً یک واقعیت است.
حالا چی؟
امروز همه ما در ابر هستیم. و سؤالاتی که برای ما پیش می آید سؤالات انتخابی است. و بسیار بزرگ است، حتی اگر فقط در مورد انتخاب فناوری های DBMS در قالب On-premises صحبت کنیم. ما همچنین خدمات مدیریت شده و SaaS را داریم. بنابراین، انتخاب تنها هر سال دشوارتر می شود.
همراه با سوالات انتخابی، نیز وجود دارد عوامل محدود کننده:
- قیمت. بسیاری از فناوری ها هنوز هم هزینه دارند.
- مهارت ها. اگر در مورد نرم‌افزار آزاد صحبت می‌کنیم، سؤال مهارت‌ها مطرح می‌شود، زیرا نرم‌افزار آزاد مستلزم صلاحیت کافی از سوی افرادی است که آن را مستقر و اجرا می‌کنند.
- کاربردی. همه سرویس‌هایی که در فضای ابری موجود هستند و مثلاً در همان Postgres ساخته می‌شوند، ویژگی‌های مشابه Postgres On-premises را ندارند. این یک عامل اساسی است که باید شناخته و درک شود. علاوه بر این، این عامل مهمتر از آگاهی از برخی قابلیت های پنهان یک DBMS واحد می شود.
آنچه اکنون از DA/DE انتظار می رود:
- درک خوب از حوزه موضوعی و معماری برنامه؛
- توانایی انتخاب صحیح فناوری DBMS مناسب با در نظر گرفتن وظیفه در دست انجام.
- توانایی انتخاب روش بهینه برای اجرای فناوری انتخاب شده در زمینه محدودیت های موجود؛
- توانایی انجام انتقال داده و مهاجرت؛
- توانایی پیاده سازی و اجرای راه حل های انتخاب شده
مثال زیر بر اساس GCP نشان می دهد که چگونه انتخاب یک یا دیگر فناوری برای کار با داده ها بسته به ساختار آن کار می کند:
لطفاً توجه داشته باشید که PostgreSQL در طرح گنجانده نشده است، و این به این دلیل است که تحت اصطلاحات پنهان است. ابر SQL. و وقتی به Cloud SQL رسیدیم، باید دوباره انتخاب کنیم:
لازم به ذکر است که این انتخاب همیشه واضح نیست، بنابراین توسعه دهندگان برنامه اغلب با شهود هدایت می شوند.
مجموع:
- هر چه جلوتر می روید، مسئله انتخاب مهم تر می شود. و حتی اگر فقط به GCP، سرویس های مدیریت شده و SaaS نگاه کنید، برخی از موارد ذکر شده از RDBMS فقط در مرحله چهارم ظاهر می شود (و Spanner در این نزدیکی است). به علاوه، انتخاب PostgreSQL در مرحله 4 ظاهر می شود و در کنار آن MySQL و SQL Server نیز وجود دارد، یعنی همه چیز زیاد است، اما شما باید انتخاب کنید.
- ما نباید محدودیت ها را در پس زمینه وسوسه ها فراموش کنیم. اساسا همه یک آچار می خواهند، اما گران است. در نتیجه، یک درخواست معمولی چیزی شبیه به این است: "لطفاً ما را یک آچار بسازید، اما برای قیمت Cloud SQL، شما حرفه ای هستید!"
اما چه باید کرد؟
بدون اینکه ادعا کنیم حقیقت نهایی است، بیایید موارد زیر را بگوییم:
ما باید رویکرد خود را به یادگیری تغییر دهیم:
- هیچ فایده ای در آموزش روشی که قبلاً DBA ها تدریس می شد وجود ندارد.
- دانش یک محصول دیگر کافی نیست.
- اما دانستن ده ها در سطح یک غیرممکن است.
شما نه تنها باید بدانید که محصول چقدر است، بلکه:
- مورد استفاده از کاربرد آن؛
- روش های مختلف استقرار؛
- مزایا و معایب هر روش؛
- محصولات مشابه و جایگزین برای انتخاب آگاهانه و بهینه و نه همیشه به نفع یک محصول آشنا.
همچنین باید بتوانید داده ها را انتقال دهید و اصول اولیه ادغام با ETL را درک کنید.
مورد واقعی
در گذشته نه چندان دور، لازم بود یک Backend برای یک اپلیکیشن موبایل ایجاد شود. زمانی که کار روی آن شروع شد، Backend قبلاً توسعه یافته بود و آماده اجرا بود و تیم توسعه حدود دو سال را روی این پروژه وقت گذاشت. وظایف زیر تعیین شد:
- ساخت CI/CD؛
- بررسی معماری؛
- همه را به بهره برداری رساند.
خود برنامه میکروسرویس بود و کد پایتون/جانگو از ابتدا و مستقیماً در GCP توسعه داده شد. در مورد مخاطب هدف، فرض بر این بود که دو منطقه وجود دارد - ایالات متحده و اتحادیه اروپا، و ترافیک از طریق متعادل کننده بار جهانی توزیع می شود. همه بارهای کاری و محاسبات بار کاری در Google Kubernetes Engine اجرا شد.
در مورد داده ها، 3 ساختار وجود دارد:
- فضای ذخیره ابری؛
- ذخیره‌گاه داده؛
- Cloud SQL (PostgreSQL).
ممکن است تعجب کنید که چرا Cloud SQL انتخاب شد؟ حقیقت را بگویم، چنین سوالی در سال های اخیر باعث ایجاد نوعی مکث ناخوشایند شده است - این احساس وجود دارد که مردم از پایگاه داده های رابطه ای خجالتی شده اند، اما با این وجود همچنان به طور فعال از آنها استفاده می کنند ;-).
در مورد مورد ما، Cloud SQL به دلایل زیر انتخاب شد:
- همانطور که گفته شد، این برنامه با استفاده از جنگو توسعه یافته است و دارای مدلی برای نگاشت داده های پایدار از پایگاه داده SQL به اشیاء پایتون (Django ORM) است.
- خود چارچوب از لیست نسبتاً محدودی از DBMS ها پشتیبانی می کند:
- PostgreSQL;
- MariaDB;
- MySQL;
- اوراکل
- SQLite.
بر این اساس، PostgreSQL از این لیست نسبتاً شهودی انتخاب شد (خب، واقعاً انتخاب اوراکل نیست).
آنچه گم شده بود:
- این برنامه فقط در 2 منطقه مستقر شد و سومین مورد در برنامه ها (آسیا) ظاهر شد.
- پایگاه داده در منطقه آمریکای شمالی (آیووا) واقع شده است.
- از طرف مشتری نگرانی هایی در مورد احتمال وجود داشت تاخیرهای دسترسی از اروپا و آسیا و وقفه ها در خدمت در صورت خرابی DBMS
علیرغم این واقعیت که خود جنگو می تواند با چندین پایگاه داده به صورت موازی کار کند و آنها را به خواندن و نوشتن تقسیم کند، نوشتن آنقدر در برنامه وجود نداشت (بیش از 90٪ در حال خواندن هستند). و به طور کلی و به طور کلی اگر ممکن بود انجام شود خواندن ماکت از پایگاه اصلی در اروپا و آسیا، این یک راه حل مصالحه خواهد بود. خوب، چه چیزی در آن پیچیده است؟
مشکل این بود که مشتری نمی خواست استفاده از خدمات مدیریت شده و Cloud SQL را رها کند. و قابلیت های Cloud SQL در حال حاضر محدود است. Cloud SQL از دسترسی بالا (HA) و Read Replica (RR) پشتیبانی می کند، اما همان RR فقط در یک منطقه پشتیبانی می شود. با ایجاد یک پایگاه داده در منطقه آمریکا، نمی توانید با استفاده از Cloud SQL یک نسخه خواندنی در منطقه اروپا ایجاد کنید، اگرچه خود Postgres شما را از انجام این کار منع نمی کند. نامه نگاری با کارمندان گوگل به جایی نرسید و با وعده هایی به سبک "ما مشکل را می دانیم و در حال کار روی آن هستیم، روزی مشکل حل خواهد شد" به پایان رسید.
اگر به طور خلاصه قابلیت های Cloud SQL را فهرست کنیم، چیزی شبیه به این خواهد بود:
1. در دسترس بودن بالا (HA):
- در یک منطقه؛
- از طریق تکرار دیسک؛
- موتورهای PostgreSQL استفاده نمی شوند.
- امکان کنترل خودکار و دستی - failover/failback.
- هنگام تعویض، DBMS برای چند دقیقه در دسترس نیست.
2. Replica (RR) را بخوانید:
- در یک منطقه؛
- آماده به کار داغ؛
- تکرار جریان PostgreSQL.
علاوه بر این، همانطور که مرسوم است، هنگام انتخاب یک فناوری همیشه با برخی از آنها روبرو می شوید محدودیت های:
- مشتری نمی‌خواهد موجودیت‌هایی ایجاد کند و از IaaS استفاده کند، مگر از طریق GKE.
- مشتری تمایلی به استقرار خود سرویس PostgreSQL/MySQL ندارد.
- خب، به طور کلی، Google Spanner اگر به خاطر قیمتش نبود، کاملاً مناسب بود، با این حال، جنگو ORM نمی تواند با آن کار کند، اما چیز خوبی است.
با توجه به وضعیت، مشتری یک سوال بعدی دریافت کرد: "آیا می توانید کاری مشابه انجام دهید تا مانند Google Spanner باشد، اما با Django ORM نیز کار کند؟"
گزینه حل شماره 0
اولین چیزی که به ذهنم رسید:
- در CloudSQL بمانید.
- هیچ تکرار داخلی بین مناطق به هیچ شکلی وجود نخواهد داشت.
- سعی کنید یک ماکت به یک Cloud SQL موجود توسط PostgreSQL متصل کنید.
- یک نمونه PostgreSQL را در جایی و به نحوی راه اندازی کنید، اما حداقل Master را لمس نکنید.
افسوس، معلوم شد که نمی توان این کار را انجام داد، زیرا دسترسی به هاست وجود ندارد (کلاً در یک پروژه متفاوت است) - pg_hba و غیره، و همچنین دسترسی تحت superuser وجود ندارد.
گزینه حل شماره 1
پس از تأمل بیشتر و در نظر گرفتن شرایط قبلی، رشته فکر تا حدودی تغییر کرد:
- ما همچنان سعی می‌کنیم در CloudSQL بمانیم، اما در حال تغییر به MySQL هستیم، زیرا Cloud SQL توسط MySQL یک استاد خارجی دارد که:
- یک پروکسی برای MySQL خارجی است.
- شبیه یک نمونه MySQL است.
- برای انتقال داده ها از دیگر ابرها یا در محل اختراع شده است.
از آنجایی که راه اندازی MySQL Replication نیازی به دسترسی به هاست ندارد، در اصل همه چیز کار می کرد، اما بسیار ناپایدار و ناخوشایند بود. و وقتی جلوتر رفتیم، کاملاً ترسناک شد، زیرا کل ساختار را با ترافورم مستقر کردیم و ناگهان معلوم شد که استاد خارجی توسط ترافورم پشتیبانی نمی شود. بله، Google یک CLI دارد، اما به دلایلی همه چیز اینجا کار می کرد - گاهی اوقات ایجاد می شود، گاهی اوقات ایجاد نمی شود. شاید به این دلیل که CLI برای انتقال داده های خارجی اختراع شده است، نه برای کپی کردن.
در واقع، در این مرحله مشخص شد که Cloud SQL اصلا مناسب نیست. همانطور که می گویند ما هر کاری از دستمان برمی آمد انجام دادیم.
گزینه حل شماره 2
از آنجایی که امکان ماندن در چارچوب Cloud SQL وجود نداشت، ما سعی کردیم الزامات را برای یک راه حل مصالحه فرموله کنیم. الزامات به شرح زیر مشخص شد:
- کار در Kubernetes، حداکثر استفاده از منابع و قابلیت های Kubernetes (DCS، ...) و GCP (LB، ...)؛
- عدم وجود بالاست از یک سری چیزهای غیر ضروری در ابر مانند پراکسی HA.
- توانایی اجرای PostgreSQL یا MySQL در منطقه اصلی HA. در مناطق دیگر - HA از RR منطقه اصلی به اضافه کپی آن (برای قابلیت اطمینان).
- چند استاد (نمی خواستم با او تماس بگیرم، اما خیلی مهم نبود)
.
در نتیجه این مطالبات، صDBMS مناسب و گزینه های الزام آور:
- MySQL Galera;
- سوسک DB;
- ابزارهای PostgreSQL
:
- pgpool-II؛
- حامی
MySQL Galera
فناوری MySQL Galera توسط Codership توسعه یافته است و یک افزونه برای InnoDB است. ویژگی ها:
- چند استاد؛
- همانندسازی همزمان؛
- خواندن از هر گره؛
- ضبط به هر گره.
- مکانیزم داخلی HA؛
- یک نمودار Helm از بیتنامی وجود دارد.
سوسک
طبق توضیحات، این چیز کاملاً بمب است و یک پروژه متن باز است که در Go نوشته شده است. شرکت کننده اصلی Cockroach Labs (که توسط افرادی از Google تأسیس شده است) است. این DBMS رابطه ای در اصل برای توزیع (با مقیاس افقی خارج از جعبه) و تحمل خطا طراحی شده بود. نویسندگان آن از این شرکت هدف "ترکیب غنای عملکرد SQL با دسترسی افقی آشنا به راه حل های NoSQL" را مشخص کردند.
یک امتیاز خوب پشتیبانی از پروتکل اتصال پس از پیشرفت است.
pgpool
این یک افزونه برای PostgreSQL است، در واقع یک موجودیت جدید است که تمام اتصالات را در اختیار گرفته و آنها را پردازش می کند. دارای بار متعادل کننده و تجزیه کننده خاص خود است که تحت مجوز BSD مجوز دارد. فرصت‌های فراوانی را فراهم می‌کند، اما تا حدودی ترسناک به نظر می‌رسد، زیرا حضور یک موجودیت جدید می‌تواند منبع برخی از ماجراهای اضافی باشد.
حامی
این آخرین چیزی است که چشمم به آن افتاد و همانطور که معلوم شد بیهوده نیست. Patroni یک ابزار منبع باز است که در اصل یک شبح پایتون است که به شما امکان می دهد به طور خودکار خوشه های PostgreSQL را با انواع مختلف تکرار و تغییر نقش خودکار نگهداری کنید. این چیز بسیار جالب بود، زیرا به خوبی با cuber ادغام می شود و هیچ موجودیت جدیدی را معرفی نمی کند.
در نهایت چه چیزی را انتخاب کردید؟
انتخاب آسان نبود:
- سوسک - آتش، اما تاریک؛
- MySQL Galera - همچنین بد نیست، در بسیاری از جاها استفاده می شود، اما MySQL.
- pgpool - بسیاری از موجودیت های غیر ضروری، بنابراین ادغام با ابر و K8s.
- حامی - ادغام عالی با K8 ها، بدون موجودیت های غیر ضروری، به خوبی با GCP LB ادغام می شود.
بنابراین، انتخاب بر عهده پاترونی افتاد.
یافته ها
وقت آن است که به طور خلاصه جمع بندی کنیم. بله، دنیای زیرساخت های فناوری اطلاعات به طور قابل توجهی تغییر کرده است و این تازه آغاز راه است. و اگر قبلا ابرها نوع دیگری از زیرساخت بودند، اکنون همه چیز متفاوت است. علاوه بر این، نوآوری‌ها در ابرها دائماً ظاهر می‌شوند، ظاهر می‌شوند و شاید فقط در ابرها ظاهر شوند و تنها پس از آن، با تلاش استارت‌آپ‌ها، به On-premises منتقل می‌شوند.
همانطور که برای SQL، SQL زنده خواهد بود. این بدان معنی است که شما باید PostgreSQL و MySQL را بشناسید و بتوانید با آنها کار کنید، اما مهمتر از آن این است که بتوانید از آنها به درستی استفاده کنید.
منبع: www.habr.com