Indipendentemente dal fatto che tu abbia partecipato o meno alla nostra conferenza CHAR(10) il mese scorso, ora puoi rivivere parte dell'esperienza scaricando le diapositive della conferenza. Alcuni di questi sono stati pubblicati dal vivo durante la conferenza, altri si sono presentati più tardi, ma ora quasi tutto è lì. Purtroppo, la presentazione divertente di Nic Ferrier su come WooMe (acquisito da Zoosk) è stato ampliato utilizzando Londiste e Django non era disponibile in una forma che potevamo facilmente riprodurre. Per quello, sicuramente dovevi essere lì, in più di un modo.
I due discorsi che ho trovato più informativi sono stati gli aggiornamenti sugli stati di pgpool-II e pgmemcache. Entrambi questi strumenti hanno quella combinazione leggermente frustrante di essere davvero utili e un po' poco documentati rispetto a quanto siano complicati (almeno in inglese!), quindi ottenere ulteriori informazioni su di essi da coloro che stanno effettivamente lavorando sul codice è stato fantastico.
Anche la discussione di Markus su MVCC e clustering ha avuto una svolta divertente. Il suo intervento si è concluso con un'analisi delle prestazioni del suo Postgres-R rispetto a pgpool-II, Postgres-XC e PostgreSQL 9 utilizzando Streaming Replication più Hot Standby, tutti utilizzati nelle configurazioni cluster per accelerare i risultati dei test dbt2. Non sono del tutto d'accordo con la sua premessa secondo cui la congestione della rete è la componente più vitale del cluster perché "la potenza di calcolo complessiva, la memoria e la capacità di archiviazione si adattano facilmente" - non è sempre vero - ma è stato soddisfacente vedere che il PG9 HS/SR l'abbinamento è efficiente in questo senso.
La conferenza ha riservato due sessioni per parlare di argomenti generali di raggruppamento in modo relativamente non strutturato. La discussione più accesa ha parlato di cosa renderebbe più facili da gestire le implementazioni di PostgreSQL nell'infrastruttura di cloud computing. Ciò ha suscitato abbastanza idee da generare già due post di blog dai miei colleghi.
Una delle idee di quella sessione che ho trovato particolarmente interessante è stata notare che se si dispone di una distribuzione in cui i nodi vengono aggiunti nel modo "elastico" piace alle persone per discutere in relazione al concetto di cloud, in questo momento c'è un divario di gestibilità in termini di semplificare la comunicazione delle applicazioni con quel set di nodi. Se puoi mettere pgpool-II o pgBouncer tra la tua applicazione e il set di nodi, puoi astrarre esattamente ciò che c'è dietro i nodi in questo momento. Ma ora hai aggiunto un altro livello e quindi un potenziale collo di bottiglia all'intera faccenda. Questo è l'opposto di ciò che dovrebbero essere le distribuzioni di cloud elastici:semplicemente aggiungere capacità secondo necessità con un lavoro di gestione minimo.
Un approccio di soluzione suggerito è stato quello di semplificare la creazione di una directory di instradamento del database a livello di applicazione, in modo che le app può semplicemente chiedere il tipo di nodo necessario e ottenerne uno a cui connettersi direttamente. I nodi possono semplicemente registrarsi nella directory mentre vengono portati online (o rimossi). Questo ha somiglianze con alcuni componenti che stanno già fluttuando. La parte di ricerca della directory che potresti inserire in LDAP; I server PostgreSQL possono già annunciarsi tramite ZeroConf AKA Bonjour. Non è difficile immaginare di collegare questi due insieme, mettendo un livello applicativo che esegue ricerche LDAP connesso a un backend di routing che tiene traccia dei nodi disponibili tramite un numero qualsiasi di protocolli. Come al solito, il diavolo è nei dettagli. Cose come il timeout dei nodi non riusciti, la distinzione tra il traffico di lettura e scrittura (pgpool-II lo fa analizzando effettivamente l'SQL, il che è costoso) e fare in modo che le trasmissioni di directory risultanti vengano memorizzate nella cache per prestazioni elevate mentre presentano anche l'invalidazione della cache sono tutti dettagli di implementazione complicati per andare bene.
Con PostgreSQL 9.0 che offre più modi che mai per scalare l'architettura del database verso l'alto, questo problema non sta scomparendo. Non sono ancora sicuro in quale forma le persone lo risolveranno, ma è un problema abbastanza comune che vale la pena risolverlo.
