configuração db backend para um aplicativo com geograficamente diversos usuários

Question

O software desenvolvido in-house onde eu trabalho conecta-se diretamente a um servidor MySQL aqui em nosso escritório através do nosso ORM DevExpress (XPO). Desempenho é grande.

Estamos abrindo outro escritório ... cross country. Performance: não tão grande. A exigência é que o software seja tão sensível em ambos os escritórios, pois é neste escritório e que os dados de um escritório estar disponível para o outro 'em tempo real'.

Algo desta escala é totalmente novo para mim. Eu não sou avesso a trazer um consultor que fez algo assim antes, mas eu gostaria de ter uma boa visão das opções em primeiro lugar. Tenho certeza de que esta é uma situação comum.

é a replicação uma boa idéia? É rápido o suficiente? bastante estável?

Existem padrões de desenvolvimento que abordam este tipo de situação, se a replicação não vai funcionar?

Heck, eu não sou mesmo certo como marcar esta, então se alguém sabe melhor ... por favor, sinta-se livre para voltar a tag

EDIT> Detalhes sobre os dados

Eu acho que, em comparação com alguns software da empresa, não estamos movendo grandes quantidades de dados. O software gerencia contas de clientes, compromissos etc. e cada usuário obras em cerca de 2-5 contas separadas / minuto (50 usuários atualmente, 200-400 após a expansão planejada), atualização de dados de cada vez.

O aspecto em tempo real entra em jogo quando alguém no escritório Um cria um compromisso para alguém no escritório B que, idealmente, deve ser capaz de ver os seus detalhes perto imediatamente (<2 minutos). Dito isto, cada registro normalmente só se transformou um máximo de 5 vezes por dia. Mas isso é só o que eu suspeito; Eu realmente não tem nenhum estatísticas de uso em mim.

Answer 1

Você não pode usar a replicação assíncrona em ambas as direções sem criar conflitos de replicação que são impossíveis de resolver e quebrar as coisas.

Portanto, a escolha óbvia é usar / gravação divisão ler - ter o aplicativo fazer noncritical lê a partir de uma (somente leitura) DB local, e direcionar todas as gravações para o mestre. A desvantagem desta situação é que isso significa que você não pode imediatamente ler de volta suas próprias gravações.

replicação do MySQL não é perfeito e exige algum esforço para configurar e monitoramento contínuo para manter; você deve frequentemente verificar os dados são os mesmos nos escravos. Algumas consultas se replicado de forma incorrecta; você precisa entender esses e evitá-los.

Answer 2

Um dos você é último resorts é, naturalmente, para se certificar de que todo o trabalho pesado é feito em threads em segundo plano tais que o segmento GUI nunca é bloqueado.

Ter dados em tempo real depende dos dados, sinto falta de uma descrição detalhada, como a quantidade de dados que estamos falando por solicitação (ou seja, o quão grande são os objetos), o quão rápido é que você está ligação à Internet (poderia ser o gargalo?), é o servidor MySQL e toda infra-estrutura entre em que você controla bem configurado? Como estático / dinâmico são os dados, se os dados em tempo real se transformou uma vez por dia ou ele é transformado um zilhão de vezes por dia é importante para a "solução"