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,
- 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.
- 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?
- qualquer solução, comentário, abordagem, sugestão são bem-vindos e apreciados.
Você ganhará muito mais em relação ao desempenho se mover a mesa para um disco rígido diferente . Contanto que a tabela "ocupada" e o restante estejam localizados no mesmo disco, mover essa tabela para um "arquivo" diferente (movendo-a para um banco de dados diferente) não mudará nada em relação ao desempenho (E/S) .
Distribuir a carga de I/O para um disco rígido diferente (e um controlador de disco rígido diferente) provavelmente dará a você um melhor desempenho para os dados restantes porque não é afetado pelo I/O feito na tabela ocupada.
Para mover a tabela para um disco rígido diferente, você precisa criar um novo espaço de tabela (que obviamente está localizado nesse disco) e então mover essa tabela para esse espaço de tabela.
Acho que, neste caso, é melhor otimizar a E/S em geral e tentar garantir que você tenha muita RAM no servidor do que mover as tabelas para outro tablespace. Se as tabelas forem acessadas com mais frequência e houver memória suficiente, elas provavelmente serão mantidas na memória e o WAL é o único arquivo liberado para o disco na confirmação de qualquer maneira.
Mais memória fará mais diferença. As páginas acessadas com frequência terão maior probabilidade de estar na fila e, portanto, a E/S de disco será reduzida. Esse é o grande.
A criação de tablespaces adicionais também pode criar outros problemas. Se eles estiverem em outras matrizes RAID, você está dividindo sua vazão total entre as duas matrizes e, portanto, tudo será mais lento. Por outro lado, se você adicionar RAM, haverá menos E/S de disco em primeiro lugar.