Oavsett om du gjorde det till vår CHAR(10)-konferens förra månaden eller inte, kan du nu återuppleva en del av upplevelsen genom att ladda ner konferensbilderna. Några av dessa publicerades live under konferensen, några dök upp senare, men nästan allt är där nu. Tyvärr var Nic Ferriers underhållande presentation om hur WooMe (uppköpt av Zoosk) skalades upp med Londiste och Django var inte tillgänglig i en form som vi enkelt kunde spela upp igen. För den behövde du verkligen vara där, på mer än ett sätt.
De två föredrag jag tyckte var mest informativa var uppdateringarna om tillstånden för pgpool-II och pgmemcache. Båda dessa verktyg har den där lite frustrerande kombinationen av att vara riktigt användbara och lite underdokumenterade i förhållande till hur komplicerade de är (åtminstone på engelska!), så att få ytterligare insikt i dem från de som faktiskt arbetar med koden var fantastiskt.
Markus diskussion om MVCC och klustring hade också en rolig twist. Hans föredrag avslutades med en prestandaanalys av hans Postgres-R mot pgpool-II, Postgres-XC och PostgreSQL 9 med hjälp av Streaming Replication plus Hot Standby, allt som används i klusterkonfigurationer för att accelerera dbt2-testresultat. Jag håller inte riktigt med om hans utgångspunkt där att nätverksstockning är den viktigaste klusterkomponenten eftersom "övergripande datorkraft, minne och lagringskapacitet kan skalas lätt" – det är inte alltid sant – men det var tillfredsställande att se att PG9 HS/SR parning är effektivt i det avseendet.
Konferensen avsatte två sessioner för att prata om allmänna klusterämnen på ett relativt ostrukturerat sätt. Den mer heta diskussionen talade om vad som skulle göra PostgreSQL-distributioner i molnbaserad infrastruktur lättare att hantera. Det rörde upp tillräckligt många idéer för att redan generera två blogginlägg från mina kollegor.
En av idéerna från den sessionen som jag tyckte var särskilt intressant var att notera att om du har en distribution där noder läggs till på det "elastiska" sätt som folk gillar att diskutera i relation till molnkonceptet, det finns en hanterbarhetslucka där just nu när det gäller att göra det enkelt för applikationer att prata med den noduppsättningen. Om du kan sätta pgpool-II eller pgBouncer mellan din applikation och uppsättningen av noder, kan du abstrahera bort exakt vad som ligger bakom noderna lite just nu. Men nu har du lagt till ytterligare ett lager och därför en potentiell flaskhals till det hela. Det är motsatsen till vad elastiska molninstallationer ska handla om:att bara lägga till kapacitet efter behov med minimalt hanteringsarbete.
En lösning som föreslagits var att göra det enklare att bygga en databasdirigeringskatalog på applikationsnivå, så att appar kan bara fråga efter vilken typ av nod som behövs och få en att ansluta direkt till. Noder kan bara registrera sig i katalogen när de läggs online (eller tas ner). Detta har likheter med vissa komponenter som redan flyter runt. Katalogsökningsdelen du kan lägga in i LDAP; PostgreSQL-servrar kan redan meddela sig själva via ZeroConf AKA Bonjour. Det är inte svårt att föreställa sig att skruva ihop dessa två, sätta ett applikationslager som gör LDAP-sökningar kopplat till en routingbackend som spårar tillgängliga noder via valfritt antal protokoll. Som vanligt sitter djävulen i detaljerna. Saker som att ta bort misslyckade noder, skilja mellan läs- och skrivtrafik (pgpool-II gör det genom att faktiskt analysera SQL, vilket är dyrt) och att göra de resulterande katalogsändningarna cachade för hög prestanda samtidigt som de innehåller cache-ogiltigförklaring är alla knepiga implementeringsdetaljer för att komma rätt.
Med PostgreSQL 9.0 som har fler sätt än någonsin att skala upp databasarkitektur, försvinner inte detta problem dock. Jag är inte säker på vilken form folk kommer att lösa det i ännu, men det är ett tillräckligt vanligt problem för att det är värt att lösa det.
