Ya sea que asistiera o no a nuestra conferencia CHAR(10) el mes pasado, ahora puede revivir parte de la experiencia descargando las diapositivas de la conferencia. Algunos de ellos se publicaron en vivo durante la conferencia, algunos aparecieron más tarde, pero casi todo está allí ahora. Lamentablemente, la entretenida presentación de Nic Ferrier sobre cómo se amplió WooMe (adquirida por Zoosk) usando Londiste y Django no estaba disponible en una forma que pudiéramos reproducir fácilmente. Para eso, ciertamente tenías que estar allí, en más de un sentido.
Las dos charlas que encontré más informativas fueron las actualizaciones sobre los estados de pgpool-II y pgmemcache. Ambas herramientas tienen esa combinación ligeramente frustrante de ser realmente útiles y un poco infradocumentadas en relación con lo complicadas que son (¡al menos en inglés!), por lo que obtener información adicional sobre ellas de parte de quienes realmente trabajan en el código fue excelente.
La discusión de Markus sobre MVCC y agrupamiento también tuvo un giro divertido. Su charla terminó con un análisis de rendimiento de su Postgres-R frente a pgpool-II, Postgres-XC y PostgreSQL 9 utilizando Streaming Replication más Hot Standby, todos utilizados en configuraciones de clúster para acelerar los resultados de las pruebas de dbt2. No estoy del todo de acuerdo con su premisa de que la congestión de la red es el componente más importante del clúster porque "la potencia de cómputo general, la memoria y la capacidad de almacenamiento escalan fácilmente", eso no siempre es cierto, pero fue satisfactorio ver que el PG9 HS/SR el emparejamiento es eficiente en ese sentido.
La conferencia reservó dos sesiones para hablar sobre temas generales de agrupamiento de una manera relativamente no estructurada. La discusión más acalorada habló sobre qué haría que las implementaciones de PostgreSQL en la infraestructura de computación en la nube fueran más fáciles de manejar. Eso generó suficientes ideas para generar dos entradas de blog de mis compañeros de trabajo.
Una de las ideas de esa sesión que encontré particularmente interesante fue señalar que si tiene una implementación donde los nodos se agregan en la forma "elástica" a la gente le gusta para discutir en relación con el concepto de nube, hay una brecha de manejabilidad en este momento en términos de facilitar que las aplicaciones se comuniquen con ese conjunto de nodos. Si puede colocar pgpool-II o pgBouncer entre su aplicación y el conjunto de nodos, puede abstraer un poco exactamente lo que hay detrás de los nodos en este momento. Pero ahora ha agregado otra capa y, por lo tanto, un cuello de botella potencial para todo. Eso es lo contrario de lo que se supone que son las implementaciones de nube elástica:simplemente agregar capacidad según sea necesario con un trabajo de administración mínimo.
Un enfoque de solución sugerido fue facilitar la creación de un directorio de enrutamiento de base de datos a nivel de aplicación, puede simplemente preguntar por el tipo de nodo necesario y obtener uno para conectarse directamente. Los nodos pueden simplemente registrarse en el directorio a medida que se ponen en línea (o se eliminan). Esto tiene similitudes con algunos componentes que ya están flotando. La parte de búsqueda de directorio que puede poner en LDAP; Los servidores PostgreSQL ya pueden anunciarse a través de ZeroConf AKA Bonjour. No es difícil imaginar unir esos dos, colocando una capa de aplicación que realiza búsquedas LDAP conectadas a un backend de enrutamiento que rastrea los nodos disponibles a través de cualquier cantidad de protocolos. Como de costumbre, el diablo está en los detalles. Cosas como el tiempo de espera de los nodos fallidos, distinguir entre el tráfico de lectura y escritura (pgpool-II lo hace al analizar el SQL, lo cual es costoso) y hacer que las difusiones de directorio resultantes se almacenen en caché para un alto rendimiento al mismo tiempo que presenta la invalidación de caché son detalles de implementación complicados. para hacerlo bien.
Con PostgreSQL 9.0 presentando más formas que nunca de escalar hacia arriba la arquitectura de la base de datos, este problema no va a desaparecer. Todavía no estoy seguro de qué forma la gente lo resolverá, pero es un problema bastante común que vale la pena resolver.
