Запись во многие копии MongoDB - PullRequest
0 голосов
/ 05 октября 2018

Допустим, у меня есть распределенное приложение, которое пишет в базу данных.Чтобы уменьшить задержку, один из экземпляров (приложение + база данных) размещается в Австралии, а другой - в Европе.Оба экземпляра базы данных должны использовать одни и те же данные.

Итак, что мы ищем, это локальность данных.Причина этого очевидна: мы не хотим, чтобы пользователи в Австралии отправляли запросы в нашу базу данных в Европе, потому что это увеличило бы задержку.

Естественным выбором будет развертывание обоих экземпляров базы данных в одном наборе реплик.Но кажется, что с MongoDB вы можете записать в только один экземпляр Mongo в пределах набора реплик.

Каковы стратегии с MongoDB, чтобы иметь два экземпляра базы данных, совместно использующих одни и те же данные, к которымты можешь написать?Или MongoDB - просто неправильный выбор для этого требования?

1 Ответ

0 голосов
/ 05 октября 2018

Огромная тема, но я постараюсь дать вам краткий и простой ответ:

Поскольку ваши два экземпляра должны использовать один и тот же sata, вы не можете использовать сегментированный кластер с зонами Но набор реплик может быть вашим решением:

  • Создайте набор реплик, как минимум, со следующим:

    • серверв «нейтральной» зоне.Это будет основной сервер (установите приоритет выше).Этот сервер, пока он остается основным, будет обрабатывать ваши операции записи.

    • ваши два существующих сервера с более низким приоритетом.

  • Установите в своем приложении Чтение предпочтения на «ближайший».Таким образом, ваши операции чтения будут обрабатываться сервером, имеющим задержку в сети газонокосилки, независимо от главной / второстепенной роли сервера.

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

РЕДАКТИРОВАТЬ

Некоторые соображения по поводу этого решения:

  • Этот вариант использования является одним из редких случаев использованияслучай, когда лучше читать из вторичных.В общем, предпочитайте читать ваши данные из MASTER, поскольку набор реплик сделан для высокой доступности, а не для масштабируемости.

  • Если некоторые из ваших данных могут быть «расположены» для более быстрого доступа,рассмотрите возможность разделения коллекций как лучшее решение

...