У меня есть система, которая по необходимости требует физического присутствия в трех или более разных местах, и мне нужен совет по структурированию таким образом, чтобы моя база данных постоянно реплицировалась без ужасных задержек. Я видел, как доступ и репликация mysql были невероятно медленными, когда сервер приложений пытался поговорить с узлом, который физически не был размещен вместе. В этом случае я использую mongodb.
Из чтения документации mongo репликация mongo кажется более подходящим кандидатом, чем сегментирование b / c, мое хранилище данных невелико. Однако я не вижу ничего, что решало бы проблему скорости для серверов, взаимодействующих на больших расстояниях с потенциально высокой задержкой.
Ваш опыт задержки несколько тревожит. В моем собственном тестировании в моей локальной быстрой сети я заметил несколько различий между Mongo и MySQL, когда дело доходит до задержки:
Часть времени MongoDB была связана с временем установки TCP-соединения, когда MySQL использовал уже существующее (объединенное) соединение. В обоих случаях база данных не была реплицирована или сегментирована, поэтому это можно считать лучшим случаем (для моей сети).
Наборы реплик Mongo могут помочь вам в этом, но только если ваше приложение допускает слабую конвергенцию.1. Чтобы добиться максимальной скорости, вам нужно настроить запись mongo так, чтобы она возвращалась только тогда, когда сервер mongodb сообщает, что он получил запись, и настроить серверы приложений на использование только экземпляра Mongo, локального в AZ. Для чтения необходимо использовать SlaveOK, чтобы они могли читать из этой локальной реплики AZ, это покажет локальные записи, а также реплицированные записи с других узлов, которые были объединены до сих пор. Это означает, что каждая зона доступности будет иметь несколько иное представление всей базы данных; за последние X минут будут только локальные изменения, но глубокая история будет сведена воедино.
Эта настройка обеспечит низкую задержку (одинаковая зона доступности) между сервером приложений и сервером БД. Однако представление данных с серверов приложений будет отличаться в зависимости от зоны доступности, в которой находятся ваши потребители приложений. Только вам решать, будет ли эта архитектура приемлемой для вашего приложения.
Однако с этим возникает очень большая проблема: MongoDB не поддерживает несколько мастеров2 репликация все записи должны поступать к одному Мастеру.
В настоящее время (v2.2) невозможно настроить MongoDB, чтобы разрешить запись на ведомые устройства, поэтому все записи в вашем приложении с тяжелой записью должны будут идти на единственное главное устройство набора реплик. Вы не упоминаете, является ли задержка чтения проблемой, но если это так, то SlaveOK читает воля захватите локальную реплику Mongo; но, в отличие от вышеупомянутого, он, возможно, еще не получил все обновления от ведущего устройства, поэтому определенно будет задержка между записью-отправкой и тем, когда он обнаружит локальное ведомое устройство.
Для Mongo существует несколько разных типов записи. По умолчанию возвращается ОК, как только сервер Mongo полностью получил запись. Следующий шаг - это режим, в котором он возвращает OK только после завершения записи в журнал. И самый параноидальный (и, следовательно, самый медленный на сегодняшний день в монго с репликами) возвращает ОК только тогда, когда указанное количество реплик сообщают, что запись находится в их журналах. Режим по умолчанию - самый быстрый, но последний режим гарантирует, что локальные реплики имеют запись (строгая согласованность).
Если этот мастер не находится в той же зоне доступности, что и серверы приложений, задержка может оказаться для вас неработоспособной даже при использовании стиля записи по умолчанию. Если это так, mongo не будет работать для вас, поскольку ваше приложение существует прямо сейчас. вам придется серьезно подумать о том, как изменить свое приложение, чтобы оно было менее чувствительным к задержкам при записи, или использовать базу данных, отличную от Mongo, которая может работать с несколькими мастерами со слабой конвергенцией.
Самый близкий подход Mongo к конфигурации с несколькими мастерами - это сегментирование. Если ваши серверы приложений знают свое географическое положение, вы можете включить геоданные в Mongo Shard-Key. Затем, когда вы подключаетесь к MongoS для записи, все записи попадают в набор реплик локального шарда. Чтение может опрашивать всю базу данных (и будет соответственно медленным при отборе из нелокальных шардов), так что это сохранит согласованность. Однако это полностью зависит от местоположения, являющегося вашим ключом осколка.
1: Слабая конвергенциявремя перехода распределенной или реплицированной базы данных в однородное состояние - это время сходимости. Слабая конвергенция - это длинный интервал. Тесная конвергенция - это короткий интервал.
2: Мульти-мастер, База данных, в которой записи могут принимать более одной реплики. Примерами баз данных, которые могут это делать, являются Active Directory, OpenLDAP и некоторые конфигурации MySQL.