HBase を使用してユーザーのキー/値情報を保存するプロジェクトに取り組んでいます。現在、使用している HBase スキーマを再設計中です。議論されている 2 つのオプションは次のとおりです。
2 つのアプローチの設計上のトレードオフは何ですか? 一方が他方よりも好ましいですか？Avro または Thrift を使用してデータを保存しない理由はありますか?
要約すると、キーごとに個別の列を使用する傾向があります。
1) 明らかに、クライアントが別の依存関係である Avro/Thrift を使用することを課しています。この依存関係は、変換せずにデータ内の値を見つけることを期待する BI ツールなど、特定のツールの可能性を排除できることを意味します。
2) avro/thrift スキームの下では、ネットワークを介してすべての価値を提供することをかなり強制されます。行内のデータの量によっては、これは問題にならない場合があります。ただし、'city' フィールド/column-qualifier のみに関心がある場合でも、'payments' や 'credit-card-info' などを取得する必要があります。これはセキュリティ上の問題を引き起こす可能性もあります。
3) 更新が必要な場合、Avro/Thrift ではより困難になります。例: 「hasIphone6」キーを追加するとします。Avro/Thrift: 行を削除し、フィールドを追加して新しい行を作成する必要があります。列スキームの下に、新しい列のみを含む新しいエントリが追加されます。1行の場合、大きくはありませんが、これを10億行にすると、大きな圧縮操作が必要になります。
4) 構成されている場合、HBase で圧縮を使用できます。これは、単一のレコードだけでなく、列ファミリー全体で圧縮できるため、avro/thrift シリアル化を超える可能性があります。
5) HBase のような BigTable の実装は、非常に広く疎なテーブルで非常にうまく機能するため、予想されるようなパフォーマンスの低下はありません。
これに対する正しい答えはもう少し複雑なので、最初に tl;dr を示します。
Avro/Thrift/Protobuf を使用
レコードと列にパックするフィールドの数のバランスをとる必要があります。
cmonkey で述べたように、使用しない余分なデータを取得するオーバーヘッドが必要ないため、通常、頻繁にアクセスされるフィールド (元の質問の「キー」) を avro レコードのようなものに配置する必要があります。
行の幅を非常に広くすると、HFile の格納方法が原因で、列のサブセットをフェッチするときにシーク時間が長くなります。繰り返しますが、何が最適かを判断することは、アクセス パターンに帰着します。
また、avro のようなものを使用することで、進化可能性も提供していることを指摘したいと思います。行を削除して、新しいフィールドを含むレコードで再度追加する必要はありません。Avro には、下位互換性と上位互換性に関するルールがあります。これにより、データを書き換えたり、古いクライアント コードを強制的に更新したりすることなく、新しいレコードと古いレコードの両方を読み取ることができるため、作業が大幅に楽になります。
ほとんどの場合、HBase では圧縮を使用する必要があります (SNAPPY は常に適切な選択です)。