PostgreSQL Connection Pooling:Část 1 – Klady a zápory

Před dlouhou dobou, v předaleké galaxii, byla „vlákna“ programátorskou novinkou, která se používala jen zřídka a byla málokdy důvěryhodná. V tomto prostředí se první vývojáři PostgreSQL rozhodli, že rozvětvení procesu pro každé připojení k databázi je nejbezpečnější volbou. Byla by škoda, kdyby vaše databáze nakonec spadla.

Od té doby pod tím mostem proteklo hodně vody, ale komunita PostgreSQL zůstala na svém původním rozhodnutí. Je těžké zavinit jejich argument – ​​protože je naprostá pravda, že:

• Každý klient, který má svůj vlastní proces, zabraňuje špatně se chovajícímu klientovi zřítit celou databázi.
• Na moderních systémech Linux je rozdíl v režii mezi rozvětvením procesu a vytvořením vlákna mnohem menší než dříve.
• Přechod na vícevláknovou architekturu bude vyžadovat rozsáhlé přepisy.

V moderních webových aplikacích však klienti obvykle otevírají mnoho spojení. Vývojářům se často důrazně nedoporučuje udržovat připojení k databázi, zatímco probíhají jiné operace. "Otevřete připojení co nejpozději, ukončete připojení co nejdříve." To však způsobuje problém s architekturou PostgreSQL – forkování procesu se stává drahým, když jsou transakce velmi krátké, jak velí běžná moudrost, že by měly být.

Architektura fondu připojení

Použití moderní jazykové knihovny tento problém poněkud redukuje – sdružování připojení je základní funkcí většiny populárních databázových knihoven. Zajišťuje, že „uzavřená“ připojení nejsou ve skutečnosti uzavřena, ale vracejí se do fondu, a „otevřením“ nového připojení se vrátí stejné „fyzické připojení“, což snižuje skutečné rozvětvení na straně PostgreSQL.

Moderní webové aplikace jsou zřídka monolitické a často používají více jazyků a technologií. Použití fondu připojení v každém modulu je stěží efektivní:

• I s relativně malým počtem modulů a malou velikostí fondu v každém skončíte se spoustou serverových procesů. Přepínání kontextu mezi nimi je nákladné.
• Podpora sdružování se mezi knihovnami a jazyky značně liší – jeden špatně fungující fond může spotřebovat všechny zdroje a databázi zanechat ostatním modulům nedostupnou.
• Neexistuje žádné centralizované řízení – nelze použít opatření, jako jsou limity přístupu pro konkrétního klienta.

V důsledku toho byly pro PostgreSQL vyvinuty populární middleware. Ty jsou umístěny mezi databází a klienty, někdy na samostatném serveru (fyzickém nebo virtuálním) a někdy na stejném boxu, a vytvářejí fond, ke kterému se mohou klienti připojit. Tyto middleware jsou:

• Optimalizováno pro PostgreSQL a jeho poměrně unikátní architekturu mezi moderními DBMS.
• Poskytujte centralizované řízení přístupu pro různé klienty.
• Umožňují vám sklízet stejné odměny jako fondy na straně klienta a pak ještě další (podrobněji o nich pojednáme v našich dalších příspěvcích)!

Nevýhody PostgreSQL Connection Pooler

Soubor připojení je téměř nepostradatelnou součástí nastavení PostgreSQL připraveného na provoz. I když existuje spousta dobře zdokumentovaných výhod používání sdružování připojení, existují některé argumenty proti použití jednoho:

• Zavedení middlewaru do komunikace nevyhnutelně přináší určitou latenci. Když se však nachází na stejném hostiteli a zohledníme režii spojené s rozvětvením připojení, je to v praxi zanedbatelné, jak uvidíme v další části.
• Z middlewaru se stává jediný bod selhání. Použití clusteru na této úrovni může tento problém vyřešit, ale to přináší další složitost architektury.

  

• Middleware znamená dodatečné náklady. Buď potřebujete další server (nebo 3), nebo vaše databázové servery musí mít dostatek zdrojů, aby kromě PostgreSQL podporovaly i pooler připojení.
• Sdílení připojení mezi různými moduly se může stát bezpečnostní chybou. Je velmi důležité, abychom nakonfigurovali pgPool nebo PgBouncer tak, aby vyčistili připojení předtím, než se vrátí do fondu.
• Ověřování se přesune z DBMS do sdružování připojení. To nemusí být vždy přijatelné.

  

• Zvětšuje plochu pro útok, pokud není přístup k podkladové databázi uzamčen tak, aby byl umožněn přístup pouze prostřednictvím fondu připojení.
• Vytváří další komponentu, kterou je třeba udržovat, vyladit pro vaši pracovní zátěž, často opravovat zabezpečení a podle potřeby aktualizovat.

Měli byste použít PostgreSQL Connection Pooler?

Všechny tyto problémy jsou však v komunitě PostgreSQL dobře diskutovány a zmírňující strategie zajišťují, že klady pooleru připojení daleko převyšují jejich nevýhody. Naše testy ukazují, že i malý počet klientů může výrazně těžit z používání pooleru připojení. Stojí za další úsilí o konfiguraci a údržbu.

V dalším příspěvku probereme jeden z nejpopulárnějších poolerů připojení ve světě PostgreSQL – PgBouncer, následovaný Pgpool-II a nakonec srovnání těchto dvou testů výkonu Sdružování připojení PostgreSQL v našem posledním příspěvku seriálu.