Que vous ayez participé ou non à notre conférence CHAR(10) le mois dernier, vous pouvez maintenant revivre une partie de l'expérience en téléchargeant les diapositives de la conférence. Certains d'entre eux ont été affichés en direct pendant la conférence, certains sont apparus plus tard, mais presque tout est là maintenant. Malheureusement, la présentation divertissante de Nic Ferrier sur la façon dont WooMe (acquis par Zoosk) a été agrandie à l'aide de Londiste et Django n'était pas disponible sous une forme que nous pourrions facilement rejouer. Pour celui-là, vous deviez certainement être là, à plus d'un titre.
Les deux présentations que j'ai trouvées les plus instructives étaient les mises à jour sur les états de pgpool-II et de pgmemcache. Ces deux outils ont cette combinaison légèrement frustrante d'être vraiment utiles et un peu sous-documentés par rapport à leur complexité (en anglais du moins !), donc obtenir des informations supplémentaires sur eux de la part de ceux qui travaillent réellement sur le code était génial.
La discussion de Markus sur le MVCC et le clustering avait également une tournure amusante. Son exposé s'est terminé par une analyse des performances de son Postgres-R par rapport à pgpool-II, Postgres-XC et PostgreSQL 9 à l'aide de Streaming Replication plus Hot Standby, tous utilisés dans les configurations de cluster pour accélérer les résultats des tests dbt2. Je ne suis pas tout à fait d'accord avec sa prémisse selon laquelle la congestion du réseau est le composant le plus vital du cluster car "la puissance de calcul globale, la mémoire et la capacité de stockage évoluent facilement" - ce n'est pas toujours vrai - mais c'était satisfaisant de voir que le PG9 HS/SR l'appariement est efficace à cet égard.
La conférence a réservé deux sessions pour parler de sujets généraux de clustering de manière relativement peu structurée. La discussion la plus animée a porté sur ce qui rendrait les déploiements de PostgreSQL dans l'infrastructure de cloud computing plus faciles à gérer. Cela a suscité suffisamment d'idées pour générer déjà deux entrées de blog de la part de mes collègues.
L'une des idées de cette session que j'ai trouvée particulièrement intéressante était de noter que si vous avez un déploiement dans lequel les nœuds sont ajoutés de manière "élastique", les gens aiment pour en discuter par rapport au concept de cloud, il existe actuellement un écart de gérabilité en termes de facilité pour les applications de communiquer avec cet ensemble de nœuds. Si vous pouvez mettre pgpool-II ou pgBouncer entre votre application et l'ensemble de nœuds, vous pouvez résumer un peu exactement ce qui se cache derrière les nœuds en ce moment. Mais maintenant, vous avez ajouté une autre couche et donc un goulot d'étranglement potentiel à l'ensemble. C'est à l'opposé de ce que sont censés être les déploiements cloud élastiques :il suffit d'ajouter de la capacité selon les besoins avec un travail de gestion minimal.
Une approche de solution suggérée consistait à faciliter la création d'un répertoire de routage de base de données au niveau de l'application, afin que les applications peut simplement demander le type de nœud nécessaire et en obtenir un auquel se connecter directement. Les nœuds peuvent simplement s'enregistrer dans l'annuaire au fur et à mesure qu'ils sont mis en ligne (ou supprimés). Cela présente des similitudes avec certains composants qui flottent déjà. La partie de recherche d'annuaire que vous pourriez mettre dans LDAP ; Les serveurs PostgreSQL peuvent déjà s'annoncer via ZeroConf AKA Bonjour. Il n'est pas difficile d'imaginer assembler ces deux éléments, en mettant une couche d'application qui effectue des recherches LDAP connectées à un backend de routage qui suit les nœuds disponibles via un nombre quelconque de protocoles. Comme d'habitude, le diable est dans les détails. Des choses comme l'expiration des nœuds défaillants, la distinction entre le trafic de lecture et d'écriture (pgpool-II le fait en analysant réellement le SQL, ce qui est coûteux) et la mise en cache des diffusions de répertoire résultantes pour des performances élevées tout en présentant également l'invalidation du cache sont tous des détails d'implémentation délicats. pour faire le bon choix.
Avec PostgreSQL 9.0 offrant plus de moyens que jamais pour faire évoluer l'architecture de la base de données, ce problème ne disparaît pas pour autant. Je ne sais pas encore sous quelle forme les gens vont le résoudre, mais c'est un problème assez courant qui mérite d'être résolu.
