Задний план
У нас есть приложение, которое будет записывать данные в базу данных postgres, размещенную в центре обработки данных Франкфурта. Приложение установлено на каждом из 8 сайтов по всему миру, в Китае, Корее, Индии, Германии, Франции и Мексике.
При подключении в Европе к базе данных Франкфурта время отклика хорошее. Однако при подключении из северной части Китая время отклика просто медленное. Великий китайский межсетевой экран задерживает время отклика и, к тому же, решающим фактором является расстояние.
Мы решили создать вторую базу данных в Корее для наших азиатских сайтов. Приложение на корейском и китайском сайтах будет кормить корейскую базу данных. Это значительно уменьшило задержки и отлично сработало.
Проблема в том, что невозможно скопировать данные между корейской базой данных и немецкой базой данных, поскольку двунаправленная репликация не разрешена.
Теперь мы вернулись к исходной точке, поскольку мы не уверены, какие шаги предпринять, поскольку нам нужна только одна база данных, но нам нужно приличное время отклика. Мы не хотим переписывать приложение.
Вопросы:
Не уверен, что это подходящее место, чтобы задать этот вопрос. Если нет, оставьте комментарий, и я удалю вопрос.
И расстояние, и мешающие промежуточные ящики увеличивают задержку, этого нельзя избежать.
Могут быть другие места для размещения базы данных с приемлемой задержкой. Однако такая большая задержка снизит время отклика. Продолжайте тестирование.
Я понимаю, что для PostgreSQL существуют решения для репликации с несколькими мастерами. Этого не будет в вашем текущем программном обеспечении и, вероятно, не будет включено в облачное предложение. Было бы полезно, если бы опытный администратор баз данных был более сложным и рискованным, чем один экземпляр.
Или переместите клиента ближе. Хост через удаленный рабочий стол или локальный VDI для базы данных. Возможно, медленный интерфейс будет терпимым, когда время загрузки запросов значительно улучшится.
Наконец, изменение приложения, несмотря на то, насколько оно непривлекательно. По крайней мере, профилируйте количество запросов, чтобы было известно количество сетевого времени. Уменьшение их могло бы принести пользу. Сложнее было бы переосмыслить дизайн, возможно, запросы на чтение из реплики, но записи идут в первичный.