17

私は最近、Paxosの論文、FLPの定理などを読み、プロジェクトのApacheZookeeperを評価しています。私はまた、Chubby（Googleの分散ロックサービス）と、オンラインで入手できるさまざまな文献を調べてきました。Zookeeperの基本的なユースケースは、分散システムのレプリケーションと一般的な調整を実装することです。

しかし、私はただ疑問に思っていましたが、ZookeeperまたはChubbyのような分散ロックシステムがテーブルにもたらす具体的な利点は何ですか。基本的に、MySQLNDBクラスターを使用できないのはなぜだろうと思っています。MySQLには多くのレプリケーションの問題があると聞き続けています。私は、このテーマについてより多くの経験を積んだ人が、それに光を当てることを望んでいました。

前もって感謝します..

私の要件の単純なリスト：

  • 私は同種の分散システムを持っています。
  • すべてのノードで一貫した状態を維持するための何らかの手段が必要です。
  • 私のシステムはサービスを公開しており、クライアントとのやり取りは私のシステムの集合的な状態に何らかの変化をもたらします。
  • 高可用性が目標であるため、ノードがダウンしてもサービスに影響を与えてはなりません。
  • 私は、システムが少なくとも1000req/秒のサービスを提供することを期待しています。
  • システムの集合的な状態はサイズに制限があると思います（基本的に挿入/削除は一時的なものになります...しかし定常状態では、多くの更新と読み取りが必要です）
4

2 に答える 2

18

管理しているデータの種類と、目的のスケールとフォールトトレランスによって異なります。

ZooKeeperの観点から答えることができます。始める前に、ZooKeeperはChubbyクローンではないことをお伝えしておきます。具体的には、直接ロックを行いません。また、さまざまな順序とパフォーマンスの要件を念頭に置いて設計されています。

ZooKeeperでは、システム状態のコピー全体がメモリに常駐します。変更は、アトミックブロードキャストプロトコルを使用して複製され、処理される前に、ZooKeeperサーバーの大部分によって（変更ジャーナルを使用して）ディスクに同期されます。このため、ZooKeeperは、サーバーの大部分が稼働している限り、障害に耐えることができる決定論的なパフォーマンスを備えています。停電などの大規模な停止が発生した場合でも、サーバーの大部分がオンラインに戻っている限り、システムの状態は維持されます。保存される情報はZooKeeperであり、通常はシステムのグラウンドトゥルースと見なされるため、このような一貫性と耐久性の保証は非常に重要です。

ZooKeeperが提供するその他のことは、動的な調整状態の監視と関係があります。エフェメラルノードを使用すると、障害の検出とグループメンバーシップを簡単に行うことができます。注文保証により、リーダー選出とクライアント側のロックを行うことができます。最後に、時計を使用すると、システムの状態を監視し、システムの状態の変化にすばやく対応できます。

したがって、動的構成の管理と対応、障害の検出、リーダーの選出などが必要な場合は、ZooKeeperが最適です。大量のデータを格納する必要がある場合、またはそのデータのリレーショナルモデルが必要な場合は、MySQLの方がはるかに優れたオプションです。

于 2010-02-23T22:19:03.673 に答える
13

MySQLとInnodbは、優れた汎用ソリューションを提供し、それほど高価ではないハードウェアでパフォーマンス要件に非常に簡単に対応できる可能性があります。適切なディスクを備えたデュアルクアッドコアボックスで、1秒あたり数千の更新を簡単に処理できます。組み込みの非同期レプリケーションを使用すると、可用性要件にほとんど対応できますが、プライマリに障害が発生すると、数秒分のデータが失われる可能性があります。この失われたデータの一部は、プライマリが修復されたときに回復可能であるか、アプリケーションログから回復可能である可能性があります。これを許容できるかどうかは、システムの動作に依存します。損失は​​少ないですが、速度は遅くなりますが、プライマリユニットとフェールオーバーユニットの間で共有ディスクを使用してMySQL Innodbを使用することもできます。この場合、フェールオーバーユニットは、プライマリに障害が発生してもデータを失うことなくディスクを引き継ぎます。ただし、プライマリに何らかのディスクの大惨事が発生していない場合に限ります。共有ディスクが使用できない場合は、DRBDを使用して、ディスクブロックを書き込み時にフェイルオーバーユニットに同期的にコピーすることでこれをシミュレートできます。これは、パフォーマンスに影響を与える可能性があります。

Innodbと上記のレプリケーションソリューションの1つを使用すると、データがフェールオーバーユニットにコピーされます。これは、リカバリの問題の大部分が解決されますが、フェールオーバーユニットをオンラインにするためにシステムを再構成するには、追加の接着剤が必要です。これは通常、RHCS、Pacemaker、Heartbeat（Linuxの場合）などのクラスターシステム、またはWindows用のMSClusterのものを使用して実行されます。これらのシステムはツールキットであり、環境に適したソリューションにそれらを構築するために手を汚す必要があります。ただし、これらすべてのシステムでは、プライマリに障害が発生したことをシステムが認識し、フェイルオーバーユニットを使用するようにシステムを再構成する間、短時間の停止期間があります。これは数十秒かかる場合があります。これを減らすと、障害検出システムの感度が高くなりすぎる可能性があります。

上に移動すると、MySQL NDBはリカバリまでの時間を短縮し、パフォーマンスを向上させるためにデータベースをある程度スケールアップすることを目的としています。ただし、MySQLNDBの適用範囲は非常に狭いです。システムはリレーショナルデータベースを分散ハッシュテーブルにマップするため、テーブル間の複数の結合を含む複雑なクエリの場合、MySQLコンポーネントとストレージコンポーネント（NDBノード）の間にかなりのトラフィックがあり、複雑なクエリの実行が遅くなります。ただし、適切なクエリは実際に非常に高速に実行されます。私はこの製品を数回見ましたが、既存のデータベースは複雑すぎてうまく収まらず、優れたパフォーマンスを得るには多くの再設計が必要になります。ただし、新しいシステムの設計段階にある場合は、その制約を念頭に置いておくことができれば、NDBはうまく機能します。また、

MySQL NDBでさえ、サイト全体の損失（データセンターでの火災、管理者エラーなど）に対処できません。この場合、通常、DRサイトに対して実行されている別のレプリケーションストリームが必要です。これは通常非同期で行われるため、サイト間リンクの接続ブリップによってデータベース全体が停止することはありません。これはNDBの地理的複製オプション（有料の電話会社バージョン）で提供されますが、MySQL5.1以降はこれをネイティブに提供できると思います。

残念ながら、私はZookeeperとChubbyについてほとんど知りません。うまくいけば、他の誰かがこれらの側面を理解することができます。

于 2010-02-22T10:17:37.537 に答える