Назад | Перейти на главную страницу

Если моя база данных должна оставаться в одном регионе, есть ли смысл распределять мой API по нескольким?

В настоящее время у нас есть API и база данных в Австралии, и мы пытаемся уменьшить задержку в других странах.

Освоение теоремы CAP для синхронизированных баз данных, вероятно, в настоящее время немного выходит за рамки возможностей, но мы изучаем горизонтальное масштабирование в нескольких регионах (например, есть серверы в США / ЕС / Азии).

Теперь, когда я ломаю голову, принесет ли этот подход какое-либо преимущество по задержке? Есть очевидные преимущества в том, что сервер находится ближе к пользователю, но взамен база данных (все еще находится в Австралии) теперь находится намного дальше.

Я надеюсь, что все это имеет смысл, я новичок в таких вещах, как devOps.

В основном это зависит от вашего варианта использования. Например, часто распределение операций записи в базу данных и чтения из базы данных резче, чем 1:10. Также конечные точки API для чтения часто используются больше, чем для операций создания / обновления / удаления. В этом случае вы можете реализовать локальное кеширование для определенных запросов, чтобы уменьшить время ответа.

Кроме того, довольно легко настроить реплики чтения для нескольких регионов для вашей базы данных. Это поддерживается многими размещенными базами данных (MongoDB Atlas, Amazon RDS, ...).

Я считаю, что в вопросе отсутствует какой-то контекст.

Я предполагаю, что вы имеете в виду, что хотите настроить серверы API в (США / ЕС / Азии).

Это очень сильно зависит от того, что на самом деле делает API.

Если вы можете кэшировать на сервере API, вы можете получить гораздо лучшую задержку.