Independentemente de você ter participado ou não da nossa conferência CHAR(10) no mês passado, agora você pode reviver parte da experiência baixando os slides da conferência. Alguns deles foram postados ao vivo durante a conferência, alguns apareceram mais tarde, mas quase tudo está lá agora. Infelizmente, a apresentação divertida de Nic Ferrier sobre como o WooMe (adquirido pela Zoosk) foi ampliado usando Londiste e Django não estava disponível em uma forma que pudéssemos reproduzir facilmente. Para isso, você certamente tinha que estar lá, em mais de uma maneira.
As duas palestras que achei mais informativas foram as atualizações sobre os estados do pgpool-II e do pgmemcache. Ambas as ferramentas têm aquela combinação um pouco frustrante de serem realmente úteis e um pouco subdocumentadas em relação ao quão complicadas elas são (pelo menos em inglês!), então obter informações adicionais sobre elas daqueles que realmente trabalham no código foi ótimo.
A discussão de Markus sobre MVCC e clustering também teve um toque divertido. Sua palestra terminou com uma análise de desempenho de seu Postgres-R contra pgpool-II, Postgres-XC e PostgreSQL 9 usando Streaming Replication mais Hot Standby, todos usados ​​em configurações de cluster para acelerar os resultados dos testes dbt2. Eu não concordo muito com sua premissa de que o congestionamento de rede é o componente de cluster mais vital porque “o poder geral de computação, memória e capacidade de armazenamento são dimensionados facilmente” – isso nem sempre é verdade – mas foi satisfatório ver que o PG9 HS/SR o emparelhamento é eficiente nesse sentido.
A conferência reservou duas sessões para falar sobre tópicos gerais de agrupamento de maneira relativamente não estruturada. A discussão mais acalorada falou sobre o que tornaria as implantações do PostgreSQL na infraestrutura de computação em nuvem mais fáceis de lidar. Isso despertou ideias suficientes para gerar duas entradas de blog de meus colegas de trabalho.
Uma das ideias dessa sessão que achei particularmente interessante foi notar que, se você tiver uma implantação em que os nós são adicionados da maneira “elástica”, as pessoas gostam para discutir em relação ao conceito de nuvem, há uma lacuna de gerenciamento agora em termos de facilitar para os aplicativos se comunicarem com esse conjunto de nós. Se você pode colocar pgpool-II ou pgBouncer entre seu aplicativo e o conjunto de nós, você pode abstrair exatamente o que está por trás dos nós agora. Mas agora você adicionou outra camada e, portanto, um gargalo potencial para a coisa toda. Isso é o oposto do que as implantações de nuvem elástica deveriam ser:apenas adicionar capacidade conforme necessário com o mínimo de trabalho de gerenciamento.
Uma abordagem de solução sugerida foi facilitar a criação de um diretório de roteamento de banco de dados no nível do aplicativo, para que os aplicativos pode apenas pedir o tipo de nó necessário e obter um para se conectar diretamente. Os nós podem simplesmente se registrar no diretório à medida que são colocados online (ou são retirados). Isso tem semelhanças com alguns componentes que já estão flutuando. A parte de pesquisa de diretório que você pode colocar no LDAP; Os servidores PostgreSQL já podem se anunciar via ZeroConf AKA Bonjour. Não é difícil imaginar juntar esses dois, colocando uma camada de aplicativo que faz pesquisas LDAP conectadas a um back-end de roteamento que rastreia os nós disponíveis por meio de qualquer número de protocolos. Como sempre, o diabo está nos detalhes. Coisas como o tempo limite de nós com falha, a distinção entre o tráfego de leitura e gravação (o pgpool-II faz isso analisando o SQL, o que é caro) e tornando as transmissões de diretório resultantes armazenadas em cache para alto desempenho, além de apresentar invalidação de cache, são todos detalhes de implementação complicados para acertar.
Com o PostgreSQL 9.0 apresentando mais maneiras do que nunca de escalar a arquitetura de banco de dados, esse problema não está desaparecendo. Ainda não tenho certeza de que forma as pessoas vão resolvê-lo, mas é um problema comum o suficiente que vale a pena resolver.