セカンダリインデックスの HBase API 実装には既知の制限があり、推奨されていません。代わりに、Lindorm SQL を使用してセカンダリインデックスを利用してください。
ApsaraDB for HBase Performance-enhanced Edition はネイティブなセカンダリインデックスを提供しており、全表スキャンを実行することなく任意のカラムでテーブルデータをクエリできます。
行キーのみによるクエリの課題
HBase は行を行キー（プライマリキー）のバイナリ順に格納します。このため、クエリが行キーに基づいている限り、行スキャン、プレフィックススキャン、範囲スキャンは高速かつ効率的です。
非行キーカラムでのクエリが必要な場合、HBase には該当する行への直接的なアクセス経路が存在しません。セカンダリインデックスがない場合、データベースはフィルターを適用して行キーの範囲を絞り込むか、テーブル全体をスキャンします。全表スキャンは I/O を浪費し、応答時間を増加させ、データ量の増加に伴ってスケーリング性が悪化します。
複数カラムクエリへの対応方法
ネイティブなセカンダリインデックスが利用可能になる前は、以下の 2 つの回避策が一般的でした。
| アプローチ | 動作原理 | 欠点 |
|---|---|---|
| 手動インデックステーブル | クエリカラムでインデックス化された別テーブルを作成 | 書き込みごとにインデックステーブルとプライマリテーブルの同期を維持する必要がある |
| 外部検索エンジン（Solr、Elasticsearch） | データを外部クラスターにエクスポートしてインデックス化 | 少数のカラムに対する一般的なクエリに対してリソースを大量消費 |
ApsaraDB for HBase Performance-enhanced Edition は、ApsaraDB for HBase に組み込まれたネイティブなセカンダリインデックスにより、上記両方の欠点を解消し、外部検索エンジンソリューションと比べてコストを削減します。
ネイティブなセカンダリインデックスの仕組み
カラムにセカンダリインデックスを作成すると、そのカラムに対するクエリはすべての行をスキャンする代わりにインデックス経由で解決されます。
ApsaraDB for HBase のネイティブなセカンダリインデックスは、高スループットおよび大規模データ向けに設計されています。この実装は、アリババグループ内で長年にわたり本番環境で使用されており、独身の日ショッピングフェスティバル期間中も運用されています。
次のステップ
Lindorm SQL の概要 — セカンダリインデックスを作成および使用する推奨方法