настройка внутренней базы данных для приложения с географически разнородными пользователями

Question

Программное обеспечение, разработанное нами, где я работаю, напрямую подключается к серверу mysql в нашем офисе через нашу систему devexpress (XPO). Производительность отличная.

Мы открываем еще один офис ... кросс-кантри. Производительность: не очень хорошая. Требование заключается в том, чтобы программное обеспечение отвечало требованиям обоих офисов так же, как и в этом офисе, и чтобы данные из одного офиса были доступны для другого «в режиме реального времени».

Что-то такого масштаба совершенно ново для меня. Я не против пригласить консультанта, который делал что-то подобное раньше, но я хотел бы сначала получить хорошее представление о вариантах. Я уверен, что это обычная ситуация.

Является ли репликация хорошей идеей? Это достаточно быстро? достаточно стабильный?

Существуют ли шаблоны разработки, которые разрешают подобные ситуации, если репликация не работает?

Черт, я даже не уверен, как пометить это, так что если кто-то знает лучше ... пожалуйста, не стесняйтесь пометить

РЕДАКТИРОВАТЬ> Подробная информация о данных

Полагаю, по сравнению с некоторыми корпоративными программами мы не перемещаем много данных. Программное обеспечение управляет учетными записями клиентов, встречами и т. Д., И каждый пользователь работает с 2-5 отдельными учетными записями в минуту (50 пользователей в настоящее время, 200-400 после запланированного расширения), обновляя данные каждый раз.

Аспект в реальном времени вступает в игру, когда кто-то в офисе A назначает встречу для кого-то в офисе B, который, в идеале, должен иметь возможность просматривать его данные почти сразу (<2 минуты). При этом каждая запись обычно видоизменяется не более 5 раз в день. Но это только то, что я подозреваю; На самом деле у меня нет статистики использования. </p>

Answer 1

Нельзя использовать асинхронную репликацию в обоих направлениях, не создавая конфликты репликации, которые невозможно разрешить и сломать.

Следовательно, ваш очевидный выбор - использовать разделение для чтения / записи - приложение должно выполнять некритическое чтение из (только для чтения) локальной БД и направлять все записи в мастер. Недостатком этого является то, что вы не сможете сразу же прочитать свои собственные записи.

Репликация MySQL не идеальна и требует определенных усилий для настройки и постоянного мониторинга; Вы должны часто проверять данные одинаковы в рабах. Некоторые запросы дублируются неправильно; вам нужно понять их и избегать их.

Answer 2

Одно из ваших последних прибежищ - конечно, чтобы убедиться, что вся тяжелая работа выполняется в фоновых потоках, чтобы поток GUI никогда не блокировался.

Наличие данных в реальном времени зависит от данных, я упускаю подробное описание, например, о каком объеме данных мы говорим по запросу (т. Е. Насколько велики объекты), как быстро вы подключаетесь к Интернету (может быть, бутылочное горлышко?) Хорошо ли сконфигурирован сервер mysql и вся инфраструктура между ними? Насколько статичны / динамичны данные, если данные в реальном времени мутируют один раз в день или мутируют миллион раз в день, это важно для «решения»