Kas yra Yugabyte ir kodėl tai svarbu
Kai pradedi kurti programą, kuri turi augti globaliai, greitai susiduri su klasikine duomenų bazių dilema: pasirinkti tradicinę reliacinę duomenų bazę su ACID garantijomis ar eiti į NoSQL pasaulį su geresniu horizontaliu masteliškumu, bet prarandant įprastą SQL funkcionalumą? Yugabyte atsirado kaip atsakas į šį amžiną klausimą, bandydamas sujungti abu pasaulius.
Yugabyte DB – tai atviro kodo paskirstyta SQL duomenų bazė, kuri žada PostgreSQL suderinamumą su horizontaliu masteliškumu ir aukštu prieinamumu. Skamba kaip marketingo šūkis, bet techniškai tai tikrai įdomus sprendimas. Jie iš esmės paėmė PostgreSQL kaip užklausų sluoksnį ir sukūrė visiškai naują paskirstytą saugojimo variklį po juo.
Kodėl tai svarbu? Nes daugelis įmonių vis dar nori naudoti SQL – tai žinoma kalba, yra tonos įrankių, bibliotekų ir žmonių, kurie ją moka. Bet kai tavo aplikacija auga ir vienas serveris nebepakanka, tradicinės duomenų bazės pradeda kankinti. Reikia sharding’o, replikacijos, sudėtingos infrastruktūros. Yugabyte sako: „Mes tai padarysime už jus automatiškai.”
Architektūra: kaip tai veikia po gaubtu
Yugabyte architektūra yra dviejų lygių. Viršuje yra YSQL – tai PostgreSQL fork’as, kuris priima tavo SQL užklausas. Apačioje yra DocDB – paskirstytas dokumentų saugojimo variklis, pastatytas ant RocksDB ir naudojantis Raft konsensuso algoritmą replikacijai.
Kai siunti užklausą į Yugabyte, YSQL sluoksnis ją apdoroja kaip PostgreSQL. Bet kai reikia skaityti ar rašyti duomenis, jis bendrauja su DocDB, kuris automatiškai paskirsto duomenis per kelis mazgus (nodes). Kiekvienas duomenų fragmentas (tablet) yra replikuojamas į kelis serverius, paprastai tris, naudojant Raft protokolą.
Štai kur įdomu: Yugabyte naudoja hybrid logical clocks (HLC) laiko žymėms. Tai leidžia jiems palaikyti snapshot isolation ir serializable isolation lygius paskirstytoje sistemoje be centralizuoto koordinatoriaus. Tai ne trivialus techninis pasiekimas – daugelis paskirstytų duomenų bazių čia susiduria su problemomis.
Duomenų paskirstymas vyksta automatiškai. Kai pridedi naują mazgą į klasterį, Yugabyte automatiškai perskirstys duomenis. Kai mazgas nukrista, sistema automatiškai persikonfiguruoja ir išrenka naują lyderį atitinkamiems tablet’ams. Teoriškai tu neturi rūpintis šiais dalykais – sistema save gydo.
PostgreSQL suderinamumas: kiek iš tikrųjų?
Čia reikia būti sąžiningiems. Yugabyte teigia esanti PostgreSQL suderinama, bet tai nėra 100% tiesa. Jie naudoja PostgreSQL 11.2 kodą kaip pagrindą savo YSQL sluoksniui, bet ne viskas veikia taip pat.
Dauguma standartinių SQL funkcijų veikia puikiai: JOIN’ai, subqueries, window functions, CTE, triggers, stored procedures. Jei naudoji paprastas PostgreSQL funkcijas, greičiausiai viskas veiks be problemų. Bet yra niuansų.
Kai kurios PostgreSQL plėtiniai neveikia arba veikia ribotai. Pavyzdžiui, PostGIS palaikymas yra eksperimentinis. Kai kurie specifiniai indeksų tipai gali neveikti arba veikti kitaip. Foreign data wrappers – irgi ne viskas palaiko.
Taip pat yra skirtumų, kaip kai kurie dalykai veikia paskirstytoje aplinkoje. Pavyzdžiui, SERIAL tipas Yugabyte generuoja unikalius ID visame klasteryje, o ne vienam serveryje. Tai gerai, bet gali būti netikėta, jei migravai iš vieno PostgreSQL serverio.
Praktiškai, jei tavo aplikacija naudoja gana standartinį SQL ir nepriklausai nuo egzotiškų PostgreSQL funkcijų, migracija turėtų būti sklandžia. Bet būtinai testuok prieš perkeliant produkciją.
Našumas ir masteliškumas realiame pasaulyje
Teorija yra graži, bet kaip Yugabyte veikia praktikoje? Čia reikalai tampa įdomesni ir sudėtingesni.
Vieno mazgo Yugabyte bus lėtesnis už vieną PostgreSQL serverį. Tai logika – yra papildomas paskirstymo sluoksnis, replikacija, koordinacija. Jei tavo duomenų bazė telpa į vieną serverį ir tau nereikia geografinio paskirstymo, Yugabyte tikriausiai nėra tau.
Bet kai pradedi horizontaliai masteliuoti, Yugabyte pradeda švytėti. Skaitymo operacijos gali būti paskirstytos per kelis mazgus. Jei tavo workload yra daugiausia skaitymas, pridėdamas daugiau mazgų tikrai gausi geresnį našumą.
Rašymo operacijos yra sudėtingesnės. Kadangi kiekvienas rašymas turi būti replikuotas į kelis mazgus naudojant Raft, yra tam tikras overhead. Bet jei tavo duomenys yra gerai paskirstyti (geras partition key), rašymai į skirtingus tablet’us gali vykti lygiagrečiai skirtinguose mazguose.
Vienas didelis privalumas yra geografinis paskirstymas. Gali turėti mazgus skirtinguose duomenų centruose ar net žemynuose. Yugabyte palaiko tablespace konceptą, kur gali nurodyti, kuriuose regionuose saugoti tam tikrus duomenis. Tai leidžia laikti duomenis arčiau vartotojų ir atitikti GDPR ar kitus duomenų lokalizacijos reikalavimus.
Diegimas ir operacinis valdymas
Yugabyte diegti nėra trivialus dalykas, bet jie stengiasi tai palengvinti. Yra keletas būdų kaip pradėti.
Lengviausias būdas eksperimentuoti – Docker konteineriai. Gali paleisti lokalų klasterį su trimis mazgais savo laptope per kelias minutes. Tai puiku mokymui ir testavimui.
Produkcijai Yugabyte siūlo Yugabyte Platform (anksčiau Yugabyte Anywhere) – tai valdymo konsolė, kuri leidžia diegti ir valdyti klasterius įvairiose aplinkose: on-premise, AWS, GCP, Azure, Kubernetes. Tai gana galinga, bet ir sudėtinga sistema. Reikia laiko ją išmokti.
Alternatyviai, yra Yugabyte Cloud – jų managed service. Jei nenori rūpintis infrastruktūra, tai geras pasirinkimas. Jie rūpinasi atnaujinimais, backup’ais, monitoring’u. Bet, žinoma, tai kainuoja.
Kubernetes deployment’as yra populiarus pasirinkimas. Yugabyte pateikia Helm charts ir operatorių. Jei jau naudoji Kubernetes, tai natūralus kelias. Bet Kubernetes prideda savo sudėtingumo sluoksnį – reikia suprasti ir Yugabyte, ir Kubernetes.
Monitoringui Yugabyte eksportuoja Prometheus metricas ir turi savo web UI su įvairiais dashboard’ais. Gali matyti klasterio sveikatą, našumą, tablet’ų paskirstymą. Tai naudinga, bet reikia išmokti, į ką žiūrėti ir kaip interpretuoti.
Backup’ai ir restore yra kritiniai. Yugabyte palaiko snapshot backup’us, kurie gali būti saugomi S3 ar kitose objektų saugyklose. Yra point-in-time recovery funkcionalumas. Bet, kaip ir su bet kuria duomenų baze, būtinai testuok savo backup ir restore procedūras prieš tau jų prireikiant.
Kaina: ne tik pinigai, bet ir sudėtingumas
Kalbant apie kainą, reikia žiūrėti plačiau nei tik serverių sąskaitas.
Jei naudoji Yugabyte Cloud, kainodara yra gana paprasta – moki už vCPU, saugyklą ir tinklo srautą. Tai gali būti brangiau nei managed PostgreSQL (RDS, Cloud SQL), bet gauni paskirstymą ir masteliškumą. Reikia skaičiuoti, ar tai verta tavo use case’ui.
Self-hosted Yugabyte yra nemokamas (open source), bet yra „paslėptų” kainų. Reikia serverių, tinklo, saugyklos. Reikia žmonių, kurie mokėtų tai valdyti. Reikia laiko mokytis ir debuginti problemas.
Sudėtingumas yra reali kaina. Paskirstyta sistema yra sudėtingesnė už vieną serverį. Bus situacijų, kai kas nors neveiks ir reikės suprasti, kas vyksta. Ar tavo komanda turi žinių ir laiko tam? Ar verta investuoti į mokymąsi?
Taip pat reikia pagalvoti apie vendor lock-in. Nors Yugabyte yra open source, jei naudoji jų specifines funkcijas (pvz., tablespace’us geografiniam paskirstymui), migracija atgal į paprastą PostgreSQL gali būti sudėtinga.
Kada Yugabyte yra geras pasirinkimas
Ne kiekvienam projektui reikia paskirstytos duomenų bazės. Štai scenarijai, kur Yugabyte tikrai turi prasmę:
**Globalios aplikacijos su vartotojais įvairiuose regionuose.** Jei tavo vartotojai yra Europoje, Azijoje ir Amerikoje, ir nori, kad duomenys būtų arti jų, Yugabyte leidžia tai padaryti išlaikant vieną loginę duomenų bazę.
**Multi-tenant SaaS aplikacijos, kurios auga.** Jei kiekvienas klientas turi savo duomenis ir tau reikia masteliškumo, Yugabyte gali automatiškai paskirstyti tenant’us per mazgus.
**High availability yra kritinis.** Jei negali sau leisti downtime ir reikia automatinio failover be duomenų praradimo, Yugabyte su trimis ar daugiau replikų tai pateikia.
**Duomenų lokalizacija ir compliance.** Jei turi laikytis GDPR ar kitų reguliacijų, kurios reikalauja, kad tam tikri duomenys būtų saugomi tam tikruose regionuose, Yugabyte tablespace funkcionalumas tai palengvina.
Bet yra ir scenarijai, kur Yugabyte greičiausiai nėra geriausias pasirinkimas:
Jei tavo duomenų bazė yra maža ir telpa į vieną galingą serverį, paprastas PostgreSQL bus paprastesnis ir greičiausiai greitesnis. Jei tavo aplikacija yra regioninė ir visi vartotojai vienoje geografinėje vietoje, paskirstymas neduos daug naudos. Jei tavo komanda maža ir neturi laiko mokytis naujų technologijų, sudėtingumas gali būti problema.
Alternatyvos ir kaip Yugabyte išsiskiria
Yugabyte nėra vienintelis žaidėjas distributed SQL erdvėje. Verta pažiūrėti į alternatyvas.
**CockroachDB** yra tikriausiai artimiausias konkurentas. Jie taip pat siūlo distributed SQL su PostgreSQL wire protocol suderinamumu. CockroachDB yra labiau orientuotas į OLTP workloads ir turi šiek tiek kitokią architektūrą. Kai kurie sako, kad CockroachDB turi geresnį automatinį rebalancing’ą, bet Yugabyte turi geresnį PostgreSQL suderinamumą.
**Google Spanner** yra proprietary sprendimas, kuris įkvėpė daugelį distributed SQL duomenų bazių. Jei esi Google Cloud, Spanner yra galingas pasirinkimas, bet brangesnis ir turi savo SQL dialektą.
**TiDB** yra kitas open source distributed SQL sprendimas, bet labiau MySQL suderinamas nei PostgreSQL. Jei tavo ekosistema yra MySQL, TiDB gali būti geresnis pasirinkimas.
**Amazon Aurora** su PostgreSQL yra managed sprendimas AWS, kuris siūlo gerą našumą ir prieinamumą, bet ne tikrą horizontalų masteliškumą ar multi-region active-active setup’ą kaip Yugabyte.
Yugabyte išsiskiria savo PostgreSQL suderinamumu ir lankstumu – gali jį naudoti bet kurioje aplinkoje, ne tik viename cloud provider’yje. Tai open source su aktyvia bendruomene. Ir jie turi tiek YSQL (PostgreSQL compatible), tiek YCQL (Cassandra compatible) API, nors dauguma naudoja YSQL.
Ką reikia žinoti prieš šokant į vandenį
Jei svarstai Yugabyte savo projektui, štai keletas praktinių patarimų iš траншėjų:
**Pradėk mažai ir testuok daug.** Neperkelsk visos savo produkcinės duomenų bazės iš karto. Pradėk nuo ne kritinio komponento ar naujo projekto. Testuok savo workloads, matuok našumą, mokykis kaip sistema veikia.
**Investuok į mokymąsi.** Paskirstytos sistemos yra sudėtingos. Skaityk dokumentaciją, žiūrėk jų webinarus, eksperimentuok. Supratimas, kaip Yugabyte veikia po gaubtu, padės, kai susidursi su problemomis.
**Gerai pagalvok apie partition key.** Kaip paskirstai duomenis yra kritinis našumui. Blogas partition key gali reikšti, kad visi duomenys atsidurs viename tablet’e ir nepasinaudosi paskirstymu. Yugabyte automatiškai hash’uoja primary key, bet kartais reikia composite key ar kitokios strategijos.
**Monitorink ir optimizuok.** Naudok Yugabyte metrikas, žiūrėk į slow queries, analizuok query plans. Distributed SQL query optimization gali skirtis nuo tradicinio PostgreSQL.
**Planuok capacity.** Yugabyte reikia daugiau resursų nei vienas PostgreSQL serveris. Skaičiuok ne tik duomenų dydį, bet ir replikacijos overhead’ą, tinklo srautą, CPU našumą.
**Turėk backup planą.** Ne tik duomenų backup’ą, bet ir planą, ką daryti, jei Yugabyte nepasiteisins. Ar gali grįžti į PostgreSQL? Ar turi alternatyvą?
Paskirstytos duomenų bazės nėra sidabrinė kulka. Jos sprendžia tam tikras problemas, bet sukuria naujas. Yugabyte yra įdomus technologinis sprendimas, kuris tikrai turi savo vietą modernių aplikacijų architektūroje. Bet kaip ir su bet kuria technologija, svarbu suprasti, ar ji sprendžia tavo konkrečias problemas ir ar esi pasirengęs susidoroti su jos sudėtingumu.
Distributed SQL ateitis atrodo šviesi, ir Yugabyte yra vienas iš stiprių žaidėjų šioje erdvėje. Jei tau reikia globalaus masteliškumo su SQL patogumu, verta bent išbandyti. Tik nepamiršk, kad su didele galia ateina ir didelė atsakomybė – ir sudėtingumas.
