horizontální škálovatelnost se Shardingem v PostgreSQL-kam směřuje Část 1 ze 3

nedávno jsem měl možnost zúčastnit se několika zajímavých rozhovorů o budoucnosti shardingu v PostgreSQL. První přednášku přednesl Bruce Momjain v PostgreSQL conf Ottawa (květen 2019), kde představil budoucnost Shardingu v PostgreSQL a hovořil o současném stavu a budoucnosti vestavěného shardingu v PostgreSQL. Druhou přednášku jsem prezentoval na PostgreSQL konferenci v Pekingu (Čína – červenec 2019), kde jsem také hovořil o současném stavu a budoucnosti vestavěného shardingu v PG. V podstatě jsem použil snímky z Bruceovy prezentace (s jeho svolením-samozřejmě) a přidal několik dalších snímků diskutujících o požadavcích, které vyžadují škálovatelnost, a také hovořil o dalších alternativách pro global transaction manager.

během konference PostgreSQL v Ottawě jsem pokračoval v tradici uspořádání snídaňového setkání během konferenčního týdne k diskusi o tématu shardingu. Dělali jsme to každý rok za posledních několik let, kdy jsem pracoval s EnterpriseDB a pokračoval v setkání nyní, když pracuji s HighGo Software Inc. Snídaňového setkání se letos zúčastnili lidé z EDB, NTT, HighGO a Pivotal, počet účastníků v letošním roce byl více než to, co jsme dostávali za poslední roky, takže jsme se museli rozhodnout pro větší snídaňový stůl. Purpose účelem tohoto setkání je získat lidi ze společností, které na této funkci pracují v komunitě, a tentokrát také lidi ze společností, které mají v úmyslu přispět k této funkci v komunitě. Na programu je projednání současného stavu bourání, průběžných prací, co se bude dít. Dalšími tématy diskutovanými na tomto setkání je diskutovat o celkovém cíli funkce shardingu, jaké případy použití očekáváme, že z těchto funkcí budou mít prospěch, jaké jsou hrubé Časové stupnice pro získání něčeho v PG, které můžeme nazvat shardingem.

o tomto blogu

původně jsem doufal, že toto téma pokryji V jednom blogu, ale protože tato funkce je tak obrovská, blog se také ukázal být mnohem delší než to, co jsem původně očekával psát. Zakryl jsem to 3 blogy, aby se lidé neunavili čtením a ztratili tam zájem. Závěr je uveden na konci 3. blogu této série.

první blog série se bude zabývat škálovatelností, jaké jsou různé typy škálovatelnosti a jaké jsou v současné době dostupné možnosti škálovatelnosti v PostgreSQL. Druhá část blogu se zaměřuje na deklarativní dělení přidané v PG 10 a na to, jak dnes funguje sharding v PostgreSQL. Třetí část tohoto blogu se zaměřuje na vestavěnou architekturu shardingu, možnosti pushdown již v PG a nakonec zbývající funkce a související výzvy.

jedna věc, o které jsem v tomto blogu nemluvil,jsou další řešení, která se pokusila poskytnout sharding, existují postgres-xc, xl a pg_shards tohoto světa. Věřím, že některé z těchto pokusů byly působivé, ale všechny mají svá omezení,která jim bránila v dosažení hlavního času s komunitou PG.

co je škálovatelnost a proč ji potřebujeme

než se dostaneme do shardingu, je důležité pochopit „co je škálovatelnost“ a potřebu škálovatelnosti a jaké jsou různé způsoby, jak škálovatelnost databáze. Škálování databáze je v podstatě schopnost zvýšit propustnost/výkon databáze zvýšením zdrojů, jako je I/ O, paměť, CPU nebo přidáním dalších počítačů do clusteru. Přidání více výpočtů zase znamená zvýšení výkonu databáze pomocí zdrojů z více systémů k provedení práce. Vaše databáze potřebuje škálovatelnost pouze v případě, že používáte databázi PostgreSQL na jednom standardním serveru a není schopna uspokojit potřebu vaší pracovní zátěže. Příznaky, které ukazují na důvod nutnosti škálovatelnosti, jsou databáze, která nefunguje dobře, velikost dat roste velmi velká a nemůže se vejít do úložiště serveru, databáze získává příliš mnoho souběžných klientů, které není schopna zvládnout, existují složité analytické dotazy, které v některých případech trvají příliš dlouho nebo nevracejí vůbec žádná data a zastavují systém.

když uživatel začne vidět některé problémyuvedené v předchozím odstavci, musí přemýšlet o různých možnostechk vyřešení tohoto problému dříve, než nakonec začnou přemýšlet o škálovatelnosti.Různé možnosti, které by měl uživatel zvážit, než přemýšlí o škálovatelnostijsou následující :

1. optimalizace schématu-je třeba se ujistit, že schéma je plně optimalizováno pro zpracování pracovní zátěže a typu dotazů odeslaných na databázový server. Důležitým aspektem je zkontrolovat, zda jsou uživatelské tabulky dostatečně velké, aby mohly být rozděleny, takže dotazy mohou být směrovány do tabulek menší velikosti. Také je třeba přemýšlet, zda jsou tabulky správně normalizovány.
2. Application logic tweaking-další důležitou oblastí, na kterou musíme myslet, když narazíme na problém, je ladění logiky aplikací. Uživatel může přemýšlet o tom, zda lze aplikaci vylepšit, aby získal nejlepší výkon z databáze. To může zahrnovat přepsání některých databázových dotazů nebo v některých případech provedení refaktoringu na úrovni aplikace pro urychlení výkonu.
3. ladění konfiguračních parametrů databáze – toto je pravděpodobně nejdůležitější návrh z možností, konfigurační parametry databáze je třeba otočit podle pracovní zátěže a typu provozu generovaného pro databázi. Hodnoty důležitých parametrů, jako je sdílená paměť, pracovní mem, checkpoint atd., je třeba nakonfigurovat správně a podle worklaod. Toto je dobrý zdroj, který popisuje některé důležité konfigurační parametry pro ladění databáze PG.

https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Možnosti škálovatelnosti

po vyzkoušení všech výše uvedených možností nebo více a problémy stále přetrvávají, je nejlepší začít přemýšlet o možnostech škálovatelnosti. Databázi lze škálovat dvěma způsoby :

dvě možnosti škálovatelnosti jsou poměrně jednoduché pochopit, vertikální škálovatelnost je o škálování nahoru a horizontální škálovatelnost je o škálování bočních cest. Vertikální škálovatelnost je dosaženo tím, že posílí jeden server, přidání více zdrojů na server, aby se dosáhlo škálovatelnost. Horizontální škálovatelnost je o házení více počítačů na problém, přidání více uzlů do clusteru, aby bylo možné použít prostředky z více počítačů k získání škálovatelnosti databáze.

vertikální škálovatelnost je způsob, jak jít, pokud splňuje požadavky uživatele a je také nákladově efektivní pro uživatele. Důvodem vertikální je preferovaná možnost je vzhledem k snadné konfiguraci a minimální údržbu a správce režie. Můžete jednoduše posílit server s rychlejším úložištěm, více paměti a přidat více a rychlejší CPU pro zvýšení výkonu vaší databáze. Existují hlavně dva důvody, proč vertikální škálovatelnost již není volbou pro vaše pracovní zatížení. V první řadě důvodem je, že posílení serveru může být velmi nákladné a v určitém okamžiku se může stát nákladově efektivní pro uživatele. Úložiště, počet souběžných klientů a příchozí provoz se stává natolik, že jediný server nemohl škálovat, aby uspokojil pracovní zátěž. Diskutuje se o tom, že PostgreSQL může škálovat pouze 64 jader a poté se linka stává lineární. Jsou to však publikované výsledky benchmarků, které ukazují škálování PostgreSQL na více než 64 jádrech, věřím, že škálování založené na jádru je relativní k počtu souběžných klientů a provozu databáze.

horizontální škálovatelnost je o přidání více než jednoho počítače do databázového clusteru, aby se využily zdroje dalších počítačů k získání horizontální škálovatelnosti. Horizontální škálovatelnost není první volbou, protože zahrnuje režii konfigurace a údržby clusteru strojů, takže uživatel musí přemýšlet o prostojích, převzetí služeb při selhání, zálohování atd. všech strojů v clusteru. Horizontální škálovatelnost se stává jasnou volbou, pokud požadavky na pracovní zátěž nemohou být splněny s jedním serverem z důvodů uvedených v předchozím odstavci. Existují způsoby, jak získat horizontální škálovatelnost i bez shardingu, nejoblíbenějším řešením horizontální škálovatelnosti bez shardingu je škálovatelnost čtení pomocí Pgpool II. Pgpool II je middleware produkt, který sedí mezi clusterem klienta a PostgreSQL a poskytuje funkce, jako je sdružování připojení, vyvažování zátěže, převzetí služeb při selhání atd. Pgpool II poskytuje horizontální škálovatelnost vyrovnáváním zatížení, odesíláním zápisů do primárního uzlu a vyrovnáváním zatížení přečtených příkazů napříč stand-by uzly. Pgpool II zajišťuje vyrovnávání zatížení na úrovni připojení a na úrovni prohlášení, s vyrovnáváním zátěže na úrovni připojení proces pgpool II vytváří spojení se Stand-by uzlem, všechna čtení pro připojení jsou odeslána do stand-by uzlu a zápisy jsou odeslány do primárního uzlu. S připojením na úrovni příkazů (přichází v pgpool II 4.1) je každý příkaz vyvážen na všech stand-by uzlech. K tomuto tématu je dobrý článek https://highgo.ca/2019/07/19/pgpool-ii-4-1-taking-the-bull-by-its-horn/