Supabase 30. maijā publicēja Multigres v0.1.0 — atvērtā koda rīku, kas Postgres priekšā liek starpniekservera slāni ar savienojumu apkopošanu, automātisku pārslēgšanos avārijas gadījumā un rezerves kopiju pārvaldību. Projektu vada Sugu Sougoumarane, MySQL klasterēšanas sistēmas Vitess līdzautors. GitHub repozitorijā jau savākušās ap 2500 zvaigznes, un kods gandrīz pilnībā rakstīts Go valodā (93,4%) ar Apache 2.0 licenci.
Nosaukums “Vitess for Postgres” nav tirgvedības frāze. Sougoumarane Vitess sākotnēji uzrakstīja YouTube, lai sadalītu MySQL datubāzi pa daudzām mašīnām, kad viens serveris vairs netika galā ar slodzi. Tagad viņš to pašu pieeju pārceļ uz Postgres. Supabase viņu pieņēma darbā tieši šī projekta dēļ, un viņš raksta, ka izvēli noteica uzņēmuma atvērtā koda pieeja un pilnībā attālināta komanda.
Kāpēc Postgres vajag mērogošanu pa horizontāli
Postgres darbojas uz vienas mašīnas. Kad dati un slodze aug, tie agrāk vai vēlāk aizpilda lielāko pieejamo serveri, un tālāk augt vairs nav kur. Sougoumarane to formulē tieši: “Kad šīs datubāzes aug, lietotāji saskaras ar cietu robežu, tiklīdz izsmeļ lielāko pieejamo mašīnu.”
Izeja ir sadalīt datus pa vairākiem serveriem — sharding. To lielās komandas parasti būvē pašas, jo katrs vaicājums jāaizmaršrutē uz pareizo mašīnu un jāsaliek atpakaļ atbilde. Vitess šo darbu paveica MySQL pasaulei; to izmanto Slack, GitHub un citi lieli uzņēmumi. Multigres mērķis ir dot Postgres kopienai to pašu bez patentētiem risinājumiem.
Kas ir Multigres v0.1 iekšpusē
Multigres nav pārrakstīts Postgres. Tas ir slānis, kas sēž datubāzu priekšā un sastāv no diviem galvenajiem servisiem. Multigateway pieņem klientu savienojumus un maršrutē vaicājumus. Multipooler pārvalda savienojumus ar aizmugures Postgres instancēm. Šis divu servisu sadalījums ļauj apkopošanu darīt tuvāk datubāzei, nevis pašā klienta pusē.
Pirmais laidiens jau dod dažas lietas, ko Postgres administratori parasti liek kopā ar atsevišķiem rīkiem:
- savienojumu apkopošana ar atsevišķiem pūliem katram lietotājam un godīgas daļas algoritmu;
- sagatavoto vaicājumu deduplikācija starp vārtejām, lai tos nedublētu katrs savienojums;
- automātiska pārslēgšanās uz rezerves mezglu, ko koordinē konsensa protokols;
- rezerves kopiju pārvaldība caur pgBackRest — pilnas, inkrementālas un diferenciālas kopijas pēc pieprasījuma vai pēc grafika;
- Kubernetes operators izvēršanai klasterī.
Alfa versijas apraksts Multigres sauc par “mērogojamu operētājsistēmu Postgres vajadzībām” — proti, vienu rīku visai infrastruktūrai ap datubāzi, nevis atsevišķi PgBouncer, atsevišķi Patroni un atsevišķi rezerves kopiju skriptu.
“Multigres holistiski pārvalda tavas Postgres instances un dod tev sharding, savienojumu apkopošanu, automātisku pārslēgšanos un rezerves kopiju orķestrēšanu,” teikts v0.1 alfa paziņojumā.
Sharding pirmajā laidienā vēl nav
Sharding — datu sadalīšana pa mašīnām — v0.1 vēl nav. Supabase to sauc par “gaidāmo flagmaņa funkciju”, un pirmais laidiens strādā tikai kā viena šarda klasteris. Tas nozīmē, ka šodien Multigres dod augstu pieejamību un apkopošanu, bet ne pašu horizontālo mērogošanu, kuras dēļ projektu sāka.
Komanda arī brīdina, ka tā ir alfa. Veiktspējas mērījumi vēl nav publicēti. Atpakaļsavietojamību starp versijām negarantē, un pielāgotā resursa (CR) API paliks nestabils līdz v1.0. Kas paļaujas uz Multigres ražošanā šodien, dara to uz savu risku.
Sougoumarane Carnegie Mellon datubāzu grupas priekšlasījumā uzsvēra saderību ar Postgres. Vitess laikā daudzas MySQL funkcijas nācās pielāgot; ar Postgres komanda cenšas neuzspiest lietotājiem izmaiņas savā kodā, jo saderība ir viena no Postgres kopienas pamatvērtībām.
Ar ko tas atšķiras no Citus un PgBouncer
Postgres sharding jau kādu laiku eksistē. Citus, ko pārvalda Microsoft, ir Postgres paplašinājums, kas sadala tabulas pa mezgliem un darbojas datubāzes iekšienē. Multigres iet citu ceļu — tas sēž datubāzes priekšā kā starpnieks un nemaina pašu Postgres. Vitess pieredze rāda, ka šī atdalīšana ļauj maršrutēšanu, apkopošanu un pārslēgšanos pārvaldīt neatkarīgi no datubāzes versijas, un tieši to Sougoumarane grib atkārtot.
Savienojumu apkopošanā līdz šim standarts bija PgBouncer — mazs, atsevišķs process, kas tur pūlu ar savienojumiem. Multigres apkopošanu iebūvē pašā slānī un pievieno lietas, ko PgBouncer viens neatrisina: pūlus katram lietotājam ar godīgas daļas algoritmu, lai viens klients neizsmeltu visus savienojumus, un sagatavoto vaicājumu deduplikāciju. Administratoram tas nozīmē mazāk atsevišķu rīku, kas jāsaliek kopā un jāuztur.
Augstajai pieejamībai daudzi lieto Patroni ar etcd konsensa glabātuvi. Multigres pārslēgšanos veido iekšēji ar savu konsensa protokolu un Kubernetes operatoru, tā ka viss klasteris — vārtejas, pūli un rezerves kopijas — nāk no vienas sistēmas. Cik labi tas strādā salīdzinājumā ar nobriedušajiem risinājumiem, rādīs veiktspējas mērījumi, kurus komanda vēl nav laidusi klajā.
Ko atnesa jūlijs
Supabase jūlija izstrādātāju atjauninājumā paziņoja par vienu konkrētu Multigres uzlabojumu: LISTEN/NOTIFY tagad strādā arī tad, kad savienojumi tiek apkopoti prom no klienta. Tas ir Postgres mehānisms, ar ko procesi cits citam sūta ziņas pa kanālu, un tradicionālā savienojumu apkopošana to salauž, jo klients vairs neturas pie tā paša savienojuma. Multigres to notur dzīvu cauri pūlim. Aplikācijām, kas paļaujas uz LISTEN/NOTIFY reāllaika paziņojumiem, tas nozīmē, ka apkopošanu var ieslēgt bez šī mehānisma zaudēšanas.
Supabase paralēli būvē komerciālu Multigres versiju, kas nāks vēlāk; atvērtā koda kods paliks Apache 2.0. Komanda pagaidām pieņem tikai nelielus kļūdu labojumus un ziņojumus, bet lielākas iemaksas atliek uz vēlāku laiku, kamēr projekts stabilizējas. Nākamais solis, ko visi gaida, ir pirmais laidiens ar reālu sharding.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.