7

シャーディング（MongoDBなど）と分散ファイルシステム（HBaseやHyperTableのHDFSなど）は、データベースがスケールアウトに使用するさまざまなメカニズムであると理解している限り、それらをどのように比較するのでしょうか。

4

1 に答える 1

17

従来のシャーディングでは、テーブルを少数のピースに分割し、各ピース（または「シャード」）を別のマシンの別のデータベースで実行します。シャードのサイズが大きいため、このメカニズムは、Foursquareインシデントによって証明されたように、ホットスポットと不均等な成長のために不均衡になりがちです。。また、各シャードは別々のマシンで実行されるため、これらのシステムでは、マシンの1つがダウンした場合に可用性の問題が発生する可能性があります。この問題を軽減するために、MongoDBを含むほとんどのシャーディングシステムはレプリカグループを実装しています。各マシンは、マスター構成と2つのスレーブ構成の3台のマシンのセットに置き換えられます。このようにして、マシンがダウンした場合、データを提供するためのレプリカが2つ残っています。この設計にはいくつかの問題があります。まず、レプリカがレプリカグループで失敗し、グループに2つのメンバーしか残っていない場合、レプリケーションカウントを3に戻すには、これら2つのマシンのいずれかのデータを次のようにする必要があります。クローン化されます。レプリカの再作成に使用できるマシンはクラスター全体で2台しかないため、膨大な数になります。再複製が行われている間にこれら2台のマシンのいずれかをドラッグすると、問題のシャードで深刻なパフォーマンスの問題が発生します（ギガビットリンクを介して1TBをコピーするには2時間以上かかります）。2番目の問題は、レプリカの1つがダウンしたときに、新しいマシンと交換する必要があることです。レプリケーションの問題を解決するためにクラスター全体に十分な予備容量がある場合でも、その予備容量を使用して状況を修正することはできません。それを解決する唯一の方法は、マシンを交換することです。これは、クラスターのサイズが数百または数千のマシンに成長するにつれて、運用の観点から非常に困難になります。

Bigtable + GFSの設計は、これらの問題を解決します。まず、テーブルデータは、より細かい「タブレット」に分割されます。Bigtableクラスターの一般的なマシンには、多くの場合500以上のタブレットがあります。不均衡が発生した場合、それを解決するには、あるマシンから別のマシンに少数のタブレットを移行するだけです。TabletServerがダウンした場合、データセットが細かく分割されて複製されるため、リカバリプロセスに参加するマシンが数百台存在する可能性があります。これにより、リカバリの負担が分散され、リカバリ時間が短縮されます。また、データは特定の1つまたは複数のマシンに関連付けられていないため、クラスター内のすべてのマシンの予備容量を障害に適用できます。

  • Hypertable Inc.、ダグジャッドCEO
于 2011-08-06T06:17:26.223 に答える