[解決済み] Zookeeper vs インメモリデータグリッド vs Redis

質問

複数のリソースで、異なるzookeeperの定義が見つかりました。もしかしたら文脈から外れているものもあるかもしれませんが、それらを見てみてください。

1. <ブロッククオート

   Zookeeperの典型的な使用例として、分散メモリ計算が挙げられます...

2. <ブロッククオート

   ZooKeeperは、クラスタ間の同期を可能にする集中型インフラとサービスを提供するオープンソースのApache™プロジェクトです。

3. <ブロッククオート

   Apache ZooKeeperは、オープンソースのファイルアプリケーションプログラムインタフェース（API）であり、大規模システム内の分散プロセスが互いに同期し、リクエストを行うすべてのクライアントが一貫したデータを受け取ることができるようにします。

RedisやHazelcastと比較すれば、Zookeeperを理解しやすいと思うのですが。

ZookeeperとインメモリデータグリッドやRedisとの比較をお願いします。

1. 分散メモリ計算の場合、zookeeperとin-memory-data-gridはどう違うのでしょうか？
2. クラスタ間の同期をとる場合、他のすべてのインメモリストレージとどう違うのですか？同じインメモリデータグリッドでも、クラスタ全体のロックを提供するものがあります。Redisもある種のトランザクションを持っています。
3. インメモリで一貫性のあるデータということであれば、他の選択肢もあります。Imdgでも同じことが実現できますよね？

どのように解決するのか？

https://zookeeper.apache.org/doc/current/zookeeperOver.html

デフォルトでは、Zookeeperはすべてのデータを各ノードに複製し、クライアントがデータの変更を監視します。変更は非常に高速に(一定時間内に)クライアントに送信されます。また、quot;ephemeral nodes" を作成し、クライアントが切断した場合、指定時間内に削除することができます。ZooKeeper は、以下のように高度に最適化されています。 読み取る 一方、書き込みは非常に遅い（一般に、書き込みが行われるとすぐにすべてのクライアントに送信されるため）。Zookeeperのファイル(znode)の最大サイズは1MBであるが、通常は単一の文字列であろう。

このことから、zookeeperは多くのデータを保存するものではなく、またキャッシュでもないことがわかる。その代わりに、ハートビートの管理、どのサーバがオンラインであるかの把握、設定の保存と更新、そして場合によってはメッセージパッシングを行います（ただし、大量のメッセージや高いスループットが必要な場合は、RabbitMQなどの方がより適しているでしょう）。

基本的に、ZooKeeper（とそれをベースにしたCurator）は、ハートビート、更新や設定の分散、分散ロックなど、クラスタリングの仕組みを扱う手助けをします。

Redisとは比較にならないのですが、具体的な質問には......。

1. 計算をサポートしておらず、ほとんどのデータセットで、パフォーマンスを維持したままデータを保存することはできません。

2. クラスタ内の全ノードに複製される（Redisクラスタリングのようにデータを分散できるものはない）。すべてのメッセージは完全にアトミックに処理され、シーケンシングされるため、実際のトランザクションは発生しない。また、znode自体にも多くのロックプリミティブがあり、どのノードがアクセスするかを制御することができます。

3. 確かに、でもZooKeeperはニッチを埋めているんです。これは、分散アプリケーションを複数のインスタンスでうまく動作させるためのツールであり、大量のデータを保存・共有するためのものではありません。この目的のためにIMDGを使うのと比べると、Zookeeperはより速く、ハートビートと同期を予測可能な方法で管理し（この部分を簡単にするための多くのAPIがある）、quot;pull"の代わりにquot;push"のパラダイムを持っているのでノードには非常に速く変更が通知されることになります。

リンク先の質問から引用すると...。

Zookeeperの典型的な使用例として、分散メモリ計算が挙げられます。

...は、IMOでは、少し誤解を招く表現です。データを提供するのではなく、計算を指揮するために使用するのです。例えば、あるテーブルの1行目から100行目までを処理するとします。1-10」「11-20」「21-30」といった名前のZKノードを10台設置するとします。クライアントアプリケーションは、この変更を ZK によって自動的に通知され、最初のアプリケーションは "1-10" を取得して、エフェメラルノードを設定します。 clients/192.168.77.66/processing/rows_1_10

次のアプリケーションはこれを見て、次のグループを処理しに行く。実際に計算するデータは別の場所（例えばRedisやSQLデータベースなど）に保存されます。もし、計算の途中でノードに障害が発生した場合、別のノードがこれを見て（30-60秒後）、再びジョブを拾います。

ZooKeeperの典型的な例は、リーダー選挙だと思いますが。3つのノードがあり、1つがマスター、残りの2つがスレーブだとします。マスターがダウンした場合、スレーブノードが新しいリーダーになる必要があります。このようなことは、ZKにぴったりです。