Bez ohledu na to, zda jste se minulý měsíc zúčastnili naší konference CHAR(10) nebo ne, nyní můžete část této zkušenosti znovu prožít stažením snímků konference. Některé z nich byly zveřejněny živě během konference, některé se objevily později, ale téměř vše je tam nyní. Je smutné, že zábavná prezentace Nica Ferriera o tom, jak byl WooMe (získaný společností Zoosk) zvětšen pomocí Londiste a Django, nebyla k dispozici ve formě, kterou bychom si mohli snadno přehrát. V tomto případě jste tam určitě museli být, a to více způsoby.
Dvě přednášky, které jsem považoval za nejvíce informativní, byly aktualizace o stavech pgpool-II a pgmemcache. Oba tyto nástroje mají tu trochu frustrující kombinaci toho, že jsou opravdu užitečné a trochu nedostatečně zdokumentované vzhledem k tomu, jak jsou komplikované (alespoň v angličtině!), takže získat o nich další vhled od těch, kteří na kódu skutečně pracují, bylo skvělé.
Markusova diskuse o MVCC a shlukování měla také zábavný nádech. Jeho přednáška skončila analýzou výkonu jeho Postgres-R proti pgpool-II, Postgres-XC a PostgreSQL 9 pomocí Streaming Replication plus Hot Standby, všechny používané v clusterových konfiguracích pro urychlení výsledků testů dbt2. Ne zcela souhlasím s jeho předpokladem, že přetížení sítě je nejdůležitější složkou clusteru, protože „celkový výpočetní výkon, paměť a kapacita úložiště lze snadno škálovat“ – to není vždy pravda – ale bylo uspokojivé vidět, že PG9 HS/SR párování je v tomto ohledu efektivní.
Konference vyčlenila dvě zasedání, kde se hovořilo o obecných tématech shlukování relativně nestrukturovaným způsobem. Ostřejší diskuse hovořila o tom, co by usnadnilo nasazení PostgreSQL do infrastruktury cloud computingu. To podnítilo dost nápadů na to, abych již vytvořil dva příspěvky na blog od mých spolupracovníků.
Jedním z nápadů z této relace, který jsem považoval za obzvláště zajímavý, bylo poznamenat, že pokud máte nasazení, kde jsou uzly přidávány „elastickým“ způsobem, který se lidem líbí Abychom diskutovali v souvislosti s konceptem cloudu, právě teď existuje mezera ve spravovatelnosti, pokud jde o usnadnění komunikace aplikací s touto sadou uzlů. Pokud můžete mezi svou aplikaci a sadu uzlů vložit pgpool-II nebo pgBouncer, můžete právě teď trochu abstrahovat přesně to, co je za uzly. Ale teď jste přidali další vrstvu, a tedy potenciální úzké hrdlo celé věci. To je opak toho, o čem by měla být elastická cloudová nasazení:pouhé přidávání kapacity podle potřeby s minimální prací na správě.
Navrhovaným řešením bylo usnadnit vytvoření adresáře směrování databáze na úrovni aplikace, takže aplikace stačí požádat o typ potřebného uzlu a získat jeden, ke kterému se lze přímo připojit. Uzly se mohou jednoduše zaregistrovat do adresáře, jakmile jsou uvedeny online (nebo jsou odstraněny). To má podobnosti s některými součástmi, které se již pohybují kolem. Část pro vyhledávání adresáře, kterou můžete vložit do LDAP; Servery PostgreSQL se již mohou ohlásit prostřednictvím ZeroConf AKA Bonjour. Není těžké si představit, že tyto dva spojíme dohromady a vytvoříme aplikační vrstvu, která provádí vyhledávání LDAP připojenou ke směrovacímu backendu, který sleduje dostupné uzly prostřednictvím libovolného počtu protokolů. Jako obvykle, ďábel je v detailech. Věci jako načasování neúspěšných uzlů, rozlišení mezi čtením a zápisem (pgpool-II to dělá tak, že analyzuje SQL, což je drahé) a výsledné vysílání adresáře ukládáme do mezipaměti pro vysoký výkon a zároveň obsahuje zneplatnění mezipaměti, to všechno jsou složité detaily implementace.
S PostgreSQL 9.0, který nabízí více způsobů, než kdy jindy škálovat architekturu databáze směrem nahoru, však tento problém nezmizí. Ještě si nejsem jistý, jakou formou to lidé vyřeší, ale je to dost běžný problém, který stojí za to vyřešit.
