Há tempos atrás, escrevi um tutorial para mostrar como unificar vários bancos de dados em um único banco de dados com vários esquemas. Hoje na lista do PostgreSQL, houve uma dúvida sobre se valia a pena juntar tudo num banco de dados ou manter cada aplicação em um banco de dados diferente no mesmo servidor.
Realmente é difícil justificar o uso de bancos de dados separados. Em geral, utilizar esquemas é sempre mais indicado. Vale a pena lembrar que existem 3 níveis de compartilhamento num mesmo servidor PostgreSQL:
- Cluster, que compartilham a mesma porta, os mesmos processos e a mesma configuração global (postgresql.conf e pg_hba.conf);
- Bancos de Dados, que compartilham o mesmo cluster mas podem ter codificação de caracteres distintos e dependendo da configuração, podem ter usuários distintos (se ‘db_user_namespace’ for configurado como ON);
- Esquemas, que compartilham o mesmo banco de dados;
Em geral, utilizar mais de um banco de dados num mesmo cluster pode ser válido se
- Você precisa ter um ambiente onde o desenvolvedor precise ter poderes plenos num banco de dados de teste sem afetar outras aplicações. Isto é muito incomum, pois é normal você dar permissões para um usuário em um schema específico, mas existem ambientes de testes que podem ser um pouco extremos… Mas se você quiser soltar o desenvolvedor para brincar a vontade no seu servidor, esta pode ser uma opção. Mas jamais faça isso num servidor de produção! O ideal seria instalar o PostgreSQLlocalmente na máquina do usuário ou criar uma máquina virtual com XEN só para isso.
- Em um provedor de serviços onde vários clientes tenham que compartilhar um mesmo servidor PostgreSQL e ao mesmo tempo ter isolação total das contas de usuários esta pode ser uma opção interessante. Vale a pena lembrar de configurar o parâmetro ‘db_user_namespace’ para OFF, opções de memória pequenas para cada banco de dados e de criar um TABLESPACE padrão para cada banco de dados procurando balancear eles entre os discos disponíveis. A partir daí cada cliente poderá colocar as suas várias aplicações em vários esquemas do mesmo banco de dados. É claro que um cliente grande vai querer ter um servidor de banco de dados dedicado, mas para clientes pequenos, isto pode ser uma opção viável.
- Você precisa de ambientes de teste, homologação e/ou produção na mesma máquina. Em geral é melhor deixar seu ambiente de teste em outro servidor. Você vai descobrir que uma única consulta mal feita no ambiente de teste pode sentar todo o servidor… melhor evitar isso a todo o custo! Você também pode criar ambientes isolados em clusters separados e garantir mais recursos para o ambiente de testes ao ambiente de produção e ainda deixar os ambientes mais isolados utilizando portas distintas. Sempre utilize discos separados para o ambiente de produção, mesmo que esteja utilizando um cluster separado ou até mesmo uma máquina virtual XEN. Se você estiver num ambiente de produção mais exigente em termos de I/O, vai descobrir logo que mesmo com discos distintos, o limite de banda do próprio barramento interno do servidor pode se esgotar!
- Você precisa de bancos de dados com codificações de caractere diferentes. Seria ideal você pensar em utilizar utf-8 para todas as bases se você está nesta situação. Mas isto é uma longa conversa, para lá de complicada. Em todo caso, você vai descobrir que terá problemas em manter bases com diferentes codificações de caractere. Há um certo consenso de que o futuro é o UTF-8, e há quem diga que até o Windows vai trabalhar direito com ele um dia.
- Você precisa de configurações de desempenho diferentes para diferentes aplicações (OLTP x BI por exemplo). Bom, você pode fazer isso com esquema também, mas pode não ser tão simples se cada usuário da aplicação possuir uma conta de usuário no banco de dados. No entanto, se você quer levar isto realmente a sério, é melhor criar clusters distintos e melhor ainda, utilizar servidores distintos para cada aplicação. Afinal, você precisa de mais desempenho, não é mesmo?
Conclusão:
Se mais de uma aplicação podem conviver no mesmo servidor e no mesmo cluster, então elas podem estar no mesmo banco de dados. Existem raros casos em que isto não se aplique… mas são exceções e não a regra.
