Saluton, Ĥabrovskaj loĝantoj. La klasoj en la unua grupo de la kurso komenciĝas hodiaŭ . Ĉi-rilate, ni ŝatus rakonti al vi pri kiel okazis la malferma retseminario pri ĉi tiu kurso.
В ni parolis pri la defioj SQL-datumbazoj alfrontas en la epoko de nuboj kaj Kubernetes. Samtempe, ni rigardis kiel SQL-datumbazoj adaptiĝas kaj mutacias sub la influo de ĉi tiuj defioj.
La retseminario okazis , Google Cloud Practice Delivery Manager ĉe EPAM Systems.
Kiam la arboj estis malgrandaj...
Unue, ni memoru kiel la elekto de DBMS komenciĝis fine de la lasta jarcento. Tamen, ĉi tio ne estos malfacila, ĉar la elekto de DBMS en tiuj tagoj komenciĝis kaj finiĝis plejsanktejo.
В конце 90-х — начале нулевых, особого выбора, по сути, не было, если говорить про промышленные масштабируемые БД. Да, существовали IBM DB2, Sybase и ещё какие-то базы данных, которые появлялись и исчезали, но в общем и целом они были не так заметны на фоне Oracle. Соответственно, навыки инженеров тех времён были так или иначе завязаны на то единственный выбор, который существовал.
Oracle DBA devis povi:
- устанавливать Oracle Server из дистрибутива;
- agordi Oracle Server:
- init.ora;
- aŭskultanto.ora;
- krei:
- tabelspacoj;
- skemoj;
- пользователей;
- fari sekurkopion kaj restarigi;
— efektivigi monitoradon;
— trakti suboptimumajn petojn.
En la sama tempo, ekzistis neniu speciala postulo de Oracle DBA:
- povi elekti la optimuman DBMS aŭ alian teknologion por stoki kaj prilabori datumojn;
- provizi altan haveblecon kaj horizontalan skaleblon (ĉi tio ne ĉiam estis DBA-afero);
- хорошо знать предметную область, инфраструктуру, прикладную архитектуру, ОС;
- выполнять загрузку и выгрузку данных, миграцию данных между разными СУБД.
Ĝenerale, se ni parolas pri la elekto en tiuj tagoj, ĝi similas la elekton en sovetia vendejo fine de la 80-aj jaroj:
Nia tempo
Ekde tiam, kompreneble, la arboj kreskis, la mondo ŝanĝiĝis, kaj ĝi fariĝis io tia:
Изменился и рынок СУБД, что хорошо видно по свежему докладу компании Gartner:
Kaj ĉi tie oni devas rimarki, ke nuboj, kies populareco kreskas, okupis sian niĉon. Se ni legos la saman raporton de Gartner, ni vidos la sekvajn konkludojn:
- Многие заказчики находятся на пути перевода приложений в облако.
- Novaj teknologioj unue aperas en la nubo kaj ne estas fakto, ke ili iam moviĝos al nenuba infrastrukturo.
- La prezo-modelo laŭ-pago fariĝis ordinara. Ĉiuj volas pagi nur por tio, kion ili uzas, kaj ĉi tio eĉ ne estas tendenco, sed simple deklaro de fakto.
Kio nun?
Hodiaŭ ni ĉiuj estas en la nubo. Kaj la demandoj kiuj ŝprucas por ni estas demandoj de elekto. Kaj ĝi estas grandega, eĉ se ni parolas nur pri la elekto de DBMS-teknologioj en la Surloka formato. Ni ankaŭ havas administritajn servojn kaj SaaS. Tiel, la elekto nur fariĝas pli malfacila ĉiujare.
Kune kun demandoj de elekto, ekzistas ankaŭ limigaj faktoroj:
- la prezo. Multaj teknologioj ankoraŭ kostas monon;
- kapabloj. Se ni parolas pri libera programaro, tiam ŝprucas la demando pri kapabloj, ĉar libera programaro postulas sufiĉan kompetentecon de la homoj, kiuj ĝin disfaldas kaj funkciigas;
- funkcia. Ne ĉiuj servoj disponeblaj en la nubo kaj konstruitaj, ekzemple, eĉ sur la sama Postgres, havas la samajn funkciojn kiel Postgres On-premises. Ĉi tio estas esenca faktoro, kiu devas esti konata kaj komprenita. Krome, ĉi tiu faktoro fariĝas pli grava ol scio pri iuj kaŝitaj kapabloj de ununura DBMS.
Kio estas atendata de DA/DE nun:
- bona kompreno de la temo kaj aplika arkitekturo;
- la kapablo ĝuste elekti la taŭgan DBMS-teknologion, konsiderante la taskon;
- la kapablo elekti la optimuman metodon por efektivigi la elektitan teknologion en la kunteksto de ekzistantaj limigoj;
- kapablo fari datumajn translokigon kaj migradon;
- kapablo efektivigi kaj funkciigi elektitajn solvojn.
Sube ekzemplo на базе GCP montras kiel la elekto de unu aŭ alia teknologio por labori kun datumoj funkcias depende de ĝia strukturo:
Bonvolu noti, ke PostgreSQL ne estas inkluzivita en la skemo, kaj tio estas ĉar ĝi estas kaŝita sub la terminologio Nubo SQL. И когда мы попадаем в Cloud SQL, нам нужно опять сделать выбор:
Oni devas rimarki, ke ĉi tiu elekto ne ĉiam estas klara, do programistoj de aplikaĵoj ofte estas gviditaj de intuicio.
Sumo:
- Ju pli vi iras, des pli prema fariĝas la demando pri elekto. Kaj eĉ se vi rigardas nur GCP, administritajn servojn kaj SaaS, tiam iu mencio pri RDBMS aperas nur ĉe la 4-a paŝo (kaj tie Spanner estas proksime). Krome, la elekto de PostgreSQL aperas en la 5-a paŝo, kaj apud ĝi estas ankaŭ MySQL kaj SQL Server, tio estas всего много, а выбирать надо.
- Ni ne devas forgesi pri limigoj sur la fono de tentoj. Esence ĉiuj volas Spanner, sed ĝi estas multekosta. Kiel rezulto, tipa peto aspektas kiel ĉi tio: «Сделайте нам, пожалуйста, Spanner но за цену Cloud SQL, ну вы же профессионалы!»
Kion ni devus fari?
Sen pretendi esti la finfina vero, ni diru la jenon:
Нужно менять подход к обучению:
- ne havas signifon instrui kiel DBA-oj estis instruitaj antaŭe;
- знания одного продукта сейчас уже недостаточно;
- sed koni dekojn je la nivelo de unu estas neeble.
Нужно знать не только и не сколько продукт, а:
- uzokazo de ĝia apliko;
- malsamaj deplojmetodoj;
- avantaĝoj kaj malavantaĝoj de ĉiu metodo;
- similaj kaj alternativaj produktoj por fari informitan kaj optimuman elekton kaj ne ĉiam favore al konata produkto.
Vi ankaŭ devas povi migri datumojn kaj kompreni la bazajn principojn de integriĝo kun ETL.
Vera kazo
En la lastatempa pasinteco, estis necese krei backend por poŝtelefona aplikaĵo. Kiam la laboro komenciĝis pri ĝi, la backend jam estis evoluigita kaj estis preta por efektivigo, kaj la disvolva teamo pasigis ĉirkaŭ du jarojn en ĉi tiu projekto. La sekvaj taskoj estis fiksitaj:
- konstrui CI/KD;
- revizii la arkitekturon;
- meti ĉion en funkciadon.
La aplikaĵo mem estis mikroservoj, kaj la kodo Python/Django estis disvolvita de nulo kaj rekte en GCP. Koncerne la celgrupon, oni supozis, ke estos du regionoj - Usono kaj EU, kaj trafiko estis distribuita per la Global Load-balancilo. Ĉiuj Laborŝarĝoj kaj komputika laborkvanto funkciis per Google Kubernetes Engine.
Koncerne la datumojn, estis 3 strukturoj:
- Nuba Stokado;
- Datastore;
- Cloud SQL (PostgreSQL).
Oni povus scivoli kial Cloud SQL estis elektita? Verdire, tia demando kaŭzis ian mallertan paŭzon en la lastaj jaroj - oni sentas, ke homoj ektimis pri interrilataj datumbazoj, sed tamen ili daŭre aktive uzas ilin ;-).
Koncerne al nia kazo, Cloud SQL estis elektita pro la sekvaj kialoj:
- Kiel menciite, la aplikaĵo estis evoluigita uzante Django, kaj ĝi havas modelon por mapado de konstantaj datumoj de SQL-datumbazo al Python-objektoj (Django ORM).
- La kadro mem apogis sufiĉe finhavan liston de DBMSoj:
- PostgreSQL;
- MariaDB;
- MySQL;
- Orakolo;
- SQLite.
Sekve, PostgreSQL estis elektita el ĉi tiu listo sufiĉe intuicie (nu, ne estas Oracle elekti, vere).
Чего не хватало:
- приложение было развернуто только в 2-х регионах, а в планах появился 3-й (Азия);
- БД находилась в североамериканском регионе (Iowa);
- flanke de la kliento estis zorgoj pri ebla alirmalfruoj el Eŭropo kaj Azio kaj interrompoj en servo en kazo de malfunkcio de DBMS.
Malgraŭ tio, ke Django mem povas labori kun pluraj datumbazoj paralele kaj dividi ilin en legadon kaj skribadon, ne estis tiom da skribado en la aplikaĵo (pli ol 90% legas). Kaj ĝenerale, kaj ĝenerale, se eblis fari leg-repliko de la ĉefa bazo en Eŭropo kaj Azio, ĉi tio estus kompromisa solvo. Nu, kio estas tiel komplika pri tio?
La malfacilaĵo estis, ke la kliento ne volis rezigni uzi administritajn servojn kaj Cloud SQL. Kaj la kapabloj de Cloud SQL estas nuntempe limigitaj. Cloud SQL subtenas Alta havebleco (HA) kaj Read Replica (RR), sed la sama RR estas nur subtenata en unu regiono. Kreinte datumbazon en la usona regiono, vi ne povas fari legitan kopion en la eŭropa regiono uzante Cloud SQL, kvankam Postgres mem ne malhelpas vin fari tion. Korespondado kun Google-dungitoj kondukis nenien kaj finiĝis per promesoj en la stilo de "ni konas la problemon kaj laboras pri ĝi, iam la problemo estos solvita."
Если перечислить возможности Cloud SQL тезисно, то это будет выглядеть приблизительно так:
1. High availability (HA):
- в рамках одного региона;
- per disko-reproduktado;
- PostgreSQL-motoroj ne estas uzataj;
- ebla aŭtomata kaj mana kontrolo - malfunkciigo/malfunkciigo;
- при переключении СУБД недоступна в течение нескольких минут.
2. Read Replica (RR):
- в рамках одного региона;
- hot standby;
- PostgreSQL fluanta reproduktado.
Krome, kiel kutimas, elektante teknologion oni ĉiam alfrontas iujn restriktoj:
- la kliento ne volis krei entojn kaj uzi IaaS, krom per GKE;
- la kliento ne ŝatus disfaldi memservon PostgreSQL/MySQL;
- Nu, ĝenerale, Google Spanner estus sufiĉe taŭga se ĝi ne estus por ĝia prezo, tamen, Django ORM ne povas funkcii kun ĝi, sed ĝi estas bona afero.
Konsiderante la situacion, la kliento ricevis sekvan demandon: "Ĉu vi povas fari ion similan por ke ĝi estu kiel Google Spanner, sed ankaŭ funkcias kun Django ORM?"
Solvo-opcio n-ro 0
La unua afero, kiu venis al la menso:
- resti ene de CloudSQL;
- ne estos enkonstruita reproduktado inter regionoj en ajna formo;
- provu ligi kopion al ekzistanta Cloud SQL de PostgreSQL;
- где-то и как-то запустить инстанс PostgreSQL, но хотя бы master не трогать.
Ve, montriĝis, ke tio ne povas esti farita, ĉar ne estas aliro al la gastiganto (ĝi estas en tute malsama projekto) - pg_hba kaj tiel plu, kaj ankaŭ ne estas aliro sub superuzanto.
Solvo-opcio n-ro 1
Post plia pripensado kaj konsiderante antaŭajn cirkonstancojn, la pensmaniero iom ŝanĝiĝis:
- всё также пытаемся остаться в рамках CloudSQL, но переходим на MySQL, т. к. у Cloud SQL by MySQL есть external master, который:
— estas prokurilo por ekstera MySQL;
- aspektas kiel MySQL-instanco;
- inventita por migri datumojn de aliaj nuboj aŭ Surloke.
Ĉar agordo de MySQL-reproduktado ne postulas aliron al la gastiganto, principe ĉio funkciis, sed ĝi estis tre malstabila kaj maloportuna. Kaj kiam ni iris pluen, ĝi fariĝis tute timiga, ĉar ni disfaldis la tutan strukturon per teraformo, kaj subite montriĝis, ke la ekstera majstro ne estis subtenata de teraformo. Jes, Guglo havas CLI, sed ial ĉio funkciis ĉi tie de tempo al tempo - foje ĝi estas kreita, foje ĝi ne estas kreita. Eble ĉar la CLI estis inventita por ekstera datuma migrado, kaj ne por kopioj.
Efektive, ĉe ĉi tiu punkto evidentiĝis, ke Cloud SQL tute ne taŭgas. Kiel oni diras, ni faris ĉion, kion ni povis.
Solvo-opcio n-ro 2
Ĉar ne eblis resti en la kadro Cloud SQL, ni provis formuli postulojn por kompromisa solvo. La postuloj montriĝis jenaj:
- laboro en Kubernetes, maksimuma uzo de rimedoj kaj kapabloj de Kubernetes (DCS, ...) kaj GCP (LB, ...);
- отсутствие балласта из кучи ненужных в облаке вещей типа HA proxy;
- la kapablo ruli PostgreSQL aŭ MySQL en la ĉefa regiono HA; en aliaj regionoj - HA el la RR de la ĉefa regiono plus ĝia kopio (por fidindeco);
- multimastro (mi ne volis kontakti lin, sed ĝi ne estis tre grava)
.
Sekve de tiuj postuloj, ptaŭgaj DBMS kaj devigaj opcioj:
- MySQL Galera;
- CockroachDB;
- PostgreSQL-iloj
:
- pgpool-II;
— Patroni.
MySQL Galera
MySQL Galera teknologio estis evoluigita fare de Codership kaj estas kromaĵo por InnoDB. Apartaĵoj:
- multi majstro;
- sinkrona reproduktado;
- чтение с любого узла;
- registrado al iu ajn nodo;
- enkonstruita HA-mekanismo;
- Estas Helm-diagramo de Bitnami.
BlatoDB
Laŭ la priskribo, la afero estas absolute bombo kaj estas malfermkoda projekto skribita en Go. La ĉefa partoprenanto estas Cockroach Labs (fondita de homoj de Guglo). Ĉi tiu interrilata DBMS estis origine dizajnita por esti distribuita (kun horizontala skalo el la skatolo) kaj mistolerema. Ĝiaj aŭtoroj de la kompanio skizis la celon "kombini la riĉecon de SQL-funkcio kun la horizontala alirebleco konata al NoSQL-solvoj."
Из приятного бонуса — поддержка постгресного протокола подключения.
Pgpool
Ĉi tio estas aldonaĵo al PostgreSQL, fakte, nova ento, kiu transprenas ĉiujn ligojn kaj prilaboras ilin. Ĝi havas sian propran ŝarĝbalancilon kaj analizilon, licencitajn laŭ la permesilo BSD. Ĝi provizas ampleksajn ŝancojn, sed aspektas iom timiga, ĉar la ĉeesto de nova ento povus fariĝi la fonto de iuj pliaj aventuroj.
Patroni
Ĉi tio estas la lasta afero, kiun miaj okuloj falis, kaj, kiel evidentiĝis, ne vane. Patroni estas malfermfonta ilo, kiu estas esence Python-demono, kiu permesas vin aŭtomate konservi PostgreSQL-grupojn kun diversaj specoj de reproduktado kaj aŭtomata rolŝanĝo. La afero montriĝis tre interesa, ĉar ĝi bone integriĝas kun la kubero kaj ne enkondukas novajn entojn.
Что в итоге выбрали
La elekto ne estis facila:
- BlatoDB - fajro, sed malhela;
- MySQL Galera - ankaŭ ne malbone, ĝi estas uzata multloke, sed MySQL;
- Pgpool — multaj nenecesaj estaĵoj, tiel tiel integriĝo kun la nubo kaj K8s;
- Patroni — прекрасная интеграция с K8s, нет лишних сущностей, хорошо интегрируется с GCP LB.
Tiel, la elekto falis sur Patroni.
trovoj
Estas tempo resumi mallonge. Jes, la mondo de IT-infrastrukturo signife ŝanĝiĝis, kaj ĉi tio estas nur la komenco. Kaj se antaŭe la nuboj estis nur alia speco de infrastrukturo, nun ĉio estas malsama. Plie, novigoj en la nuboj konstante aperas, ili aperos kaj, eble, ili aperos nur en la nuboj kaj nur tiam, per la klopodoj de noventreprenoj, ili estos translokigitaj al Surlokoj.
Koncerne SQL, SQL vivos. Ĉi tio signifas, ke vi bezonas koni PostgreSQL kaj MySQL kaj povi labori kun ili, sed eĉ pli grava estas povi ĝuste uzi ilin.
fonto: www.habr.com