Мое приложение, по сути, представляет собой набор микросервисов, развернутых в экземплярах Node.js. Один сервис может записать некоторые данные, в то время как другой сервис будет читать эти обновления. (конкретный пример, я обрабатываю данные, которые поступают в мое решение, используя конвейер обработки. Стадия 1 что-то делает, стадия 2 делает что-то еще с теми же данными и т. д. Это довольно распространенный шаблон)
Итак, у меня большой набор данных (~ 250 ГБ сейчас, и я прочитал, что, как только БД становится намного больше этого размера, невозможно ввести сегментирование в базу данных, по крайней мере, не без какого-либо серьезного обруча прыжки). Я хочу иметь высокодоступную БД, поэтому я планирую использовать набор реплик, по крайней мере, с одним вторичным сервером и арбитром.
Я все еще исследую свои варианты «шардинга», но я думаю, что могу разделить свои данные «клиентом», которому они принадлежат, и поэтому я думаю, что для меня имеет смысл иметь 3 шарда.
Первый вопрос, если я прав, если у меня есть 3 осколка и мой набор реплик - Primary / Secondary / Arbiter (с Arbiter, работающим на Primary), у меня будет 6 экземпляров MongoDB. Будет три первичных и три вторичных (с Арбитром, работающим на каждом Первичном). Это правильно?
Второй вопрос. Я прочитал противоречивую информацию о том, что означает «большинство» ... Если у меня есть Основной и Вторичный, и я пишу, используя подтверждение записи «большинство», что произойдет, когда основной или дополнительный будет отключен? Если Арбитр все еще там, выборы могут произойти, и у меня все еще будет Первоначальное общество. Но относится ли большинство к членам набора репликации? Или для Вторичных? Итак, если у меня есть только Primary, и я пытаюсь написать с опцией «большинства», получу ли я когда-нибудь подтверждение? Если существует только Первичный, то «большинство» будет означать, что запись в Первичный только инициирует подтверждение. Или это будет просто блокировать, пока не истечет мое время ожидания, и тогда я получу ошибку?
Третий вопрос ... Я предполагаю, что, пока я пишу с подтверждением «большинства» и читаю со всех Праймериз, мне не нужно беспокоиться о причинно-следственных данных? Я читал, что чтение с «вторичных» узлов не стоит усилий. При чтении из вторичного устройства вам нужно беспокоиться о «возможной согласованности», и, поскольку записи синхронизируются, вторичные устройства по существу видят тот же объем трафика, что и первичные. Так что нет никакой пользы от чтения из вторичных Если это так, я могу выполнить все чтения из Primaries (используя задачу чтения «большинства») и быть уверенным, что я всегда получаю согласованные данные, а осколки, которые я делаю, дают мне некоторые преимущества от распределения нагрузки между осколки. Это правильно?
Четвертый (и последний) вопрос ... Когда стоит причинно-следственная сессия? Если я правильно понимаю, и я не уверен в этом, то я думаю, что это происходит, когда у меня есть случай, похожий на типичное веб-приложение (не какое-то распределенное приложение, как мое текущее), где есть только одно (или два). ) узлы, делающие чтение и запись. В этом случае я буду использовать причинно согласованные сеансы и делать свои записи в Первичную и чтения из вторичной. Но, в таком случае, какой будет польза от чтения от Вторичных? Что мне не хватает? Каков вариант использования для причинно согласованных сессий?