почему все записи должны идти к хозяину и почему писать рабу не имеет смысла?

Question

http://www.pcpro.co.uk/realworld/355477/understanding-the-nosql-movement:

Тем не менее, все записи должны идти на мастер, потому что поток данных является односторонним от мастера к подчиненным, а запись на ведомый не имеет смысла.

У меня проблемы с пониманием этого утверждения.Из моего ограниченного понимания я просто не могу понять, почему существует это ограничение.Разве нет никакого способа для подчиненного «общаться» с ведущим, чтобы пользователь мог просто написать подчиненному, и тогда ведомое устройство сообщит ведущему о записи… нет?

Answer 1

Термин «мастер» в этом смысле означает «владелец» - авторитетная копия данных. Рабы - это реплики, которые можно использовать для распределения нагрузки. (Как правило, есть несколько ведомых на одного мастера)

Таким образом, по определению, любой узел, выполняющий запись, становится "главным". Существует много систем, которые поддерживают конфигурации с несколькими мастерами, и они, как правило, более сложны, чем системы с одним мастером, поскольку мастерам необходимо поддерживать согласованность между собой.

Я написал пост, объясняющий это более подробно здесь

Answer 2

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

Answer 3

Проще говоря, потому что вы теряете последовательность. что вы делаете, когда конфликтует запись в ведомое устройство и одновременная запись в ведущее устройство? Либо одно, либо другое обновление будет потеряно, или, если вы обнаружите конфликт, что вы будете делать тогда?

Обычно вы хотите, чтобы ваша база данных демонстрировала свойства ACID . Если вы хотите этого, то с несколькими серверами, принимающими записи (это действительно определение мастера), вы попадаете в сценарии с несколькими мастерами, о которых говорится в статье, на которую вы ссылаетесь, и возникающие с этим проблемы масштабируемости (см. ). Распределенные транзакции (подробнее)