PostgreSQL para transações de alto volume e para data warehousing

Sou bastante novo no PostgreSQL, nunca fiz uma grande implantação usando-o antes. Mas tenho uma boa experiência em soluções corporativas e quero tentar aplicar um pouco do que aprendi usando o PostgreSQL.

Eu tenho um site dimensionado para lidar com grande número de dados e tráfego. A infraestrutura será construída usando a Amazon (AWS) usando instâncias EC2 e volumes EBS.

O design deve ter dois bancos de dados, um banco de dados transacional principal e um armazém de dados para lidar com análises e relatórios.

Banco de dados transacional principal

será usado para o site ao vivo, o site é construído em vários nós para aumentar a escala de usuários simultâneos. Principalmente exigimos que o banco de dados para esse caso seja extremamente rápido nas operações de leitura, esperamos> 100 GB de dados com 30% de crescimento anual. Neste ponto, planejamos usar dois servidores EC2 ( e adicionar mais tarde, conforme necessário ).

minha pergunta, qual é a configuração recomendada para os requisitos acima? Além disso, existe uma maneira de gerenciar o particionamento de tabela e volume? existem recomendações para o uso da configuração da AWS?

Banco de dados do armazém de dados

Será usado principalmente para capturar todos os dados do banco de dados transacional principal na dimensão de tempo. portanto, mesmo os registros excluídos do banco de dados principal serão capturados no DWH. Portanto, os dados serão muito grandes e o crescimento será ainda maior. Também usaremos algumas instâncias do EC2 ou mais, se necessário.

Qual é a configuração recomendada neste caso? isso exigirá operação de gravação rápida devido à gravação constante (ETL). Podemos construir cubos OLAP no PostgreSQL? se sim, alguém lá fora tentou?

Conectando ao banco de dados

Os servidores da web estarão se conectando ao banco de dados principal para consultar e gravar. No momento, estamos desenvolvendo um aplicativo usando o django, que usa a biblioteca nativa para conexão. É recomendável usar o mesmo método básico? ou devemos configurar o pgpool?

Armazém de dados (ETL)

Qual é a maneira recomendada para criar processos de ETL para ler do principal e carregar no data warehouse? Alguma ferramenta? metodologia a seguir? O PostgreSQL oferece funções / ferramentas úteis na construção de processos ETL?

Serviços de infraestrutura / banco de dados

Você provavelmente deve ler isso para obter uma visão geral de um site de alto volume que é executado na AWS com EBS. Eles mudaram para o armazenamento efêmero, mas tiveram que criar alguma redundância para poder (re) armazenar os dados.

http://blog.reddit.com/2012/01/january-2012-state-of-servers.html

Data Warehouse / ETL

Eu usei o Pentaho no passado. Não diretamente no postgres, mas achei uma boa solução para OLAP (Mondrian) e ETL (Kettle)

http://www.pentaho.com/

edit: "Edições da comunidade" podem ser encontradas aqui

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

Conexão

Essas pessoas parecem realmente gostar do pgbouncer. /programming/1125504/django-persistent-database-connection

Eu não tenho experiência com isso, no entanto. Aparentemente, o Disqus o usa.

Sua configuração é semelhante à que eu desenvolvi para uma universidade. O banco de dados não era enorme, mas bastante grande, com cerca de 300 GB de tamanho e a maior tabela continha cerca de 500 milhões de registros. E ainda está crescendo.

Para o efeito, foram utilizados dois servidores realmente robustos (ferro real, não virtualizado), um dedicado ao tratamento de dados de um site e o outro usado para cálculos e análises estatísticas. Os dados foram replicados em ambas as direções usando o Slony. Os dados OLTP foram replicados para o servidor OLAP continuamente e alguns esquemas e tabelas únicas foram replicados do servidor OLAP para o OLTP. Dessa maneira, cálculos pesados ​​poderiam ser executados no servidor de análise sem afetar o servidor OLTP. Atualmente, existem algumas alternativas ao Slony para replicar dados: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony foi bom e rápido para a nossa preocupação, mas pode ser duro professor.

Como o servidor OLAP cresce constantemente, considere usar algum tipo de particionamento, se aplicável.

Se tiver a possibilidade, use o pool de conexão. Eu só usei o PgPool e funcionou perfeitamente. PgBouncer é outra opção. Além de reduzir a latência init, também reduz a inicialização e o gerenciamento da sessão. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Outro benefício do uso de um conjunto de conexões é que você tem um único ponto em que pode redirecionar facilmente seu tráfego (isso também pode ser um risco).

Não usei nenhum ETL pronto para carregar dados no servidor OLAP. Eu escrevi meu próprio script em Python, pois alguns dados foram entregues em grandes arquivos de texto com um formato peculiar.

A estrutura do banco de dados precisa ser cuidadosamente considerada. Usar esquemas é bom para reunir e facilitar o manuseio de objetos. Pode parecer complicado, para começar, usar esquemas, mas à medida que o número de objetos aumenta, você se agradece. Sabendo que você deve prefixar explicitamente os objetos com o esquema deles, você sabe exatamente em quais objetos você opera. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Para os mais ousados, o PostgreSQL XC é uma alternativa interessante ou apenas uma fantasia de tamanho grande http://postgres-xc.sourceforge.net/