Консистенция для чтения из распределенных баз данных

Question

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

Мне нужно убедиться, что мои данные всегда будут сохранены.

Я не могу организовать набор реплик с репликацией sync/async, поскольку он заставит меня подключиться к одному хозяину, который является точкой отказа, поэтому я отправляю данные от клиента ко всем базам данных, которые я знаю. По-видимому, одна база данных может не сохраниться, поэтому я полагаюсь на другие записи баз данных. В конце концов, я получаю разные наборы данных, хранящиеся в БД, хотя эти наборы перекрываются. (Пример DB1 -> [1, 2, 3], DB2 -> [1, 3], DB3 -> [2,3,4])

Как получить согласованные данные при чтении из этих БД? Какие методы следует применять на клиенте, который пишет данные и клиент, который читает, чтобы иметь возможность успешно объединять наборы данных (получение на читателе [1,2,3,4])?

Answer 1

Существует двухстороннее/трехстороннее репликационное программное обеспечение, для которого не требуется «мастер». Вы также можете использовать репликации на основе журнала транзакций.

Что и как вы можете использовать, будет зависеть от используемого вами продукта базы данных.

НТН

Answer 2

Что вы спрашиваете, в основном целая отрасль информатики. Это очень нетривиальная проблема, и вы обнаружите, что удивительное количество вещей невозможно.

Также обратите внимание, что просто говорить «согласованные» данные не является достаточным определением. Существуют всевозможные уровни согласованности (read-your-own-write, reads-follow-write, monotonic read, линеаризуемый, причинный и т. Д.). Я думаю, вы, вероятно, имеете в виду (в очень свободном смысле): последовательность, аналогичная тому, что вы получаете, когда используете только одну базу данных.

Чтобы ответить на ваш вопрос напрямую, вы хотите выбрать размер кворума для чтения и размер кворума для записи. Эти размеры должны быть выбраны так, чтобы чтения и записи перекрывались по крайней мере одним экземпляром базы данных. Если вы хотите оптимизировать латентность записи, используйте меньший кворум для записи и делайте наоборот, если хотите оптимизировать латентность чтения.

Более подробное изложение перекрывающихся кворумов чтения/записи можно найти в Weighted Voting for Replicated Data. Это считается важной работой в области репликации.

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

Наконец-то - вот настоящий удар в зубах - то, что я описал, в некоторых случаях не дает вам согласованности (по каким-либо определениям) (мне нравится Daniel Abadi's explanation of when andy why), но для многих систем это дает вам достаточно Консистенция. Вам решать, какой уровень согласованности вам нужен.