Гипотетически ... Я вхожу в веб-приложение из Австралии и меняю некоторые данные. В США мой коллега использует ту же систему и хочет просмотреть данные, которые я изменил. Как можно было развернуть веб-приложение локально для австралийских пользователей и локально для пользователей из США (для повышения производительности), но совместно использовать данные?
Как Google, Facebook или любая другая глобальная система улучшает производительность для пользователей в разных странах, но при этом сохраняет синхронизацию данных в случае, если пользователь отправляется в другое место или данные используются глобально. Или у них на самом деле серверы баз данных находятся в одном месте?
Что касается Facebook, Google и т. Д.: Не все серверы баз данных находятся в одном месте и, конечно же, не все синхронизируются полностью. Все они используют распределенную систему на нескольких кластерах серверов для разных географических регионов.
Кластеры распространены во многих странах. Частота обновлений между кластерами зависит от необходимости приемлемой работы системы.
Если вы возьмете Facebook, например: большую часть времени вы общаетесь с друзьями в своей стране. Таким образом, сохранение серверов в вашей стране даст немедленный эффект, и ваши друзья мгновенно увидят ваши сообщения.
У друзей в других странах может быть задержка, в зависимости от того, как часто обновляются узлы кластерного сервера. Кластеры IIRC Facebook взаимодействуют, при необходимости запрашивая информацию у других кластеров. Много раз я получал сообщение вроде «Этот пользователь обновил статус до бла-бла». При переходе по ссылке на все сообщение появляется сообщение об ошибке. Это проблема синхронизации между кластерами. Часть информации была синхронизирована, а другая нет.
Способ построения инфраструктуры зависит от количества пользователей, частоты синхронизации данных и т. Д.
Другой пример, электронная почта: система электронной почты - это распределенная система по всей планете. Сервер с одним пользователем не так загружен по сравнению с сервером с 1 миллионом пользователей. Как бы вы решили проблемы с доставкой на загруженный сервер? Более распределенный локальный сервер? Более мощные серверы? Более мощное интернет-соединение? Все вышеперечисленное? Поскольку основная концепция электронной почты (доставлять сообщения от одного узла к другому) не меняется независимо от количества пользователей электронной почты, вам нужно будет разработать свою конкретную систему, которая будет соответствовать всем вашим пользователям. Независимо от того, как вы проектируете свою систему, бывают случаи, когда доставка электронных писем задерживается из-за того, что на других узлах цепочки просто слишком много трафика.
То же самое применимо и к Facebook. Они проектируют и строят свои фермы для конкретного региона, но вся система опирается на «географические различия». То есть у вас больше шансов взаимодействовать с пользователями в вашем собственном регионе, чем в других регионах.
Что касается вашей конкретной проблемы: все зависит от того, сколько пользователей.
Вам может подойти один сервер базы данных (или кластерный сервер). Если есть необходимость в распределенных кластерных фермах серверов, возможно, вам придется написать собственную систему для синхронизации, как это сделали Facebook и Google. Это решение зависит от того, что нужно вашим пользователям и как система предназначена для работы. Я не знаю ни одной стандартизированной системы, которая могла бы работать для всех.
Я много разглагольствовал здесь, и уже довольно поздно, и я, возможно, совсем не намечен, но эй, это мои 2 цента.
Ура!
Не уверен, насколько это конструктивно, однако Google утверждает, что синхронизация почти в реальном времени. У них даже есть собственные атомные часы в центрах обработки данных для надлежащей синхронизации. В Wired есть статья об этом:
http://www.wired.com/wiredenterprise/2012/11/google-spanner-time/
Это хорошо известная проблема CS, сформулированная Эриком Брюером как теорема CAP.
Однако кажется, что Google мог решить эту проблему с помощью гаечного ключа Google, который теперь общедоступен. https://cloud.google.com/spanner/
Если вы не готовы использовать гаечный ключ, то вам следует рассмотреть руководящие принципы ваших требований к данным. Последовательность, доступность или производительность. (ШАПКА)
для этого есть много статей и шаблонов проектирования, поэтому я не буду здесь повторять.