Рекомендуемая топология репликации CouchDB
Я работаю над предложением для системы с семью серверами CouchDB (A,B,C,D,E,F,G) в разных странах. Идея состоит в том, чтобы настроить репликацию с несколькими мастерами, чтобы все данные можно было синхронизировать.
Я мог настроить двунаправленную репликацию с каждого сервера на другой сервер
но я подозреваю, что это может привести к слишком большому количеству соединений, которые могут снизить производительность за счет увеличения используемой полосы пропускания (так ли это?).
Поэтому моя следующая идея - настроить их как кольцо:
Теперь у нас намного меньше подключений, и мы сохраняем избыточность, поскольку каждый узел подключен к двум серверам. Проблема для моей конкретной ситуации заключается в том, что мы не хотим иметь все базы данных во всех узлах. Мы хотели бы иметь два узла (A & B) со всеми базами данных, а остальные - с разными его подмножествами. По этой причине я думаю о том, чтобы сделать это:
Поскольку я не эксперт по топологии сети, я хотел бы спросить:
- Разве это не хорошая идея, чтобы реплицировать все узлы против всех узлов?
- Это разумная топология (последняя показана)?
- Где я могу узнать больше об этом?
Для полноты картины были созданы следующие команды Mathematica:
Graph[Rule @@@ Permutations[CharacterRange["A", "G"], {2}], VertexLabels -> "Name"]
Graph[Rule @@@ (Partition[CharacterRange["A", "G"], 2, 1, {-1}] /. {a_, b_} :> Sequence[{a, b}, {b, a}]), VertexLabels -> "Name"]
Graph[Flatten[Outer[{#1 -> #2, #2 -> #1} &, {"A", "B"}, CharacterRange["C", "G"]]~Join~{"A" -> "B", "B" -> "A"}], VertexLabels -> "Name"]
1 ответ
У меня нет особого опыта работы с семью узлами (но с тремя узлами), но не должно быть проблем с репликацией каждого узла друг на друга. Я делаю это также с тремя узлами, которые я использую в наших проектах. CouchDB создан для поддержки нескольких основных настроек узлов. Но вы также правы, думая об используемой полосе пропускания при репликации на такое количество узлов со многими соединениями. Я предлагаю вам следить за этим.
CouchDB следует теореме CAP с AP: доступность и допуск раздела. Это означает, что данные в конечном итоге непротиворечивы (см. http://guide.couchdb.org/draft/consistency.html). Поэтому вам также следует подумать о разделении ваших данных, что приведет к другой настройке, которую вы показали выше.
Или вы можете взглянуть на CouchDB 2.0, который был выпущен 20 сентября. Теперь CouchDB поддерживает кластеризацию. Я уверен, что это может решить вашу проблему. Предложенная установка состоит в том, чтобы запустить кластер с, по крайней мере (естественно) тремя узлами (n), содержащими 8 осколков (q) в каждом узле ( https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/). Использование репликации по-прежнему возможно, и я думаю, что это может быть способом уменьшить ваши настройки (хотя я не знаю, почему вы думаете о настройке из семи узлов).