Veja em 3 minutos como a replicação de banco de dados pode ajudar na melhoria da disponibilidade e do desempenho de sistemas…
Veja em 3 minutos como a replicação de banco de dados pode ajudar na melhoria da disponibilidade e do desempenho de sistemas…
Esta animação explica de forma bastante simples o que é uma replicação de banco de dados e os benefícios de ter sua base de dados descentralizada.
Conte para nós escrevendo para contato@object.com.br como é o seu projeto e ajudaremos a você estudar os prós e contras de se trabalhar com replicação de banco de dados.
Nosso produto OBJECTMMRS é muito flexível podendo ajudar em muitos cenários, desde um simples backup em tempo real até a projetos complexos de distribuição de dados envolvendo bases de dados de diferentes fabricante e também bases NoSQL em Cloud.
A OBJECT acaba de lançar a versão 8.0 do seu software de replicação de banco de dados OBJECTMMRS. Esta nova versão, batizada de OBJECTMMRS Cloud, surgiu após anos de experiência da empresa em projetos de replicação de bancos de dados, tanto para governo quanto para variados tamanhos de empresas, aliado à novas tecnologias trazidas pela nova geração que começa a participar ativamente trazendo novos conhecimentos à equipe.
Destaques do OBJECTMMRS Cloud
Entre em contato e experimente sem compromisso nosso novo produto. Leia mais em OBJECTMMRS Cloud – Detahes
Não perca mais negócios devido à desconectividade. Em um país como o Brasil onde a Internet é satisfatória (não digo boa) apenas nas grandes capitais fica impossível tentar trabalhar com sistemas informatizados centralizados, por melhor que seja seu datacenter não tem jeito, seus usuários mais distantes sofrerão demais para usar com produtividade o sistema, e fatalmente negócios serão perdidos.
Uma antiga providência para tratar o problema são os chamados ETLs, onde sistemas locais enviam dados em formas de arquivos texto, XMLs, etc, para um servidor central, isso melhora bastante o cenário, mas traz junto um atraso considerável que pode ser de até 5 dias em alguns negócios.
Nosso produto de replicação de banco de dados, o OBJECTMMRS trabalha com o conceito de CDC, trabalhando “near real-time”, i.e., em poucos minutos você consegue ter seus dados centralizados de forma transparente para o usuário e também ter dados replicados de volta para os servidores distribuidos geograficamente de modo a refletir de forma quase tempo real todas as atualizações ocorridas a nível nacional / internacional.
Você não precisa trabalhar 8 (centralizado) ou 80 (descentralizado transmitindo arquivos), trabalhe com o conceito de CDC e replicação de banco de dados assíncrona como o OBJECTMMRS oferece que terá pelo menos um pouco do melhor desses 2 cenários (a velocidade na sincronização dos dados e a simplicidade dos ETLs).
Recentemente foi divulgado um texto com as justificativas da equipe técnica do UBER para a substituição do PostgreSQL pelo MySQL como seu banco de dados da app que todos conhecem.
Um dos principais problemas alegados pela equipe do UBER foi com a replicação de banco de dados. Eles citam que um simples UPDATE causa um volume grande de atualizações que precisam ser propagadas pela rede para todos os servidores. O que ocorre é que optaram pelo modo de replicação “física” disponível nativamente no PostgreSQL. Este modo de replicação deveria ser usado apenas quando os servidores estivessem em rede local pois existe necessidade de grande banda de rede para que os dados sejam replicados em tempo viável para manter a consistência dos servidores. Outro problema mencionado foi relativo ao upgrade de versão de PostgreSQL. Como usam essa ferramenta nativa do PostgreSQL para a replicação então TODOS os servidores precisam sofrer o upgrade ao mesmo tempo, imagine isso num cenário com mais de 100 servidores, imposssível não é mesmo.
Se seu negócio vive no mundo real, onde banda de internet é ruim, onde é impossível um upgrade de versão simultâneo, conheça o OBJECTMMRS. Com absoluta certeza o UBER não teria deixado de usar o PostgreSQL se usasse o OBJECTMMRS como ferramenta de replicação. O UBER é um exemplo de aplicação onde é perfeitamente viável o uso de um software assíncrono de replicação, onde a replicação seja realizada apenas na camada lógica do banco de dados.
Antes de decidir qual modelo de replicação usar consulte a OBJECT Sistemas, poderemos esclarecer para o seu cenário específico os motivos de uma determinada ferramenta ser ou não adequada, e poderemos também dizer se o OBJECTMMRS é viável para o seu projeto. Responderemos às suas dúvidas de forma estritamente técnica, sem nenhum compromisso com a aquisição de nosso software.
Venha fazer parte de um novo conceito de arquitetura para trabalhar com alto desempenho e alta disponibilidade mesmo em situações onde seus usuários não estejam todos no mesmo local geográfico. Faça como grandes redes varejistas dos EUA fazem com sucesso, esteja preparado para crescer sem limites.
Para incentivar a arquitetura descentralizada e o uso de hot-backup por pequenas empresas a OBJECT passará a distribuir uma versão free do ObjectMMRS.
O ObjectMMRS Express tem como público alvo empresas com até 3 sites, por exemplo, uma matriz, uma filial e um datacenter como backup. O volume diário de operações de banco de dados não pode ultrapassar 50 mil (inserts, updates e deletes).
O ObjectMMRS Express será distribuido com todos os recursos existentes nas versões Standard e Corporate, limitando apenas a quantidade de servidores e o volume de dados replicados.
Entre em contato e comece hoje mesmo a trabalhar com “zero-downtime” e alto desempenho. Use links baratos para inteligar seus sites, pode ser 3G, banda larga estilo home, etc.
A revista SQLMagazine traz em sua edição número 95 (janeiro/2012) um excelente artigo escrito por Paulo Henrique dos Santos, intitulado “Trabalhando com replicação de dados”.
No artigo o produto ObjectMMRS foi lembrado e indicado como ferramenta multiplataforma para replicação de banco de dados.
Recomendamos a todos os interessados em replicação de bases de dados que leiam o artigo, é muito didático, o autor abordou de forma simples e direta o assunto mostrando as diversas opções disponíveis para projetos de replicação e a sua importância no momento atual.
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.