Uma sugestão de arquitetura para poder crescer linearmente sem limites
A maior comodidade e simplicidade para a equipe de TI em se manter apenas uma base de dados central em empresas de médio a grande porte tem se mostrado um pesadelo para quem está no final da linha, o usuário dos sistemas.
Não dá para crescer a quantidade de serviços oferecidos tendo-se uma arquitetura centralizada, inevitavelmente a lentidão uma hora ou outra vai aparecer e os transtornos causados serão imensuráveis.
No mês de janeiro tivemos notícias de problemas no sistema do Detran do Estado de São Paulo (http://www.agora.uol.com.br/saopaulo/ult10103u1033262.shtml).
No final de janeiro, mais especificamente no dia 30 procurei uma loja da Vivo para correção de uma conta telefônica, onde haviam sido debitados 5 pacotes de 90 minutos, algum erro de operação, etc. Fiquei la aguardando uns 15 minutos e de repente fomos informados que o sistema “caiu” e que não havia nenhuma previsão de volta, e que alias segundo o funcionário da loja, o sistema vinha estado assim instável desde a virada do ano, ou seja, quase 30 dias de problemas, eu não consigo nem imaginar o transtorno que isso tem causado para uma grande empresa como a Vivo.
Certa vez um consultor que presta serviços de TI para a Vivo comentou comigo que a Vivo seria um excelente cliente para nosso produto (ObjectMMRS), mas que seria impossível implantar nosso produto lá porque nosso produto utiliza trigger para a coleta de log / fila. Segundo ele a máquina principal da base de dados central era tão sobrecarregada que se uma trigger fosse criada travaria tudo.
Fiquei um bom tempo refletindo, o que será mais nocivo ? Uma empresa que concentra todos os seus negócios e conhecimento em uma única base de dados ou uma trigger para coletar log / fila.
Em todos os clientes onde utilizei o método de coleta de log / fila por trigger nunca tive problema de desempenho, não porque a trigger não provoca “overhead” (pois provoca e muito, se nos preocuparmos em medir exclusivamente o tempo a mais para um insert, update ou delete por exemplo, esquecendo que o volume grande de operações em um SGBD é de select na grande maioria dos casos) mas sim porque ao utilizar o ObjectMMRS a empresa descentraliza sua operação, ou seja, o que ela fazia numa única base de dados passa a fazer em N bases, então a sobrecarga no banco de dados simplesmente desaparece, e com isso você pode começar a usar os recursos “avançados” que seu banco de dados oferece sem a neura do problema do desempenho – afinal de contas a idéia de usar um banco de dados relacional é para agilizar a obtenção de dados não é ? Se não fosse para isso qual o motivo então de ter saído do COBOL ? Se não pudermos fazer nada no banco de dados então perde-se o sentido, não dá para ficar usando um banco de mãos amarradas, não pode trigger, não pode join, não pode isso não pode aquilo, etc..
No mês de outubro/2011 estivemos em Denver/Colorado/USA palestrando para usuários do banco de dados PostgreSQL, e nesta ocasião tivemos a oportunidade de jantar com conceituados consultores de banco de dados – eles nos contaram ter clientes com volumes absurdos de dados, da ordem de 4 bilhões de inserts diários em uma base de dados, etc. E o que deu para ver foi que existe uma tendência ao “database sharding” que é justamente quebrar uma base de dados central e única em diversas menores, todas trabalhando simultaneamente, cada uma atendendo uma determinada região ou área de negócio. Esta é uma opção inteligente porque permite à empresa utilizar hardwares mais modestos em seus servidores de banco de dados, por exemplo, em vez de um servidor único de R$ 1,5 mi pode-se usar 4 servidores de R$ 100 mil e assim por diante. Nos EUA eles já passaram por esta fase de tentar resolver o problema de desempenho de banco de dados restringindo o que se pode fazer com o banco e comprando hardware ultra-sofisticado a preços absurdos, agora a idéia é outra, a idéia é realmente “dividir para conquistar” e passar a usar os dados de forma mais distribuída e com hardware modesto.
O ObjectMMRS pode ser usado como infra-estrutura básica para a criação de um ambiente deste tipo onde desmonta-se um servidor central único em N servidores menores, talvez geograficamente localizados mais próximos dos seus usuários trazendo assim inclusive economia de banda de rede e melhoria de disponibilidade.
Caso tenha interesse em discutir e saber como implantar uma arquitetura descentralizada de forma gradativa entre em contato, teremos prazer em fazer uma visita e explicar como o ObjectMMRS pode ajudar.
