Of u nu wel of niet onze CHAR(10)-conferentie vorige maand hebt bezocht, u kunt nu een deel van de ervaring opnieuw beleven door de conferentiedia's te downloaden. Sommige daarvan werden tijdens de conferentie live gepost, andere kwamen later opdagen, maar bijna alles is er nu. Helaas was de vermakelijke presentatie van Nic Ferrier over hoe WooMe (overgenomen door Zoosk) werd opgeschaald met Londiste en Django niet beschikbaar was in een vorm die we gemakkelijk konden herhalen. Daarvoor moest je er zeker bij zijn, in meer dan één opzicht.
De twee gesprekken die ik het meest informatief vond, waren de updates over de toestanden van pgpool-II en pgmemcache. Beide tools hebben die enigszins frustrerende combinatie van echt nuttig en een beetje ondergedocumenteerd in verhouding tot hoe ingewikkeld ze zijn (in het Engels tenminste!), dus het was geweldig om er meer inzicht in te krijgen van degenen die daadwerkelijk aan de code werkten.
Markus' bespreking van MVCC en clustering had ook een leuke twist. Zijn toespraak eindigde met een prestatieanalyse van zijn Postgres-R tegen pgpool-II, Postgres-XC en PostgreSQL 9 met behulp van Streaming Replication plus Hot Standby, allemaal gebruikt in clusterconfiguraties om dbt2-testresultaten te versnellen. Ik ben het daar niet helemaal eens met zijn uitgangspunt dat netwerkcongestie de meest vitale clustercomponent is omdat "algemene rekenkracht, geheugen en opslagcapaciteit gemakkelijk kunnen worden geschaald" - dat is niet altijd waar - maar het was bevredigend om te zien dat de PG9 HS/SR pairing is in dat opzicht efficiënt.
De conferentie reserveerde twee sessies om op een relatief ongestructureerde manier over algemene clusteringonderwerpen te praten. De meer verhitte discussie ging over wat PostgreSQL-implementaties in cloud computing-infrastructuur gemakkelijker zou maken. Dat leverde genoeg ideeën op om al twee blogberichten van mijn collega's te genereren.
Een van de ideeën uit die sessie die ik bijzonder interessant vond, was de opmerking dat als je een implementatie hebt waarbij knooppunten worden toegevoegd op de "elastische" manier die mensen leuk vinden om te bespreken met betrekking tot het cloudconcept, is er op dit moment een hiaat in de beheersbaarheid in termen van het gemakkelijk maken voor applicaties om met die knooppuntenset te praten. Als u pgpool-II of pgBouncer tussen uw toepassing en de set knooppunten kunt plaatsen, kunt u op dit moment precies wat zich achter de knooppunten bevindt, abstraheren. Maar nu heb je nog een laag en dus een potentieel knelpunt aan het geheel toegevoegd. Dat is het tegenovergestelde van wat elastische cloudimplementaties zouden moeten zijn:het toevoegen van capaciteit indien nodig met minimaal beheerwerk.
Een voorgestelde oplossingsbenadering was het gemakkelijker maken om een databaserouteringsdirectory op applicatieniveau te bouwen, zodat apps kan gewoon vragen om het type node dat nodig is en er een krijgen om rechtstreeks verbinding mee te maken. Nodes kunnen zichzelf gewoon registreren in de directory wanneer ze online worden gebracht (of worden verwijderd). Dit heeft overeenkomsten met sommige componenten die al rondzweven. Het directory-opzoekgedeelte dat u in LDAP zou kunnen plaatsen; PostgreSQL-servers kunnen zichzelf al aankondigen via ZeroConf AKA Bonjour. Het is niet moeilijk voor te stellen die twee samen te voegen en een applicatielaag te creëren die LDAP-lookups doet, verbonden met een routeringsbackend die beschikbare knooppunten volgt via een willekeurig aantal protocollen. Zoals gewoonlijk zit de duivel in de details. Dingen zoals het timen van mislukte knooppunten, onderscheid maken tussen lees- en schrijfverkeer (pgpool-II doet het door de SQL daadwerkelijk te ontleden, wat duur is), en de resulterende directory-uitzendingen in de cache te plaatsen voor hoge prestaties, terwijl ook cache-invalidatie is, zijn allemaal lastige implementatiedetails om het goed te doen.
Met PostgreSQL 9.0 met meer manieren dan ooit om de database-architectuur op te schalen, gaat dit probleem echter niet weg. Ik weet niet zeker in welke vorm mensen het gaan oplossen, maar het is een veel voorkomend probleem dat het waard is om op te lossen.
