web-dev-qa-db-ja.com

CouchDBレプリケーションが推奨するトポロジ

私は、さまざまな国で7つのCouchDBサーバー（A、B、C、D、E、F、G）を備えたシステムの提案に取り組んでいます。アイデアは、すべてのデータの同期を維持できるようにマルチマスターレプリケーションを構成することです。

各サーバーから他のサーバーへの双方向レプリケーションを構成できます

Mathematica graphics

しかし、これにより接続が多すぎて、使用帯域幅が増えることでパフォーマンスが低下する可能性があると思います（これは本当ですか？）。

だから私の次のアイデアは、リングのようにそれらを構成することです：

Mathematica graphics

これで、接続数が大幅に減り、各ノードが2つのサーバーに接続されるため、冗長性が維持されます。私の特定の状況での問題は、すべてのノードにすべてのデータベースを配置したくないということです。すべてのデータベースを備えた2つのノード（AとB）と、異なるサブセットを備えた残りのノードが必要です。このため、私はこれを行うことを考えています：

Mathematica graphics

私はネットワークトポロジの専門家ではないので、質問したいと思います。

  • すべてのノードに対してすべてのノードを複製することは本当に良い考えではありませんか？
  • これは妥当なトポロジですか（最後に表示）？
  • これについてどこでもっと知ることができますか？

完全を期すために、図は次の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"]
replicationcouchdbtopologynetwork-topology
1
gdelfino

私は7つのノード（ただし3つのノード）で特別な経験はありませんが、各ノードを相互に複製することにまったく問題はないはずです。これは、プロジェクトで使用する3つのノードでも行います。 CouchDBは、ノードのマルチマスターセットアップをサポートするように構築されています。しかし、多くの接続を持つその多くのノードに複製するときに使用される帯域幅について考えることも正しいです。これを監視することをお勧めします。

CouchDBは、APのCAP定理（可用性とパーティションの許容範囲）に従っています。つまり、データは結果整合性があります（ http://guide.couchdb.org/draft/consistency.html を参照）。したがって、データをパーティション化することについても検討する必要があります。これにより、上記で示した別のセットアップが発生します。

または、9月20日にリリースされたCouchDB2.0をご覧ください。現在、CouchDBはクラスタリングをサポートしています。これで問題が解決することは間違いありません。提案されたセットアップは、少なくとも（当然のことながら）3つのノード（n）が各ノードに8つのシャード（q）を保持するクラスターを実行することです（ https://blog.couchdb.org/2016/08/01/couchdb -2-0-アーキテクチャ/ ）。レプリケーションを使用することはまだ可能であり、セットアップを減らす方法になると思います（ただし、7ノードのセットアップについて考えている理由はわかりません）。

http://docs.couchdb.org/en/2.0.0/index.html

1
awenkhh