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.