Dados em tempo real com o menor custo

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).

UBER troca PostgreSQL por MySQL devido a problemas na replicação

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.

Fonte: Artigo publicado no website infoq

ObjectMMRS no Tribunal de Justiça do Amazonas

A OBJECT Sistemas está instalando o ObjectMMRS em 61 servidores a serem distribuídos em todas as comarcas do estado do Amazonas. Este projeto viabilizará o uso do sistema PROJUDI (primeira instância) de forma descentralizada nas 61 comarcas do Amazonas, garantindo aos usuários destas comarcas excelente desempenho e disponibilidade, qualidades impossíveis de serem obtidas com o uso do sistema de forma centralizada em Manaus. A implantação está caminhando a todo vapor, com 15 comarcas já atendidas. O OBJETMMRS foi escolhido após longa série de avaliações e testes envolvendo outros produtos de replicação, inclusive produtos de grandes empresas que falharam ao tentar replicar dados nas condições de rede existentes na região (via satélite). O ObjectMMRS foi o único a replicar com bom desempenho tanto dados comuns como BLOBS (processos digitalizados, etc) nestas condições apresentadas graças à tecnologia diferenciada na qual o produto é baseado, permitindo grande granularidade de configuração de forma a operar tanto em redes de boa qualidade quanto nas piores situações possíveis.

Leia mais sobre o projeto do TJAM

Novo TCC sobre descentralização e replicação de banco de dados

Mais uma vez parabenizamos o autor e seu orientador pela produção de um TCC no Centro Universitário IESB. Desta vez o autor foi o Sr. Sidnei Fernandes das Neves, orientado pelo Prof. Esp. Eder Couto.

A íntegra do trabalho de Sidnei pode ser vista em http://www.object.com.br/files/TCC_BDD_Sidnei.pdf

Neste TCC pode-se ter idéia de como o OBJECTMMRS pode ser usado como infra-estrutura para um ambiente de banco de dados distribuído. O estudo mostra um comparativo com outras ferramentas de mercado, e por qual motivo o OBJECTMMRS é a melhor escolha para um ambiente descentralizado.

A OBJECT Sistemas procura sempre que possível apoiar estudos onde o OBJECTMMRS possa ser usado para a criação de projetos de bancos de dados descentralizados.

OBJECT na APAS 2012

Anderson Shibata e Wagner Ramos estiveram na APAS 2012 em 08/05/2012 apresentando o “CASE Shibata”. Cerca de 90 pessoas (empresários e dirigentes de TI) estavam presentes e puderam presenciar o histórico de evolução no uso da TI pela rede de supermercados Shibata, com destaque para a adoção do produto OBJECTMMRS em 2009, que trouxe ao grupo a tranquilidade de poder trabalhar com alta disponibilidade e alto desempenho com seus sistemas informatizados.

Anderson e Wagner na APAS 2012

Desde 2009 o grupo não teve nenhum evento de parada de banco de dados, pois com a arquitetura possibilitada pelo OBJECTMMRS, cada loja tem o seu próprio servidor, com isto os usuários conseguem excelente produtividade no uso do sistema, pois ficam independentes da velocidade ou estabilidade de redes, internet, etc.

O OBJECTMMRS permite hoje ao grupo um crescimento linear, sem preocupações com sobrecarga de servidores, a cada nova loja inaugurada pelo grupo um novo servidor de baixo custo é alocado e instalado dentro da loja.

Estamos disponibilizando para quem não teve a oportunidade de ver ao vivo, a palestra em que Sr. Anderson Shibata (Diretor de TI da rede Shibata) e Wagner Ramos (Diretor da OBJECT Sistemas) apresentaram durante o evento.

Clique aqui para assistir à palestra, com duração de aproximadamente 30 minutos.

Replicação acessível a todos

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.

ObjectMMRS em artigo da SQLMagazine

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.

Os problemas da centralização de banco de dados

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.