É comum aparecer alguém na lista do PostgreSQL perguntando sobre um bom plano de hospedagem para o PostgreSQL. Sei que existem alguns, mas nunca tive a oportunidade de testar um. Na verdade, seria uma boa idéia criar uma lista de provedores!
Então porque estou escrevendo sobre isso? Bom a questão é que hospedar um PostgreSQL não é tão simples assim. Se você está querendo hospedar uma aplicação que faz uso de banco de dados fora da empresa (ou fora da sua casa) é porque você quer se beneficiar com o ganho de escala de uma empresa de hospedagem, ou seja gastar menos com: banda de Internet, manutenção de servidores e segurança da rede. A opção de hospedar uma aplicação fora também tem várias opções com preços bem variados que aumentam geometricamente:
- Hospedagem em servidor compartilhado com acesso FTP;
- Hospedagem em servidor compartilhado com acesso SSH;
- Hospedagem em máquina virtual compartilhada com acesso SSH e root;
- Locação de servidor dedicado;
- Locação de espaço físico Rack, banda de internet e outros serviços em Data Center;
Hospedagem em servidor compartilhado
Se você quer hospedar um blog ou um ou mais sites simples, um serviço de hospedagem com servidor compartilhado deve ser mais do que suficiente. Você não tem que se preocupar com a configuração dos servidores, segurança ou manutenção do servidor. Basta colocar o seu código numa pasta do servidor, criar um banco de dados e pronto. Se você tiver um mínimo de conhecimento com shell, poderá utilizar um acesso via SSH que é muito versátil e seguro. Com 10 dólares por mês, você consegue hospedar um site com milhares de visitas por dia.
E onde entra o banco de dados nisso? Bons provedores de hospedagem em servidores compartilhados possuem bancos de dados em servidores dedicados bem como um servidor de e-mail dedicado, um servidor web dedicado e por aí vai. Porém estes servidores são compartilhados com vários clientes do provedor. Isto significa que você não poderá ter acesso a várias configurações do banco de dados. Mas o pior mesmo é que você não poderá distribuir a carga de I/O do banco de dados em diversos discos. Note que em sites onde a maior parte das operações em banco de dados são de leitura e a maior parte das operações de leitura são executadas sobre as as mesmas páginas – quem já viu estatísticas de acesso de um site, sabe que mais de 90% dos acessos ocorre sobre menos de 10% do conteúdo. Isto significa que o servidor web (que na maior parte dos casos será o nosso amigo Apache) irá cachear estas páginas e o banco de dados irá cachear o resultado das consultas mais frequentes. O resultado disso é que os servidores raramente consultam os seus discos e você tem um site onde o maior gargalo é a velocidade de processamento e a banda de internet disponível.
Se você está utilizando uma aplicação onde a maior parte das operações são de leitura… você provavelmente não precisa do PostgreSQL!!! Já escrevi sobre isso por aqui, e sei que o tema é polêmico, mas o PostgreSQL é um exagero nestes casos. O SQLite seria mais que suficiente. No entanto a maioria dos provedores costuma ter um servidor de MySQL compartilhado e como muitas soluções livres para aplicações web o utilizam… acaba sendo a primeira opção dos projetos web.
Hospedagem em máquinas virtuais
As maquinas virtuais são o pior e o melhor de dois mundos. Você tem a flexibilidade de um servidor dedicado e pode instalar tudo o que você quiser nele, configurando exatamente como você quer. Por outro lado você pode ter recursos de máquina tão limitados ou mais que um servidor compartilhado. Isto significa que um projeto pequeno, mas que não se enquadre num plano de acesso compartilhado padrão pode se encaixar bem neste tipo de plano. Em geral, você também não conseguirá fazer muitos ajustes em bancos de dados em máquinas virtuais, pois você não tem muito controle sobre os discos do servidor. Isto pode variar um pouco de plano para plano. No entanto você pode ajustar os parâmetros de memória do seu servidor da forma com que desejar. Vale lembrar que a memória de um servidor virtual compartilhado costuma ser bem pequena, o que novamente não é uma boa notícia para quem quer utilizar o PostgreSQL. Em ambientes com pouca memória o SQLite e o BDB são opções muito interessantes.
Servidor Dedicado
Bom, não é segredo para nenhum DBA ou SysAdmin (e não deveria ser para nenhum desenvolvedor também) que se você tem um mínimo de preocupação o com desempenho dos seus bancos de dados, você precisa de um servidor dedicado só para o banco de dados. Discos SCSI ou SAS não são opcionais (esqueça definitivamente que existe SATA) e o uso do plural não é casual. Com alguns GB de memória ECC(não vale a pena passar muito de 4GB se você utiliza um SO de 32 bits…) você terá um bom servidor de Banco de Dados. É claro que é possível ser um pouco mais modesto. Se você for muito mais modesto, pode ser que você consiga se virar com um servidor compartilhado. Por outro lado, se você precisar hospedar um Oracle RAC num data center, pode ser que o ganho de escala comece a fazer pouco sentido e valha a pena hospedar tudo dentro da sua empresa.
Se você vai optar por alugar os seus servidores ou vai comprar as suas próprias máquinas dentro de um data center a decisão é sua. Em todo caso, vale a pena realizar alguns testes para saber se você realmente precisa de um servidor dedicado. Testes de carga são difíceis de se fazer, mas quando você está prestes a lançar mão de um orçamento considerável para hospedar alguns servidores dedicados, vale a pena fazer algumas considerações para ver se um bom servidor compartilhado não lhe atende.
Particularmente, eu acredito que aplicações com muita escrita em banco de dados se sentem mais a vontade quando guardados dentro da sua empresa e perto dos olhos do seu DBA. Se você estiver falando de dados confidenciais, então fique longe de Data Centers. Lembre-se que ao fim e ao cabo, quem tem acesso físico ao servidor sempre tem acesso aos dados. O ganho de escala, neste momento, está limitado principalmente a banda de internet, já que num servidor de dicado você tem que arcar com o equipamento e com a manutenção do SO e SGDB. Já ouvi falar de algumas empresas que tem seus negócios completamente hospedados fora, mas também já ouvi falar de roubo de informações confidenciais. No entanto, uma aplicação de Supply Chain, por exemplo, podem se uma boa pedida para um data center respeitável.
Conclusão
Quando você decide por hospedar um banco de dados fora da sua companhia, é fundamental conhecer bem quais as opções de mercado e o que se pode esperar destas soluções em termos de escalabilidade, segurança e desempenho:
- Utilize um serviço que lhe permita crescer sem transtornos. As demandas sempre crescem e você não vai querer ficar trocando de provedor a cada vez que precisar de mais recursos de sistema. Fique sempre atento a opções de memória e discos se o desempenho do banco de dados for um fator importante para você;
- Faça uma boa pesquisa sobre a confiabilidade da empresa que você pretende contratar. Se vai armazenar dados que são relativamente sigilosos, triplique os esforços neste sentido. Conheça bem as opções de backup e SLA do provedor antes de fechar negócio;
- Conheça a sua aplicação e saiba como ela utiliza o banco de dados. Quanto mais leve for a demanda sobre o banco de dados, mais compensador será hospedar fora. Se o desempenho do banco de dados for um gargalo, então um estudo mais minucioso com testes de carga são recomendados. As aplicações web, tradicionalmente não utilizam muita escrita ou consultas complexas, o que pode lhe deixar menos preocupado com isso. Mas isso tem mudado muito nos últimos anos, com aplicações web cada vez mais complexas. Neste caso avalie se realmente vale a pena hospedar os seus SGBS fora.
