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

Question

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

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

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

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

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

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

РЕДАКТИРОВАТЬ > Подробности о данных

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

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

Answer 1

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

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

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

Answer 2

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

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