Salam Xabrovsk sakinləri. Kursun birinci qrupunda dərslər bu gün başlayır . Bununla əlaqədar olaraq, bu kurs üzrə açıq vebinarın necə baş tutması barədə məlumat vermək istərdik.
В buludlar və Kubernetes dövründə SQL verilənlər bazalarının üzləşdiyi çətinliklərdən danışdıq. Eyni zamanda, biz SQL verilənlər bazalarının bu çağırışların təsiri altında necə uyğunlaşdığını və mutasiya etdiyini nəzərdən keçirdik.
vebinar keçirilib , EPAM Systems-də Google Bulud Təcrübəsi Çatdırılma Meneceri.
Ağaclar balaca olanda...
Əvvəlcə DBMS seçiminin ötən əsrin sonunda necə başladığını xatırlayaq. Bununla belə, bu çətin olmayacaq, çünki o günlərdə DBMS seçimi başladı və bitdi Kahin.
90-cı illərin sonu və 2-ci illərin əvvəllərində sənaye genişlənə bilən verilənlər bazalarına gəldikdə, əslində heç bir seçim yox idi. Bəli, IBM DBXNUMX, Sybase və bir neçə başqa verilənlər bazası gəlib-gedən var idi, lakin ümumilikdə Oracle fonunda onlar o qədər də nəzərə çarpmırdı. Müvafiq olaraq, o dövrün mühəndislərinin bacarıqları bir növ mövcud olan yeganə seçimlə bağlı idi.
Oracle DBA aşağıdakıları bacarmalıdır:
- paylama dəstindən Oracle Server quraşdırın;
- Oracle Serverini konfiqurasiya edin:
- init.ora;
- dinləyici.ora;
- yaratmaq:
- masa boşluqları;
- sxem;
- istifadəçilər;
— ehtiyat nüsxəsini çıxarmaq və bərpa etmək;
— monitorinqin aparılması;
- optimal olmayan sorğularla məşğul olmaq.
Eyni zamanda, Oracle DBA-dan heç bir xüsusi tələb yox idi:
- məlumatların saxlanması və emalı üçün optimal DBMS və ya digər texnologiyanı seçməyi bacarmalı;
- yüksək əlçatanlığı və üfüqi miqyaslılığı təmin edin (bu, həmişə DBA məsələsi deyildi);
- mövzu sahəsi, infrastruktur, tətbiq arxitekturası, ƏS haqqında yaxşı bilik;
- məlumatları yükləyin və boşaltın, müxtəlif DBMS-lər arasında məlumat köçürün.
Ümumiyyətlə, o günlərdəki seçimdən danışsaq, 80-ci illərin sonlarında sovet mağazasındakı seçimə bənzəyir:
Bizim vaxtımız
O vaxtdan bəri, əlbəttə ki, ağaclar böyüdü, dünya dəyişdi və belə bir şey oldu:
Gartner-in son hesabatından aydın göründüyü kimi DBMS bazarı da dəyişdi:
Və burada qeyd etmək lazımdır ki, populyarlığı artan buludlar öz yerlərini tutublar. Eyni Gartner hesabatını oxusaq, aşağıdakı nəticələri görəcəyik:
- Bir çox müştəri proqramları buludlara köçürmək yolundadır.
- Yeni texnologiyalar əvvəlcə buludda meydana çıxır və onların nə vaxtsa bulud olmayan infrastruktura keçəcəyi faktı deyil.
- Getdikcə ödə qiymət modeli adi hala çevrilib. Hər kəs yalnız istifadə etdiyi şeyə görə pul ödəmək istəyir və bu, hətta bir tendensiya deyil, sadəcə bir həqiqətdir.
İndi nə?
Bu gün hamımız buluddayıq. Bizim üçün yaranan suallar isə seçim suallarıdır. Yalnız yerli formatda DBMS texnologiyalarının seçimindən danışsaq belə, bu, böyükdür. Bizdə idarə olunan xidmətlər və SaaS da var. Beləliklə, seçim hər il daha da çətinləşir.
Seçimlə bağlı suallarla yanaşı, var məhdudlaşdıran amillər:
- qiymət. Bir çox texnologiyalar hələ də pula başa gəlir;
- bacarıqlar. Əgər pulsuz proqram təminatından danışırıqsa, onda bacarıqlar məsələsi ortaya çıxır, çünki pulsuz proqram təminatı onu yerləşdirən və işlədən insanlardan kifayət qədər bacarıq tələb edir;
- funksional. Buludda mövcud olan və məsələn, hətta eyni Postgres-də qurulan bütün xidmətlər Postgres On-premises ilə eyni xüsusiyyətlərə malik deyil. Bu, tanınmalı və başa düşülməli olan vacib amildir. Üstəlik, bu amil tək bir DBMS-nin bəzi gizli imkanlarını bilməkdən daha vacib olur.
İndi DA/DE-dən nə gözlənilir:
- mövzu sahəsini və tətbiq arxitekturasını yaxşı başa düşmək;
- qarşıya qoyulan vəzifəni nəzərə alaraq müvafiq DBMS texnologiyasını düzgün seçmək bacarığı;
- mövcud məhdudiyyətlər kontekstində seçilmiş texnologiyanın həyata keçirilməsi üçün optimal metodu seçmək imkanı;
- məlumatların ötürülməsi və miqrasiyasını həyata keçirmək imkanı;
- seçilmiş həlləri həyata keçirmək və idarə etmək bacarığı.
Aşağıdakı nümunə GCP əsasında məlumatlarla işləmək üçün bu və ya digər texnologiyanın seçiminin strukturundan asılı olaraq necə işlədiyini nümayiş etdirir:
Nəzərə alın ki, PostgreSQL sxemə daxil edilməyib və bunun səbəbi terminologiya altında gizlədilməsidir. Bulud SQL. Cloud SQL-ə çatanda yenidən seçim etməliyik:
Qeyd etmək lazımdır ki, bu seçim həmişə aydın deyil, ona görə də proqram tərtibatçıları çox vaxt intuisiya ilə idarə olunurlar.
Ümumi:
- Nə qədər irəli getsəniz, seçim məsələsi bir o qədər aktuallaşır. Yalnız GCP, idarə olunan xidmətlər və SaaS-ə baxsanız belə, RDBMS haqqında bəzi qeydlər yalnız 4-cü addımda görünür (və orada Spanner yaxınlıqdadır). Üstəlik, PostgreSQL seçimi 5-ci addımda görünür və onun yanında MySQL və SQL Server də var, yəni. hər şey çoxdur, amma seçmək lazımdır.
- Vəsvəsələrin fonunda məhdudiyyətləri unutmaq olmaz. Əsasən hər kəs bir Anahtar istəyir, lakin bahadır. Nəticədə tipik bir sorğu belə görünür: "Lütfən, bizə bir açar hazırlayın, lakin Cloud SQL qiymətinə görə siz peşəkarsınız!"
Biz nə etməliyik?
Son həqiqət olduğunu iddia etmədən, aşağıdakıları deyək:
Öyrənməyə yanaşmamızı dəyişdirməliyik:
- DBA-nın əvvəllər öyrədildiyi yolu öyrətməyin mənası yoxdur;
- bir məhsul haqqında bilik artıq kifayət deyil;
- lakin bir səviyyəsində onlarla bilmək mümkün deyil.
Yalnız məhsulun nə qədər olduğunu deyil, həm də bilməlisiniz:
- onun tətbiqindən istifadə halı;
- müxtəlif yerləşdirmə üsulları;
- hər bir metodun üstünlükləri və çatışmazlıqları;
- məlumatlı və optimal seçim etmək üçün oxşar və alternativ məhsullar və həmişə tanış məhsulun xeyrinə deyil.
Siz həmçinin məlumatları köçürməyi bacarmalı və ETL ilə inteqrasiyanın əsas prinsiplərini başa düşməlisiniz.
real hal
Yaxın keçmişdə mobil proqram üçün backend yaratmaq lazım idi. Onun üzərində iş başlayana qədər arxa plan artıq hazırlanmış və həyata keçirilməyə hazır idi və inkişaf qrupu bu layihəyə təxminən iki il sərf etdi. Aşağıdakı vəzifələr qoyuldu:
- CI/CD qurmaq;
- memarlığı nəzərdən keçirin;
- hamısını işə salın.
Tətbiqin özü mikroservislər idi və Python/Django kodu sıfırdan və birbaşa GCP-də işlənib hazırlanmışdır. Hədəf auditoriyaya gəlincə, burada iki regionun - ABŞ və Aİ-nin olacağı güman edilirdi və trafik Qlobal Yük balanslaşdırıcısı vasitəsilə paylanır. Bütün iş yükləri və hesablama iş yükü Google Kubernetes Mühərrikində işləyirdi.
Məlumatlara gəlincə, 3 struktur var idi:
- Bulud Saxlama;
- Məlumat anbarı;
- Bulud SQL (PostgreSQL).
Cloud SQL-in niyə seçildiyini düşünmək olar? Düzünü desəm, belə bir sual son illərdə bir növ yöndəmsiz fasiləyə səbəb oldu - belə bir hiss var ki, insanlar əlaqəli verilənlər bazalarından utanırlar, lakin buna baxmayaraq, onlardan fəal istifadə etməyə davam edirlər ;-).
Bizim vəziyyətimizə gəldikdə, Cloud SQL aşağıdakı səbəblərə görə seçildi:
- Qeyd edildiyi kimi, proqram Django istifadə edərək hazırlanmışdır və o, SQL verilənlər bazasından Python obyektlərinə (Django ORM) davamlı məlumatların xəritələşdirilməsi üçün bir modelə malikdir.
- Çərçivə özü DBMS-lərin kifayət qədər məhdud siyahısını dəstəkləyirdi:
- PostgreSQL;
- MariaDB;
- MySQL
- kahinlər;
- SQLite.
Müvafiq olaraq, PostgreSQL bu siyahıdan olduqca intuitiv olaraq seçildi (yaxşı, həqiqətən seçmək Oracle deyil).
Nə çatışmadı:
- proqram yalnız 2 bölgədə yerləşdirildi və 3-cü planlarda (Asiya) göründü;
- Məlumat bazası Şimali Amerika regionunda (Ayova) yerləşirdi;
- Müştərinin mümkün olması ilə bağlı narahatlıqları var idi giriş gecikmələri Avropa və Asiyadan və fasilələr xidmətnizdə DBMS-nin dayanması zamanı.
Djanqonun özü paralel olaraq bir neçə verilənlər bazası ilə işləyə bilsə və onları oxumağa və yazmağa bölə bilsə də, tətbiqdə o qədər də çox yazı yox idi (90% -dən çoxu oxuyur). Və ümumiyyətlə, və ümumiyyətlə, etmək mümkün olsaydı Avropa və Asiyada əsas bazanın oxunması-replikası, bu kompromis həll olardı. Yaxşı, bu qədər mürəkkəb nə var?
Çətinlik ondan ibarət idi ki, müştəri idarə olunan xidmətlərdən və Cloud SQL-dən imtina etmək istəmirdi. Və Cloud SQL imkanları hazırda məhduddur. Cloud SQL Yüksək əlçatanlığı (HA) və Oxu Replikasını (RR) dəstəkləyir, lakin eyni RR yalnız bir regionda dəstəklənir. Amerika regionunda verilənlər bazası yaratdıqdan sonra siz Cloud SQL-dən istifadə edərək Avropa regionunda oxunmuş replika edə bilməzsiniz, baxmayaraq ki, Postgres özü bunu etməyə mane olmur. Google əməkdaşları ilə yazışmalar heç bir nəticə vermədi və “biz problemi bilirik və bunun üzərində işləyirik, nə vaxtsa məsələ həll olunacaq” üslubunda vədlərlə başa çatdı.
Cloud SQL-in imkanlarını qısaca sadalasaq, o, belə görünəcək:
1. Yüksək əlçatanlıq (HA):
- bir bölgə daxilində;
- diskin təkrarlanması vasitəsilə;
- PostgreSQL mühərrikləri istifadə edilmir;
- avtomatik və əllə idarəetmə mümkündür - əvəzetmə/failback;
- Kommutasiya zamanı DBMS bir neçə dəqiqə ərzində əlçatmaz olur.
2. Replikanı oxuyun (RR):
- bir bölgə daxilində;
- isti gözləmə rejimi;
- PostgreSQL axın replikasiyası.
Bundan əlavə, adət olduğu kimi, texnologiya seçərkən həmişə bəziləri ilə qarşılaşırsınız məhdudiyyətlər:
- müştəri GKE vasitəsilə istisna olmaqla, qurumlar yaratmaq və IaaS-dən istifadə etmək istəməyib;
- müştəri özünə xidmət PostgreSQL/MySQL tətbiq etmək istəmir;
- Ümumiyyətlə, Google Spanner qiyməti olmasaydı, olduqca uyğun olardı, lakin Django ORM onunla işləyə bilməz, amma bu yaxşı bir şeydir.
Vəziyyəti nəzərə alaraq, müştəri növbəti sual aldı: "Oxşar bir şey edə bilərsinizmi ki, o, Google Spanner kimi olsun, həm də Django ORM ilə işləyir?"
Həll variantı № 0
Ağlıma gələn ilk şey:
- CloudSQL daxilində qalmaq;
- hər hansı formada regionlar arasında daxili replikasiya olmayacaq;
- PostgreSQL tərəfindən mövcud Bulud SQL-ə bir replika əlavə etməyə çalışın;
- haradasa və bir şəkildə PostgreSQL nümunəsini işə salın, lakin heç olmasa master-a toxunmayın.
Təəssüf ki, məlum oldu ki, bunu etmək mümkün deyil, çünki hosta giriş yoxdur (bu, tamamilə fərqli bir layihədədir) - pg_hba və s. və super istifadəçinin də girişi yoxdur.
Həll variantı № 1
Daha ətraflı düşünmədən və əvvəlki şərtləri nəzərə alaraq, düşüncə qatarı bir qədər dəyişdi:
- Biz hələ də CloudSQL daxilində qalmağa çalışırıq, lakin MySQL-ə keçirik, çünki MySQL tərəfindən Cloud SQL-in xarici master var, hansı:
— xarici MySQL üçün proxydir;
- MySQL nümunəsinə bənzəyir;
- digər buludlardan və ya yerli yerlərdən məlumatların köçürülməsi üçün icad edilmişdir.
MySQL replikasiyasının qurulması hosta giriş tələb etmədiyi üçün prinsipcə hər şey işləyirdi, lakin çox qeyri-sabit və əlverişsiz idi. Və daha da irəli getdiyimiz zaman tamamilə qorxunc oldu, çünki biz bütün strukturu terraform ilə yerləşdirdik və birdən məlum oldu ki, xarici usta terraform tərəfindən dəstəklənmir. Bəli, Google-da CLI var, amma nədənsə burada hər şey işləyirdi - bəzən yaradılır, bəzən yaradılmır. Ola bilsin ki, CLI replikalar üçün deyil, xarici məlumat miqrasiyası üçün icad edilib.
Əslində, bu nöqtədə aydın oldu ki, Cloud SQL heç də uyğun deyil. Necə deyərlər, əlimizdən gələni etdik.
Həll variantı № 2
Cloud SQL çərçivəsində qalmaq mümkün olmadığından, biz kompromis həll üçün tələbləri formalaşdırmağa çalışdıq. Tələblər aşağıdakılar olduğu ortaya çıxdı:
- Kubernetes-də işləmək, Kubernetes (DCS, ...) və GCP (LB, ...) resurslarından və imkanlarından maksimum istifadə;
- HA proxy kimi buludda bir çox lazımsız şeydən balastın olmaması;
- əsas HA bölgəsində PostgreSQL və ya MySQL-i işə salmaq imkanı; digər bölgələrdə - əsas bölgənin RR-dən HA və onun surəti (etibarlılıq üçün);
- multi master (mən onunla əlaqə saxlamaq istəmədim, amma çox vacib deyildi)
.
Bu tələblərin nəticəsi olaraq, suyğun DBMS və bağlama seçimləri:
- MySQL Galera;
- Haqqımızda Şirkətin Adı: CockroachDB;
- PostgreSQL alətləri
:
- pgpool-II;
- Patroni.
MySQL Galera
MySQL Galera texnologiyası Codership tərəfindən hazırlanmışdır və InnoDB üçün plagindir. Xüsusiyyətlər:
- multi master;
- sinxron replikasiya;
- hər hansı bir qovşaqdan oxumaq;
- hər hansı bir node üçün qeyd;
- daxili HA mexanizmi;
- Bitnami-dən Helm qrafiki var.
Hamamböceği DB
Təsvirə görə, şey tamamilə bombadır və Go-da yazılmış açıq mənbəli bir layihədir. Əsas iştirakçı Cockroach Labs (Google-dan olan insanlar tərəfindən yaradılmışdır). Bu relational DBMS əvvəlcə paylanmaq (qutudan kənarda üfüqi miqyasla) və nasazlığa dözümlü olmaq üçün nəzərdə tutulmuşdur. Onun şirkətdən olan müəllifləri “SQL funksionallığının zənginliyini NoSQL həlləri ilə tanış olan üfüqi əlçatanlıq ilə birləşdirmək” məqsədini qeyd ediblər.
Gözəl bir bonus post-qress əlaqə protokoluna dəstəkdir.
pgpool
Bu, PostgreSQL-ə əlavədir, əslində bütün əlaqələri ələ keçirən və onları emal edən yeni bir qurumdur. BSD lisenziyası ilə lisenziyalaşdırılmış öz yük balanslaşdırıcısı və analizatoru var. Bu, geniş imkanlar təqdim edir, lakin bir qədər qorxulu görünür, çünki yeni bir varlığın olması bəzi əlavə macəraların mənbəyinə çevrilə bilər.
Patroni
Bu, mənim gözlərim düşdüyü son şeydir və göründüyü kimi, boş yerə deyil. Patroni açıq mənbəli yardım proqramıdır və mahiyyətcə Python demonudur və sizə PostgreSQL klasterlərini müxtəlif növ replikasiya və avtomatik rol dəyişdirmə ilə avtomatik saxlamağa imkan verir. İş çox maraqlı oldu, çünki kub ilə yaxşı birləşir və heç bir yeni obyekt təqdim etmir.
Sonda nə seçdiniz?
Seçim asan deyildi:
- Hamamböceği DB - yanğın, lakin qaranlıq;
- MySQL Galera - həm də pis deyil, bir çox yerdə istifadə olunur, lakin MySQL;
- pgpool — çoxlu lazımsız obyektlər, beləliklə bulud və K8-lərlə inteqrasiya;
- Patroni - K8s ilə əla inteqrasiya, lazımsız obyektlər yoxdur, GCP LB ilə yaxşı inteqrasiya olunur.
Beləliklə, seçim Patroninin üzərinə düşdü.
Tapıntılar
Qısaca yekunlaşdırmağın vaxtıdır. Bəli, İT infrastrukturu dünyası əhəmiyyətli dərəcədə dəyişdi və bu, yalnız başlanğıcdır. Əgər əvvəllər buludlar başqa bir infrastruktur növü idisə, indi hər şey fərqlidir. Üstəlik, buludlarda olan yeniliklər daim peyda olur, görünəcək və ola bilsin ki, onlar yalnız buludlarda görünəcək və yalnız bundan sonra startapların səyləri ilə On-premises-ə köçürüləcək.
SQL-ə gəlincə, SQL yaşayacaq. Bu o deməkdir ki, siz PostgreSQL və MySQL-i bilməli və onlarla işləməyi bacarmalısınız, lakin daha da önəmlisi onlardan düzgün istifadə edə bilməkdir.
Mənbə: www.habr.com