Unabhängig davon, ob Sie es letzten Monat zu unserer CHAR(10)-Konferenz geschafft haben oder nicht, können Sie jetzt einen Teil der Erfahrung noch einmal erleben, indem Sie die Konferenzfolien herunterladen. Einige davon wurden während der Konferenz live gepostet, andere tauchten später auf, aber jetzt ist fast alles da. Leider war Nic Ferriers unterhaltsame Präsentation darüber, wie WooMe (übernommen von Zoosk) mit Londiste und Django hochskaliert wurde, nicht in einer Form verfügbar, die wir leicht wiedergeben konnten. Dafür mussten Sie auf jeden Fall dabei sein, in mehr als einer Hinsicht.
Die beiden Vorträge, die ich am informativsten fand, waren die Updates zu den Zuständen von pgpool-II und pgmemcache. Diese beiden Tools haben diese etwas frustrierende Kombination aus wirklich nützlichen und im Verhältnis zu ihrer Komplexität (zumindest auf Englisch!) etwas unzureichend dokumentierten, daher war es großartig, zusätzliche Einblicke in sie von denen zu bekommen, die tatsächlich am Code arbeiten.
Markus Diskussion über MVCC und Clustering hatte auch eine lustige Wendung. Sein Vortrag endete mit einer Leistungsanalyse seines Postgres-R im Vergleich zu pgpool-II, Postgres-XC und PostgreSQL 9 unter Verwendung von Streaming Replication plus Hot Standby, die alle in Cluster-Konfigurationen verwendet werden, um die dbt2-Testergebnisse zu beschleunigen. Ich stimme seiner Prämisse dort nicht ganz zu, dass Netzwerküberlastung die wichtigste Cluster-Komponente ist, weil „die gesamte Rechenleistung, der Arbeitsspeicher und die Speicherkapazität leicht skalieren“ – das stimmt nicht immer –, aber es war befriedigend zu sehen, dass das PG9 HS/SR Pairing ist in dieser Hinsicht effizient.
Die Konferenz hat zwei Sitzungen vorgesehen, um auf relativ unstrukturierte Weise über allgemeine Clustering-Themen zu sprechen. In der hitzigeren Diskussion ging es darum, was PostgreSQL-Bereitstellungen in Cloud-Computing-Infrastrukturen einfacher handhabbar machen würde. Das hat genug Ideen geweckt, um bereits zwei Blog-Einträge von meinen Kollegen zu generieren.
Eine der Ideen aus dieser Sitzung, die ich besonders interessant fand, war die Feststellung, dass bei einer Bereitstellung, bei der Knoten auf die „elastische“ Art und Weise hinzugefügt werden, die die Leute mögen Um in Bezug auf das Cloud-Konzept zu diskutieren, gibt es dort derzeit eine Verwaltbarkeitslücke, wenn es darum geht, Anwendungen die Kommunikation mit diesem Knotensatz zu erleichtern. Wenn Sie pgpool-II oder pgBouncer zwischen Ihre Anwendung und die Gruppe von Knoten setzen können, können Sie genau das abstrahieren, was sich jetzt ein wenig hinter den Knoten befindet. Aber jetzt haben Sie dem Ganzen eine weitere Ebene und damit einen potenziellen Engpass hinzugefügt. Das ist das Gegenteil von dem, worum es bei elastischen Cloud-Bereitstellungen gehen sollte:einfach Kapazität nach Bedarf mit minimalem Verwaltungsaufwand hinzuzufügen.
Ein vorgeschlagener Lösungsansatz bestand darin, den Aufbau eines Datenbank-Routing-Verzeichnisses auf Anwendungsebene zu erleichtern, sodass Apps Sie können einfach nach dem benötigten Knotentyp fragen und einen erhalten, mit dem Sie sich direkt verbinden können. Knoten können sich einfach selbst im Verzeichnis registrieren, wenn sie online geschaltet (oder heruntergefahren) werden. Dies hat Ähnlichkeiten mit einigen Komponenten, die bereits herumschwirren. Den Verzeichnissuchteil, den Sie möglicherweise in LDAP einfügen; PostgreSQL-Server können sich bereits über ZeroConf AKA Bonjour anmelden. Es ist nicht schwer vorstellbar, diese beiden miteinander zu verbinden und eine Anwendungsschicht, die LDAP-Lookups durchführt, mit einem Routing-Backend zu verbinden, das verfügbare Knoten über eine beliebige Anzahl von Protokollen verfolgt. Wie so oft steckt der Teufel im Detail. Dinge wie das Timeout von ausgefallenen Knoten, die Unterscheidung zwischen Lese- und Schreibverkehr (pgpool-II tut dies, indem es das SQL tatsächlich analysiert, was teuer ist) und das Zwischenspeichern der resultierenden Verzeichnis-Broadcasts für hohe Leistung bei gleichzeitiger Cache-Invalidierung sind alles knifflige Implementierungsdetails um es richtig zu machen.
Da PostgreSQL 9.0 mehr Möglichkeiten als je zuvor bietet, die Datenbankarchitektur nach oben zu skalieren, wird dieses Problem jedoch nicht verschwinden. Ich bin mir noch nicht sicher, in welcher Form die Leute es lösen werden, aber es ist ein so häufiges Problem, dass es sich lohnt, es zu lösen.
