Minulý týden na CHAR(10) konference jsme měli workshop na téma „Cloud Databases“. Zjednodušeně řečeno:co dělat, když požadavky na případ použití překročí zdroje dostupné na databázovém serveru.
To bylo hlavní téma celé konference a během dne bylo ukázáno několik řešení. Společným tématem bylo, že žádné řešení nevyhovuje všem případům použití a že každé řešení má své náklady; proto si musíte vybrat řešení, které si váš případ použití může dovolit.
Dalším společným (i když implicitním) bodem bylo zaměření na „vysoká“ řešení, to znamená:připojení několika databázových serverů na vyšší úrovni pro emulaci jednoho serveru s většími zdroji.
Zjevná výhoda spočívá v tom, že nepotřebujete měnit dobře zkontrolovaný kód PostgreSQL; nevýhodou je, že při použití více databázových serverů s jejich nezávislými časovými osami přicházíte o některé užitečné vlastnosti. Dva příklady:částečná ztráta transakční sémantiky generuje konflikty; předběžná analýza každého dotazu mimo databázi zavádí omezení přijímaných dotazů.
Diskuse byla docela zajímavá, a když Dimitri Fontaine zmínil vzdálené tabulkové prostory, začal jsem přemýšlet o související, ale odlišné myšlence, konkrétně:zda přístup na nižší úrovni problém sdružování zdrojů by byl opravdu nepraktický. Než jsem mohl upřesnit detaily, workshop skončil a já mohl jen načrtnout myšlenku některým lidem, kteří byli kolem tabule (mezi nimi Gabriele Bartolini, Nic Ferrier, Marko Kreen, Hannu Krosing, Greg Smith) spolu se základními otázky "vypadá to proveditelně?" a „připomíná to něco, co už znáte?“.
Stručný náčrt:zásobník aplikací lze znázornit tímto způsobem
(application) --> (connection) --> (db server) --> (resources)
kde zdroje používané databází zahrnují úložiště, RAM a CPU. Účelem je umožnit aplikaci ovládat více zdrojů za účelem zvýšení kapacity a rychlosti. „Chytré“ aplikace, které spravují několik databází, mohou být reprezentovány jako
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
zatímco řešení „sdružování připojení“ lze reprezentovat jako
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
„řešením nižší úrovně“ myslím něco jako
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
který by mohl připomínat něco známého, ale to není to, co zde navrhuji. Abych vysvětlil rozdíl, mohu zvětšit podrobnosti a napsat
(resources) = (virtual resources) --> (physical resources)
reprezentovat skutečnost, že na nejnižší úrovni můžete mít netriviální mapování mezi fyzickými objekty a virtuálními. Například úložiště SAN nebo prokládání RAID může poskytnout větší virtuální disky spojením menších fyzických disků. Takové případy by mohly být zobrazeny jako
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
Můj návrh je shromáždit zdroje na databázovém serveru úroveň, abychom mohli mít efektivnější „virtualizaci“ s využitím znalostí konkrétních případů použití pro každý zdroj (CPU, RAM, disk) a zároveň se mohli vyhnout potížím transakčního paradigmatu. Obrázek by byl:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
Výhodou je, že nemusíme spravovat všechny možné případy použití pro každý virtuální zdroj; jen musíme spravovat (a optimalizovat pro) případy použití, které PostgreSQL skutečně potřebuje. Například:WAL by měl být stále zapsán v místním „nevirtualizovaném“ úložišti, bgwriter bude přistupovat k místním a vzdáleným zdrojům (RAM a disk) atd.
Několik slov na závěr o spolehlivosti. Aby celý systém správně fungoval, potřebuje každý podsystém; dílčí selhání nejsou spravována, protože tato architektura není redundantní. Je to distribuovaný systém, ale není sdílený. Pokud by tato architektura mohla poskytovat levnou a jednoduchou škálovatelnost prostřednictvím virtuálního databázového serveru, který je funkčně ekvivalentní fyzickému serveru s většími zdroji, pak by bylo možné dosáhnout vysoké dostupnosti standardním způsobem nastavením dvou identických virtuálních serverů v konfiguraci Hot Standby.
Kvalita sítě má velký vliv na celkový výkon; tento návrh může být užitečný pouze v případě, že máte řadu počítačů ve stejné síti LAN, a to nejen z důvodu rychlosti, ale také proto, že selhání sítě by ve skutečnosti znamenalo selhání systému. I přes tato omezení si myslím, že mít tuto možnost by bylo docela užitečné.
Toto je stále náčrt, který má být použit jako reference pro další diskusi. Další možné kroky:
- vytvoření podrobného seznamu případů použití zdrojů
- rozhodnout, které technologie mohou nejlépe pomoci v jednotlivých případech použití
- odhadnout skutečný výkon/náklady na vývoj