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

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.

O desgaste da arquitetura centralizada

Ano após ano vemos os mesmos problemas, seja em websites do governo, em aplicações centralizadas do governo (como esta do Detran do Estado de São Paulo, que vira e mexe apresenta problemas sérios de desempenho e disponibilidade – http://www.agora.uol.com.br/saopaulo/ult10103u1033262.shtml) ou em aplicações de grandes websites de comércio eletrônico.

E sempre procuram resolver o problema de uma forma que acredito que não tem dado muito resultado, que é a forma mais simples mas em contra partida mais cara de resolver o problema: escalar o hardware, sempre comprando hardware cada vez mais caro e de difícil reposição.

A solução para isto não está no hardware, está na arquitetura de software e banco de dados da aplicação, faça a aplicação de forma descentralizada, trabalhe com N servidores e N bancos de dados, fique livre dos problemas de desempenho e de disponibilidade, trabalhe com hardware de baixo custo !!

A OBJECT pode ajudar no planejamento para a mudança de uma arquitetura centralizada para uma arquitetura descentralizada, nosso principal produto, o OBJECTMMRS ajuda muito pois permite que este processo de descentralização seja gradativo, você migra da aplicação centralizada para a descentralizada em etapas, sem o stress de uma implantação traumática – continue usando parte da sua aplicação de forma centralizada, com bancos de dados proprietários de alto custo, etc, e gradativamente va migrando para arquitetura descentralizada, com o uso de servidores e bancos de dados de baixo custo – O OBJECTMMRS vai ligar estes 2 mundos diferentes para você, de forma transparente e totalmente gerenciada.

Entre em contato, solicite uma visita para entendermos o seu problema e mostrarmos como podemos ajudar.

Informação rápida e confiável

A rede de supermercados Shibata iniciou um projeto para trazer a informação de BI em tempo real para seus gerentes e executivos.

Através do uso do OBJECTMMRS, os dados recebidos nos concentradores dos PDVs, atualmente um banco de dados MySQL em cada loja da rede, serão replicados continuamente para o ERP / Retaguarda que trabalha com banco de dados PostgreSQL, e estes dados da retaguarda por sua vez são replicados para um servidor central PostgreSQL que recebe os dados e em tempo real também com o uso do OBJECTMMRS replica para a base de Business Intelligence, que é uma base de dados SQLServer.

Mas não pára por aí, uma vez os dados transformados pelas “classes customizadas” desenvolvidas pela própria equipe de TI da rede e gravados na base de BI SQLServer, o OBJECTMMRS mais uma vez entra em ação para replicar estes dados para as bases de dados SQLite localizadas nos smart-phones padrão Android que poderão ser usados online ou offline para a análise de vendas, compras, custos e rentabilidade.

O OBJECTMMRS entra neste circuito como o integrador de todas estas aplicações, oferecendo ao empresário dados em tempo real de centenas de PDVs consolidados em sua base de dados local do seu tablet ou smart-phone, podendo ele usar estes dados em qualquer situação ou ambiente, como por exemplo em uma longa viagem aérea, etc.

Entre em contato conosco e venha ser mais uma empresa a ter informações sempre disponíveis, nunca mais se preocupe com a frase “o sistema está fora do ar”, ou então “a rede está fora”, etc.

Nosso email: contato@object.com.br