Aky file system pre DB server?

Re:Aky file system pre DB server?
« Odpověď #30 kdy: 02. 09. 2024, 07:05:56 »
Ohledně fragmentace CoW FS (a nejspíš i CoW block device v LVM), nad rámec toho co psal Michal Šmucr:
ano SSD svou nulovou latencí seeku (v porovnání s mechanickým diskem) v principu odstraní tento konkrétní problém. Ale nějaké další problémy zbydou. A řekněme, že nebudu řešit dvoupatrové mapování a všelijaké snaživé chytristiky uvnitř SSD.

CoW znamená obecně "Copy On Write" = změny zapisuj na jiné místo, než kde jsou původně uložena měněná data. Takže pokud byl soubor původně uložený hezky sekvenčně, tak teď některé bloky (na jakési úrovni alokace) "vystupují mimo řadu". Pokud jsou ty zápisy drobné a rozházené, tak těch "vystoupení mimo řadu" je velká spousta, a je potřeba tato "evidovat" jednotlivě každé zvlášť. V zásadě to vede k otázce na organizaci metadat FS. Pokud sekvenční alokace vyžaduje relativně prostý záznam [počáteční blok; počet] tak "celý soubor sekvenčně" si vyžádá ideálně jediný záznam :-) A jak do něj začnete CoW stylem zapisovat, začne se ta sekvence drolit do většího počtu dílčích úseků. Při sekvenčním čtení si toto vyžádá větší počet jednotlivých I/O operací skrz blokovou vrstvu vůči disku. Při náhodném čtení je potřeba "pouze" projít delší/hlubší "index v rámci metadat" (spojový seznam, strom apod.) než najdete informaci o umístění žádaného bloku. Mimochodem zkratka BTRFS podle mého původně znamenala B-TRee FS - ale podrobnosti jsem nezkoumal. Obecně průchod BTree indexem (asociativním polem) při vyhledávání záznamu škáluje jak... log(n) ? Samozřejmě objem metadat je maličký ve srovnání se souborem jako celkem, mohou být uložena a načtena nějak optimálně, takže v optimistické variantě jde fakt jenom o to projít ten per-file stromeček v RAMce.

BTRFS má CoW chování by default šmahem zapnuté na jakýkoli soubor, na celý FS - takže se při drobných lokálních modifikacích souborů musí strašně fragmentovat :-) Ono to má asi nějaké optimalizace proti tomuto jevu, ale dával bych si na to bacha. Tohleto CoW chování je nejspíš výhodné z hlediska bezpečnosti FS = na disku jsou vždycky jak původní tak nová data, a "okno příležitosti pro poškození při výpadku napájení" představuje okamžik "přehození výhybky v metadatech", který lze pro jistotu napřed žurnálovat. (Přehlédněme na moment škatule batule, které v dnešní době potichu dělá interně SSD). Především je to výhodné / prostorově efektivní pro vytváření snapshotů: co se nezměnilo, to se alokuje jenom jednou, pro "snapshot původního stavu" i pro aktuální živá data. Zamrzlý snapshot předchozího stavu i "aktuální náhled" mají vlastně jenom oddělené stromečky metadat (a to možná ještě oddělené jenom do jisté míry) - opět jsem nestudoval detaily.

Zde v tomto vlákně se řeší DB server. Databáze běžně mění data ve svých záznamech. Drobné kousky dat. Taky celé záznamy odmazává, což řeší víceméně interní dealokací ve svém DBMS, následně může dealokovaný prostor recyklovat (což FS pod DB extentem vnímá jako přepis souboru). Pokud FS dělá při přepisech zásadně CoW, tak potěš koště, ten BTree v rámci FS bude bobtnat. Konkrétně u BTRFS se CoW chování dá potlačit - dokud nevyrobíte snapshot.

Podobně pokud BTRFS použijete v hypervizoru jako storage pro image blokových zařízení virtuálů, by default bude provoz virtuálů ty image brutálně fragmentovat. Osobně navrhuji, CoW chování pro tyto potřeby zakázat - tuším se to dá udělat per adresář - nebo per subvolume? (není třeba to dělat na celý FS). Pokud máte image virtuálek jako soubory o pevné velikosti, tak se potom přepisy budou dít in-place (dokud neštípnete snapshot, třeba kvůli pořízení zálohy).
Kolmá poznámka: další dobrou fintou je protáhnout z virtuálu na hostitele TRIM/discard, a ty image vyrobit jako "sparse files" (prázdné místo v podkladovém btrfs zůstane předem nealokované). Stalo se mi nedávno, že se ve virtuálu cosi zbláznilo a během okamžiku přetekl disk... (image na podkladovém BTRFS). Po smazání souboru uvnitř virtuálky jsem zvenčí nedostal zpátky zdaleka celé uvolněné místo, ani po BTRFS rebalance - asi že ta dealokace nebyla hezky zarovnaná zevnitř-ven na celé alokační "chunky" podkladového BTRFS :-(

BTRFS dělá CoW hezky uvnitř filesystému - a pokud ho omezíte na snapshoty, tak snapshot = subvolume = adresář v rámci namountovaného "celého" volume (oddílu na blokovém zařízení). Snapshot=subvolume "sdílí alokační pool" s ostatními subvolumy v rámci blokového oddílu. Je v tomto smyslu užitečné, mít snapshoty implementovány v rámci FS, protože tím pádem fungují "téměř per file" (pro admina opticky per directory subtree) a je tam právě ten sdílený alokační mechanismus, což zřejmě umožňuje jistou efektivitu (oproti CoW v rámci LVM).

CoW snapshot v rámci LVM je historicky starší a funguje taky, ale pak děláte snapshot na celé blokové zařízení (volume). Mimochodem jsem našel zmínku o jedné fičuře, která mi připadá "nenápadně půvabná" pro potřeby pořizování záloh: jmenuje se "snapshot-origin". V tom případě CoW funguje tak, že při zápisu změn (do blokového zařízení o pevné velikosti) se změny zapíšou především do živého "primárního volume", který pojede dál, a zároveň taky do "CoW space mimo sekvenci", kde žije zamrzlý snapshot. Pořídíte si takový "zamrzlý snapshot", uděláte z něj zálohu, a smažete ho. Ve výsledku původní "primární volume" nijak neutrpěl CoW fragmentací, protože ten fragmentovaný chumel jste po použití zahodili. Bylo by fajn, kdyby tohle umělo BTRFS - ale nějak nedokážu najít žádnou zmínku, že by tohle šlo.

https://unix.stackexchange.com/questions/756366/is-there-a-reverse-cow-filesystem-or-lvm-feature-for-linux

Mimochodem ten nápad, hintovat SSDčku zda jde v rámci souboru o konkrétní append nebo konkrétní přepis, ten je hodně hezkej :-) Taky jsem tuším viděl nějaký návrh, diktovat SSDčku ještě mnohem podrobněji interní mapování - už nedohledám, kde jsem to viděl, ale šlo v zásadě o návrh "transparentního vendor-independent rozhraní pro pro manipulaci s erase bloky". Připadalo mi, že si navrhovatelé chtějí z SSDčka udělat "pool NAND bloků na způsob prehistorického MTD". Tuším to byl někdo jako Google/Amazon... (operátor velkých cloudů).


Re:Aky file system pre DB server?
« Odpověď #31 kdy: 02. 09. 2024, 09:10:43 »
Celou dobu se tu řeší SSD, což v zadání nebylo explicitně uvedeno. Vzhledem k tomu, že se v zadání píše o MariaDB a MySQL, tedy žádné velké databáze, dá se SSD předpokládat.

Nicméně pokud byste přeci jen chtěl stavět server pro databázi s velkým objemem dat, ke kterým se nepřistupuje až tak často, a řešilo se to pomocí HDD (rotačních disků), tam je CoW souborový systém nevhodný, protože sabotuje to, o co se DB při zápisu na disk snaží (tedy přepisovat data na místě, aby se minimalizoval zápis, a řídit fragmentaci dat).

Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)

Re:Aky file system pre DB server?
« Odpověď #32 kdy: 02. 09. 2024, 10:31:29 »
Já jsem teď ne moc do hloubky hledal vhodný FS pro Postgre. Nakonec mi z toho vyšla podle nějakých benchmarků podobná věc, jako tady píší ostatní - XFS nebo EXT4. A protože EXT4 je rozšířenější a běží na ní i zbytek systémů, zvolil jsem ji. Propadlo BTRFS, to bych pro DB nedoporučoval.
Co může být pro ostatní užitečný parametr, tak možnost rozšířit partition, když dochází místo. Partition pro DB vždycky stavím nad LVM, aby to šlo snadno. EXT4 to umí, XFS předpokládám taky, ale doporučuju si to prostě ohlídat.

Re:Aky file system pre DB server?
« Odpověď #33 kdy: 02. 09. 2024, 16:11:55 »
A pak BUM, přijde kolega a nějakou chytrostí z toho leze 10x víc dat...navíc machruje a neprozradí, jak to udělal...

Skvělý kolega.

Re:Aky file system pre DB server?
« Odpověď #34 kdy: 03. 09. 2024, 14:13:09 »
Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)

Zdaleka neznám všechny databázové servery, ale myslím, že to bohužel zůstává pořád na adminovi nebo možná dnes i adminovi s ChatGPT :)

Každý ten engine má už relativně dlouho konf. parametry, které ovládají nějakou formou paralelismus při I/O operacích, co se dá potencionálně zvýšit při použití na SSD.
Také můžete narazit na možnost ladit query planner tak, aby víc preferoval buď náhodný, nebo sekvenční přístup.
Většinou je to formou nějakého vážení (U Oracle je to volba optimizer_index_cost_adj, u Postgresu pak třeba random_page_cost resp. seq_page_cost), u některých workloadů to může hrát roli.
Nakonec tam mohou opravdu být i specifické optimalizační mechanismy primárně pro točivé disky, což je asi to, na co jste narážel. Např. innodb_random_read_ahead nebo innodb_flush_neighbors. Tam třeba nějaké změny byly, innodb_flush_neighbors byl u MySQL 5.x ve výchozím stavu povolený a od MySQL 8 to musíte explicitně zapnout.
MariaDB jde trochu dál. Nejen že to není ve výchozím nastavení povoleno, ale snaží se opravdu detekovat SSD a když se jí to povede, tak volbu ignoruje.
https://mariadb.com/kb/en/innodb-system-variables/#innodb_flush_neighbors
To je asi zatím jediné místo, kde je použitá podobná autodetekce.

U těch CoW systémů, tak tam jde o to dohledat, jestli se zbytečně nezapisuje vícekrát, než je nutné, a nezvyšuje WAF. Např. u ZFS a innodb s vypnutím doublewrite mechanismu, tam je to vcelku jasné. U některých jiných voleb to ale může být trochu sporné, viz třeba ten ZFS logbias, co jsem zmiňoval. Jedna věc může být nějaký rychlý benchmark, druhá pak jak ten výkon bude vypadat po dvou letech provozu. Atd.
U toho ZFS a innodb je tam pak ještě další aspekt, který v určitých situacích může hrát roli. A to vyladění velikostí innodb_buffer poolu a ARC u ZFS, resp. nalezení jejich optimálního mixu při dané velikosti RAM a výrazně větší databázi.

Nakonec ty velikosti bloků, to je také relativně komplexní téma, aspoň pro mě.
Vstupuje do toho hodně různých vrstev a subsystémů ovlivňuje to workload atp. V tuhle chvíli jsou, co vím, výchozí hodnoty (4k - Oracle; 8k - Postgres, MSSQL, Firebird; 16k - innodb). Osobně bych se primárně koncentroval na ten workload, výchozí bude asi v pohodě pro valnou většinu věcí, a jakákoliv změna má logicky i nějaké negativum. V určitých situacích, kdy tam bude hodně souběžných krátkých zápisů a modifikací, tak může kratší 4k stránka pomoct, naopak třeba pokud se u nějaké db používá komprese, tak ty delší (32, 64k) můžou znatelně zvýšit její efektivitu. Takže člověk může dojít k různým závěrům,
pokud dělá např. transakčně orientovanou službu s vysokou mírou souběžného přístupu, nebo třeba někam ukládá hromady logů a jednou za čas z toho něco vytáhne.

Nicméně vy jste spíš narážel na velikost db stránky ve vztahu ke konkrétnímu SSD.
Jak jste zmiňoval blok na SSD, tak jste nejspíš myslel stránku, což je standardně nejmenší adresovatelná jednotka na SSD. Blok u SSD pak spíš brán ve smyslu více stránek, co se mažou jedním P/E cyklem, a může mít i několik MB.
U nativní velikost stránky bude asi záležet na generaci SSD, bývalo to 4k, u novějších velkých TLC/QLC disků to může být i 8, 16k. Do systému se to, co vím, žádným standardním způsobem neindikuje, abyste to použil v nějaké autodetekci. Některá pokročilejší NVME SSD mají možnost přes standardní namespace id-ns zjistit, že podporují víc režimů komunikace s hostem (např. 4k - výchozí, 8k - optimální). Následně se pak dá režim SSD přes nvme format příkaz změnit (destruktivně!).
To přepne vnitřní režim SSD, který do té doby typicky fungoval na úrovni tzv. sub-pages, a do hosta se indikuje nová velikost fyzického sektoru.
Pak se třeba dá zvětšit i velikost log. bloku na novém FS (tam myslím i dokonce nějaká autodetekce bude) a následně i porovnat s délkou stránky v DB. Pokud bude stránka stejně dlouhá nebo delší než na FS resp. u fyz. sektoru, fajn. Jestli bude kratší, pak bych režim disku nejspíš nechal být.
Motivací k tomu přepnutí by mohla být efektivnější činnost všech vrstev. Nicméně reálný výkonnostní dopad by se pak samozřejmě musel ověřit.
Nejspíš, a to už se dívám za roh, by se mohl snížit WAF v hardware. Pokud to SSD podporuje reportování zapsaných dat na úrovni buňek i to se dá samozřejmě zjistit s nějakým referenčním workloadem.


Re:Aky file system pre DB server?
« Odpověď #35 kdy: 03. 09. 2024, 14:17:02 »
Navážu ještě obecně na ty SSD. Resp. proč si nemyslím, že by provoz s tou emulovanou velikostí bloku byla nutně až tak zásadní tragédie. Nebo, že by bylo zásadně nutné se zkusit vždy trefovat s délkami zápisů do nějakých interních struktur v SSD (page, stripe napříč čipy, neřkuli P/E blok). Ano samozřejmě pokud ta optimalizace nic nestojí, a je to úplně evidentní, směle do toho. Na druhou stranu, pokud je to na hraně a člověk si není jistý benefity, tak to nechat být.
Ano můžou se najít některé návody, kdy to trefování třeba velmi pomůže, dost často např. na laciných dram-less SSD.
Stejně tak třeba chybně vyvodit, že když to člověk neudělá, tak mu za půl roku chcípne SSD, protože razantně zvýší WAF v hardware.
Tady je na místě připomenout jeden aspekt, který občas zapadá. Když výrobce SSD specifikuje výdrž (TBW, DWPD), tak pokud to neuvede jinak, tak je podle daných JEDEC standardů 218, 219 přesně definovaný workload.
Pro serverové disky je to náhodný zápis, náhodných dat (kvůli kompresi) a přesně daná distribuce délek zápisů. Teď z hlavy je tam 2/3 zápisů s 4k délkou, 1/10 s 8k délkou, zbytek nějaký definovaný mix různých délek. Výdrž se udává ve velikostí zápisů z hosta (ne do buněk) a využije se celá logická kapacita disku.
Tzn. tenhle údaj už má v sobě kompenzovaný WAF v hardware s tímhle konkrétním workloadem.
Není to tak, že by na to někdo sypal v sekvenčním zápisu, a s blokem tak, aby to bylo "příjemné" pro SSD (pak je ta výdrž ještě vyšší).

Takže pokud je někdo schopen aspoň nahrubo odhadnout (nebo extrapolovat z měření, simulace) množství zápisů za den, neměl by být extra překvapený. A ve většině případů to se slušnými disky je naprosto v pohodě, mimo nějakých extrémních workloadů. SSD používám na serverech asi 12 let (tzn. tak tři generace disků) a na problémy s výdrží jsem během celkové životnosti serverů nenarazil i na relativně dost exponovaných místech.
Ano viděl jsem i SSD, která se přepnulo do R/O a mělo wearout 100%. Ale to šlo o vyloženou blbost, kdy někdo použil nejlacinější SATA SSD (level - upgrade notebooku pro sestřenici) na vytěžovanou cache s metadaty.

ZAJDAN

  • *****
  • 2 086
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #36 kdy: 04. 09. 2024, 19:19:45 »
Do chvíle, než se to sesype a už to nikdo nedá dohromady. Jinak bych doporučil kritická data hlavně zálohovat. (RAID a snapshoty nejsou záloha.)
Přesně tak, jak se BTRFS dojebe tak je makačka to dát dokupy :(
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.

ZAJDAN

  • *****
  • 2 086
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #37 kdy: 04. 09. 2024, 19:20:33 »
SAP HANA pro své partitions s logy a daty požaduje XFS
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.

Re:Aky file system pre DB server?
« Odpověď #38 kdy: 04. 09. 2024, 23:29:42 »
Přesně tak, jak se BTRFS dojebe tak je makačka to dát dokupy :(

Ťukám, zatím se mi nestala situace, ze bych se z něčeho standardními nástroji nedostal a přišel o data. Ale jakože bych za to dal ruku do ohně :)) Měl jsem to s BTRFS na etapy, vždycky jsem si to zhruba po dvou letech vyzkoušel, nejdřív super skvělé, subvolumes, snapshoty a končilo to typicky tím, že to přestalo reagovat, koukal jsem na backtracy z kernelu a přemýšlel, jestli na to mám ještě hledět, nebo už to PC můžu vzít tlačítkem power a jít si lehnout. Pak vždycky zpátky na zem, a zas pauza :)
Ale je fakt, že ten základ se asi ustabilizoval. Když si člověk najde aplikaci, kde to nedělá zásadní potíže a vyhne se problematickým věcem jako je třeba ten multi-device, dá se s tím existovat.
Jak jsem zmiňoval, přijde mi to fajn na rolling distribuce, nebo věci, co se i v případě zásadního problému dají v podstatě rychle deployovat znovu.
Krom postupného vychytávání chyb se taky přizpůsobily výchozí nastavení (např. dup profil na metadata) a distribuce mají obvykle naplánovanou periodickou údržbu FS s nějakým rebalancem. Do toho jsem si samozřejmě u pokusů předtím šlápl taky, klasika volné místo a nejde zapisovat.. Pak jsem taky chvíli uvažoval, jestli jsem si místo s BTRFS neměl hrát s Tamagoči, které se taky vyznačovalo tím, že když se mu nedalo najíst a nepohladilo se, tak samo chcíplo.
Je tam sice pár věci, co mě pořád štvou, třeba dlouhé výtuhy při povolených kvótách s práci se snapshoty atp., ale nakonec to nějak jede, PCčka, Synology, kontejnery atp.

Nicméně i přesto, pro dedikovaný db server bych BTRFS fakt asi neřešil. I kdyby s tím nebyly žádné potíže, tak tím jak je to teď relativně neefektivní s krátkými random přepisy, bych to fakt neřešil pro nic jiného než nějaké malé, nenráročné db.
Straight from the horse's mouth, BTRFS guru Mr. Bacik:
https://www.percona.com/blog/taking-a-look-at-btrfs-for-mysql/#comment-10973474

Re:Aky file system pre DB server?
« Odpověď #39 kdy: 06. 09. 2024, 14:40:55 »
Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)

Prizpusobovat se SSD nestoji za namahu. Oracle i Postgres maji uz od pradavna parametry optimizeru pro nahodne a sekvencni cteni. Takze se dokazi v pohodo SSSD prizpusobit. Pokud uz se to predelava, tak se to prepise kompletne.
AWS Aurora - klon Posgresu - nepouziva WAL logy pro replikaci, a pri zapisu na "disk" pouziva API EFS filesystemu.

Oracle pouziva pluginy pro zapis na ruzne "disky". Jeden plugin treba umi "direct NFS", coz je userspace klient pro NFS. Oracle Exadata pouzivala Infiniband, kdy cluster nekolika DB serveru pozival zapis do clusteru nekolika "cell serveru". Dneska to pokrocilo o kousek dal a z Infinibandu se vyvinulo "RDMA - remote DMA". Tahle technologie umi prenest data z pameti jednoho serveru na druhy, bez toho aby se toho ucastnil OS anebo CPU s minimalni latenci. Krome Infunibandu je tu jeste "RoCE" - RDMA over Converged Ethernet.

Takze bych rekl, ze databaze se spis prizpusobuji tomu, ze nebudou mit zadne disky, a misto toho budou komunikovat s nejakou distribuovanou sitovou sluzbou.

Re:Aky file system pre DB server?
« Odpověď #40 kdy: 06. 09. 2024, 21:40:40 »
Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)

Prizpusobovat se SSD nestoji za namahu. Oracle i Postgres maji uz od pradavna parametry optimizeru pro nahodne a sekvencni cteni. Takze se dokazi v pohodo SSSD prizpusobit. Pokud uz se to predelava, tak se to prepise kompletne.
AWS Aurora - klon Posgresu - nepouziva WAL logy pro replikaci, a pri zapisu na "disk" pouziva API EFS filesystemu.

Oracle pouziva pluginy pro zapis na ruzne "disky". Jeden plugin treba umi "direct NFS", coz je userspace klient pro NFS. Oracle Exadata pouzivala Infiniband, kdy cluster nekolika DB serveru pozival zapis do clusteru nekolika "cell serveru". Dneska to pokrocilo o kousek dal a z Infinibandu se vyvinulo "RDMA - remote DMA". Tahle technologie umi prenest data z pameti jednoho serveru na druhy, bez toho aby se toho ucastnil OS anebo CPU s minimalni latenci. Krome Infunibandu je tu jeste "RoCE" - RDMA over Converged Ethernet.

Takze bych rekl, ze databaze se spis prizpusobuji tomu, ze nebudou mit zadne disky, a misto toho budou komunikovat s nejakou distribuovanou sitovou sluzbou.

Postgres Neon https://neon.tech/ se snaží o takovou architekturu. Jinak samozřejmě Aurora Postgres a Aurora MySQL.