Gnanam's questions

Em continuação a uma pergunta postada por mim em É uma boa ideia mover tabelas de alto volume e altamente acessadas para um banco de dados separado? , estou procurando diferentes técnicas/soluções disponíveis para arquivamento de banco de dados no PostgreSQL.

Poucas soluções que posso pensar são:

1. Particionamento de tabela
2. Espaço de tabela e/ou esquema separado
3. Movendo registros/tabelas arquivados para um disco rígido diferente

Quaisquer outras sugestões/dicas/soluções são muito bem-vindas e apreciadas.

NOTA: Estamos executando o PostgreSQL v9.1.3 no CentOS5.2

Nosso aplicativo é baseado na web (criado em arquitetura multilocatário ) executando o PostgreSQL v9.1.3. Existem cerca de 450 tabelas em nosso aplicativo, das quais 2 a 3 tabelas, específicas para um módulo no aplicativo, possuem um grande volume de registros armazenados em comparação com outras tabelas restantes e são fortemente acessadas (operações de leitura e gravação ) pelos usuários do aplicativo .

Para dar uma ideia/estatística do volume de registros disponíveis, atualmente existem 8 milhões de registros em uma tabela e 3 milhões de registros em outra tabela. Esperamos um aumento/tráfego imediato no volume de transações (novamente, transações de leitura e gravação ) para essas tabelas em um futuro próximo, pois estamos apresentando alguns recursos interessantes neste módulo específico.

Minha pergunta com requisitos são,

1. como estamos esperando um grande tráfego para este módulo específico, não queremos que os usuários que acessam outros módulos no aplicativo sejam afetados devido a quaisquer problemas de desempenho que isso possa causar.
2. separar/isolar tabelas fortemente acessadas é uma solução que surgiu na minha cabeça. É uma boa ideia separar/mover para um banco de dados diferente? Quais são os prós e os contras dessa abordagem?
3. qualquer solução, comentário, abordagem, sugestão são bem-vindos e apreciados.

Nosso servidor de produção está executando o PostgreSQL v8.2.3 no CentOS5.2. Estamos planejando atualizar para a versão mais recente da série 8.2, que é a v8.2.20 . Além disso, no futuro, planejamos atualizar para a versão secundária mais recente o mais rápido possível (como e quando lançado pelo PostgreSQL).

Inicialmente, instalamos a v8.2.3 da fonte. O PostgreSQL é instalado em /usr/local/pgsql/ e o diretório de dados está disponível em /usr/local/pgsql/data

A política de controle de versão do PostgreSQL diz:

A atualização para uma versão secundária não requer um despejo e restauração; simplesmente interrompa o servidor de banco de dados, instale os binários atualizados e reinicie o servidor.

Agora, sem um despejo/restauração, quais são as formas/etapas recomendadas envolvidas na atualização do PostgreSQL para a versão mais recente para versões secundárias?

EDIT: Bem, eu deveria ter feito minha pergunta dessa maneira. Como o documento diz install the updated binaries, minha pergunta é se a versão mais recente pode ser instalada como está. Meu diretório de dados /usr/local/pgsql/data/ será perturbado de alguma forma? Ou esse diretório de dados deve ser movido temporariamente até que a instalação mais recente seja concluída. Além disso, há algo que, como administrador, eu precise tomar cuidado, como fazer um backup de /usr/local/pgsql/data/postgresql.conf , etc.?

Estamos usando o PostgreSQL v8.2.3.

Existem tabelas envolvidas: EMPLOYEE e EMAILLIST .

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2 tabelas são unidas de tal forma que, se EMPLOYEE.EMAIL1 ou EMPLOYEE.EMAIL2 não tiverem uma entrada correspondente, essas linhas serão retornadas.

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

A coluna EMAILque é varchar(256) da EMAILLISTtabela é indexada. Agora, o tempo de resposta é de 14 segundos.

Estatísticas de contagem de tabelas: Atualmente, EMPLOYEE tem 165.018 registros e EMAILLIST tem 1.810.228 registros, e espera-se que ambas as tabelas cresçam no futuro.

1. É uma boa ideia/abordagem indexar uma coluna VARCHAR? Esta questão imediatamente me veio à mente devido ao motivo pelo qual não indexamos uma coluna VARCHAR antes em nosso aplicativo. Os conselhos/sugestões de especialistas sobre isso são muito apreciados.
2. Com essa consulta e índice atuais, o tempo de resposta de 14 segundos é razoável ou há espaço para ajustes adicionais? Quais são as experiências/opiniões em tempo real de outros usuários com base nesse tipo de tamanho de tabela e tempo de resposta?

NOTA: Meu requisito/caso de uso real é explicado em detalhes aqui .