Uanset om du gjorde det til vores CHAR(10)-konference i sidste måned, kan du nu genopleve en del af oplevelsen ved at downloade konferencens slides. Nogle af dem blev sendt live under konferencen, nogle dukkede op senere, men næsten alt er der nu. Desværre var Nic Ferriers underholdende præsentation om, hvordan WooMe (erhvervet af Zoosk) blev opskaleret ved hjælp af Londiste, og Django var ikke tilgængelig i en form, som vi nemt kunne afspille. For den ene skulle du helt sikkert være der, på mere end én måde.
De to foredrag, jeg fandt de mest informative, var opdateringerne om tilstandene pgpool-II og pgmemcache. Begge disse værktøjer har den lidt frustrerende kombination af at være virkelig nyttige og en smule underdokumenterede i forhold til, hvor komplicerede de er (i hvert fald på engelsk!), så det var fantastisk at få yderligere indsigt i dem fra dem, der rent faktisk arbejder på koden.
Markus' diskussion om MVCC og clustering havde også et sjovt twist. Hans foredrag sluttede med en præstationsanalyse af hans Postgres-R mod pgpool-II, Postgres-XC og PostgreSQL 9 ved hjælp af Streaming Replication plus Hot Standby, alle brugt i klyngekonfigurationer til at accelerere dbt2-testresultater. Jeg er ikke helt enig i hans præmis der om, at netværksoverbelastning er den mest vitale klyngekomponent, fordi "samlet computerkraft, hukommelse og lagerkapacitet nemt skaleres" - det er ikke altid sandt - men det var tilfredsstillende at se, at PG9 HS/SR parring er effektivt i den henseende.
Konferencen afsatte to sessioner til at tale om generelle klyngeemner på en relativt ustruktureret måde. Den mere ophedede diskussion talte om, hvad der ville gøre PostgreSQL-implementeringer i cloud computing-infrastruktur nemmere at håndtere. Det skabte nok ideer til allerede at generere to blogindlæg fra mine kolleger.
En af ideerne fra den session, jeg fandt særligt interessant, var at bemærke, at hvis du har en implementering, hvor noder tilføjes på den "elastiske" måde, folk kan lide. at diskutere i forhold til cloud-konceptet, er der et håndterbarhedshul der lige nu i forhold til at gøre det nemt for applikationer at tale med det nodesæt. Hvis du kan sætte pgpool-II eller pgBouncer mellem din applikation og sættet af noder, kan du abstrahere præcis det, der er bag noderne lidt lige nu. Men nu har du tilføjet endnu et lag og derfor en potentiel flaskehals til det hele. Det er det modsatte af, hvad elastiske cloud-implementeringer formodes at handle om:blot tilføjelse af kapacitet efter behov med minimalt ledelsesarbejde.
En løsningstilgang, der blev foreslået, var at gøre det nemmere at opbygge en database-routing-mappe på applikationsniveau, så apps kan bare bede om den nødvendige type node og få en til at oprette direkte forbindelse til. Noder kan bare registrere sig selv til biblioteket, efterhånden som de bringes online (eller bliver fjernet). Dette har ligheder med nogle komponenter, der allerede flyder rundt. Biblioteksopslagsdelen, som du måske lægger i LDAP; PostgreSQL-servere kan allerede annoncere sig selv via ZeroConf AKA Bonjour. Det er ikke svært at forestille sig at bolte disse to sammen, sætte et applikationslag, der udfører LDAP-opslag forbundet med en routing-backend, der sporer tilgængelige noder via et vilkårligt antal protokoller. Som sædvanlig er djævelen i detaljerne. Ting som at time-out mislykkede noder, skelne mellem læse- og skrivetrafik (pgpool-II gør det ved faktisk at parse SQL, hvilket er dyrt), og at gøre de resulterende mappeudsendelser cachelagret for høj ydeevne, mens de også byder på cache-invalidering, er alle vanskelige implementeringsdetaljer for at komme rigtigt.
Med PostgreSQL 9.0, der byder på flere måder end nogensinde før til at skalere opadgående databasearkitektur, forsvinder dette problem dog ikke. Jeg er ikke sikker på, hvilken form folk endnu vil løse det i, men det er et almindeligt nok problem til, at det er værd at løse.
