HBase の根底にある HDFSのライト ワンスの制約を考慮すると、 HBase をデータベースとして使用して、頻繁に変更される数千万人のユーザーのユーザーごとの設定値を管理することは不適切に思えます。ここでの設定値は、たとえば、ユーザーの個人情報 (誕生日、電話番号、電子メール アドレスなど) の可視性を制御するためのブール値と、個人情報の可視部分へのアクセスを誰に許可するかを制御するための友人ごとのフラグです。HBase が複数の変更を HDFS への 1 つの書き込みにマージしたとしても、ユーザーが設定値を変更するたびにストレージ サイズがどんどん大きくなっていくのではないかと心配しています。
ただし、本当に不適切かどうかはわかりません。私の理解は間違っているかもしれません。これについてコメントをいただけますか？
HBaseがファイルシステムに使用するHDFSは、追加専用のファイルシステムです。つまり、ファイルの一部が上書きされることはありません。新しい変更は、CouchDBのように、古い変更の上にパックされます。
ただし、CouchDBとは異なり、HBaseは独自の分割と圧縮を管理します。
StoreFileのクリーンアップには、主要な圧縮が絶対に必要であることを強調することが重要です。唯一の変形は、それらが発生したときです。これらは、HBaseシェルまたはHBaseAdminを介して管理できます。
圧縮中に、古いデータが解放され、スペースが解放されます。
頻繁に変更されるデータを独自の列ファミリーに分離し、圧縮をオンにする必要があります。残念ながら、現時点では、フラッシュは列ファミリーごとではなくグローバルに実行されますが、HBase-3149はそれに対処しています。
私はあなたの質問に直接答えると思います、はい、HBaseは頻繁に変更されるデータを保存できます。誰かに設定ページを注意深く読んでもらい、状況に応じて適切な決定を下してもらうようにしてください。
ジェイコブの答えを少し拡張すると、HBase が頻繁に変更される値に適している理由を理解するには、Log Structured Merge Treesのアプローチを理解する必要があります。
一般的なリレーショナル データベース (B+ ツリーと「その場で更新」セマンティクスを使用) とは異なり、HBase へのすべての書き込みは、タイムスタンプ付きの追加として扱われます。PUT を実行するたびに、それが新しい値 (RDBMS 言語では "INSERT") であるか、既存のキー (RDBMS 言語では "UPDATE") であるかに関係なく、次の 2 つのことが起こります。
次回、それを保証するのに十分な新しいものがメモリ内にある場合、メモリ内のものはディスクにフラッシュされます (これも、既にソートされているため、かなり高速です)。また、テーブルで使用した設定によっては (たとえば、過去のバージョンをたくさん保持するかどうか、削除された値を保持するかどうかなど)、古いバージョンの値がフラッシュ時にすぐに消去される場合があります。時間も。
ただし、どちらの場合でも、時間の経過とともに、1 つの値の異なるバージョンが複数のストア ファイルに格納される可能性があり、1 回の読み取りで多くのストア ファイルをヒットする必要があることは明らかです。そこで、圧縮の出番です。多くのストア ファイルを 1 つに結合して、読み取りでそれを行う必要がないようにします。