HBaseの元の主キーインデックスが提供され、ユーザは効率よくのrowKey、前方一致、クエリ動作範囲による単一の行を読み取ることができます。クエリに列のプロパティを使用する必要がある場合は、あなただけの検索にラインフィルタによるフィルタラインを使用することができます。大きな走査範囲、RT要求は保証できない、IOの多くを無駄にします。このため、HBaseのは非パフォーマンスのrowKeyクエリの問題を解決するために、元のセカンダリインデックスの強化版を発売しました。
クラウドHBaseのはハンドリング、パフォーマンスの面で、二重試験の11年後（またLindormとして知られている）アリの内部HBaseの枝の拡張バージョン、セカンダリインデックスは、そのコアコンピタンスの一つである上に構築されており、安定性は、コア競争力ありますさ。
ここでは、インデックスとその機能の使用を理解するために例のセットから開始します。
特長
ビューのテーブルデザイン、クエリデザインの観点から、HBaseのの拡張版のRDBMS二次インデックスを使用して基本的に同じセカンダリインデックス。簡単な例で見てみましょう：学生情報テーブル（Students）、テーブルのプライマリキー（すなわちのrowKey）は学校で、非プライマリキーは、学生の名前であり、大学の名前が属しています。大学生と一対一の関係に多くの。
HBaseのシェルテーブルの構築、インデックス化：
# 创建主表student，列族名为f
create 'student', 'f'
# 创建索引表department，为department列建索引
# COVERED_ALL_COLUMNS是HBase增强版引入的新属性关键字，
# 意味冗余主表student中的所有列，以此来避免回查主表
create_index 'department', 'student', {INDEXED_COLUMNS => ['f:departement']}, {COVERED_COLUMNS => ['COVERED_ALL_COLUMNS']}JavaのAPIを介したデータへのアクセス
// 定义一些常量
String id = "11"; // 一个随机的学号
String studentName = "Harry";
String department = "CS";
byte[] f = Bytes.toBytes("f");
byte[] qStudent = Bytes.toBytes("name");
byte[] qDepartment = Bytes.toBytes("department");
// 写入一个学生的数据
Put put = new Put(Bytes.toBytes(id));
put.addColumn(f, qStudent, Bytes.toBytes(studentName));
put.addColumn(f, qDepartment, Bytes.toBytes(department));
Table t = conn.getTable("student");
t.put(put); // put成功返回意味着主表和索引表都成功更新，变更立即可见
// 按department进行查询
Scan scan = new Scan();
SingleColumnValueFilter where = new SingleColumnValueFilter(
f, qDepartment, EQUAL, Bytes.toBytes(department));
scan.setFilter(where);
ResultScanner rs = t.getScanner(scan);
// 处理查询结果...HBaseのAPIで、見実施形態では、直接、インデックスからの照会要求を記述するために使用されます。HBaseの拡張バージョンを自動的インデックスが完全に冗長でない場合、上記の例では（主インデックステーブルをチェックするために戻ってくる調査が完了した後、必要に応じて、フィルタおよび照会のための最も適切なインデックスにインデックススキーマに従ってマッチされ、それはチェックを戻します列全体を埋めるために主テーブル）。使用に関する詳細な手順についてを参照してください。セカンダリインデックスの開発マニュアル。
セカンダリインデックスHBaseの拡張機能の主な特徴は次のとおり
- 複数のインデックスを構築するために、単一の主テーブルのサポート
- 単一の支持体および複数列インデックス（複合インデックス）
- 冗長インデックス：明示的に冗長列または指定することができ、すべての冗長列をメインテーブルリコールパフォーマンスの低下を避けるために、
- クエリの最適化：スキャンし、フィルタするためによると、自動的に必要に応じて、適切なインデックステーブルクエリを選択し、します自動的にチェックするために、メインテーブルに戻ります
- オンラインスキーマの変更：サポートは既に使用中のインデックステーブルを構築するために、メイン読むためにテーブルと書き込みには影響を及ぼしませんでした
- サポートTTL：TTLインデックステーブルは自動的にマスターテーブルを継承するには、メインテーブルとインデックスのデータテーブルで期限切れ
- ユーザー定義のタイムスタンプデータが書き込まれる（まだオープン）：データのカスタムバージョンのサポート
メリット
高性能
カーネルに直接組み込まセカンダリインデックスの拡張バージョンをHBaseの、そして深く最適化を行っている、強力なスループットとパフォーマンスを提供します。図下HBaseのコントラストは、性能指標との2 Apacheのフェニックスのグローバルインデックスのバージョンを強化します：
チャートから見ると、関係なく、RTやスループットの、二次インデックスははるかにApacheフェニックスの拡張バージョンよりもHBaseの。
読める書き込み後
データが書き込まれた後に正常のある程度提供する従来の非同期遅延索引付けスキーム排除するデータ、インデックスデータを直ちに読み取ることができる、返さ強度セマンティック整合性（データの整合性の主インデックステーブル）は、特定のセマンティック、次のように：
- クライアントに正常に書き込まれ、バック、あなたはその後すぐに（プライマリデータテーブルとインデックスを含む）だけで書き込まれたデータを読み取ることができ、書き込みプロセスを目に見えるを確保していないながら、
- エラーをIOタイムアウトまたは戻り、その後、時間の期間は、データの視認性にメインテーブルとインデックステーブルに決定しますが、どちらかのすべての成功、またはすべて失敗した最終合意ことを保証することはできません
HBaseの「は、ポストライト正常に更新直ちに可視セマンティクス」は、スパークなどの分散協調作業、データ更新中のノードのいくつかの数のために使用することができる、いくつかの他のノードが計算書き込ま上のデータを読み出すの拡張バージョンを提供します。この時点で、あなただけ書き込まれたデータを読み取ることができます。
完全な冗長性指数
完全な冗長インデックスができる完全チェックメインテーブルに戻って避けるだけでなく、性能を向上させる糖衣構文を、複雑なDDLの手動メンテナンスを避けます。以下が導入されました。
如果查询中需要的列在索引表中没有，则查完索引后，还需回查主表。在分布式场景下，回表查询会使得查询RT大幅度升高，最差情况下可能会回查主表的全部region，访问集群中的所有机器。此时，索引带来的性能收益已经可有可无。通过精良的查询设计和索引设计，我们可以在设计阶段避免回查，但随着业务发展变化，这个约束很难维持。因此，仍然需要冗余索引(Covered Index)来解决。
HBase增强版创造性的引入了全冗余索引的概念，即冗余主表中的所有列，以此来彻底避免回查主表。配合HBase的schema-free特性，主表中新增的任何列都会自动冗余到索引表中。无论业务模式如何变化，都不需要回查主表。
同时，全冗余也是可大幅度提升效率的语法糖，我们可以对比如下两个SQL语句：
CREATE INDEX idx ON dt (c1, c2) include(c3, c4, c5, c6, ....);
CREATE INDEX idx ON dt (c1, c2) include(ALL);对于大部分业务来说，表里有数十列是常态，个别表可能会有数百列。如果为了建冗余索引，而把这数百列的列名再写一遍，无疑是巨大的负担(只能写工具自动化做，人来做太容易出错)。全冗余索引的新语法给人工维护DDL提供了可能。
为了获得上述两点收益，全冗余索引的代价是会占用更多存储空间。配合HBase增强版深度优化的ZStandard压缩算法，可有效降低冗余带来存储开销。冷热分离特性亦可应用于索引表，进一步控制成本。
基于原生API的查询优化
对大部分场景来说，业务一行代码不改就能用上索引。
从本文开头的示例代码中可见：
- 写：写主表即可，会自动同步到索引，强一致。用户无需担心索引更新的问题
- 读：基于主表进行查询，直接按业务逻辑进行查询表达，系统自动选择合适的索引表进行查询
这样，用户只需为那些性能不好的查询设计并添加索引，即可从索引特性中受益，实际的数据读写代码一般不需要修改。同时，既有的HBase生态相关的产品，都可以无缝使用上索引。一些如Spring的框架软件也可帮助用户获得业务上的灵活性。
大表建索引
从一开始就设计好主表和全部索引几乎是不可能的。因此，在后续业务发展过程中，索引表可能需要不断的删除和新增。为此，对一个已经有大量数据表添加、删除索引，将是一个关键的运维操作。HBase增强版二级索引针对此场景做了特别的优化：
- schema在线修改：索引的变更不影响主表的正常读写(就像一次普通的alter表操作)，不影响其他索引表
- 服务端rebuild：在服务端为主表的历史数据构建索引
- 支持对超大主表添加索引：支持TB级别的主表添加新索引
- 流控：大主表的索引rebuild会消耗大量的系统资源，因此，精准的流控即可在兼顾索引构建速度的前提下，保障系统整体性能不会被影响
在有上述特性的加持下，索引变更的运维成本和风险大大降低，从容的适应业务发展。
原理简介
HBase增强版二级索引是一种全局二级索引，每个索引表都是一张独立的HBase表。每张表的主键(rowkey)设计决定了其能支持的查询模式。当同一份数据有多种rowkey组织时，就能支持多种查询模式。这里，主表和它的索引表，可以看做是同一份数据的不同组织形式，各自能够高效的支持一定的查询模式。
考虑本文开始时给出的学生信息表的示例：
主表Student：以学号(id)为主键(rowkey)，每行有两列，学生姓名(name)和所属的学院(department)。该设计仅支持按id进行查询。如果用户要按department或者name来查询，需要全表扫描 + filter。在学生数较少时，这种暴力扫描完全可行。但在数据量大时(数十万乃至上亿时)，这种操作是无法执行的。
为了高效的支持按department查询，可为其建立一个全冗余索引(使用HBase shell)：
create_index 'department', 'student', {INDEXED_COLUMNS => ['f:departement']}, {COVERED_COLUMNS => ['COVERED_ALL_COLUMNS']}インデックスを作成すると、システムが自動的に在庫データテーブルベースのインデックス意志、インデックステーブルが書かれています。メインテーブルの行とインデックス列は、一個です。更新されたテーブル上の主なデータは、自動的にインデックステーブルに同期した後に発生します。
次のクエリを考えてみます。
-- 查找所有计算机学院(cs)的学生的姓名(name)
select name from student where department = 'cs';このクエリは、直接部門の列プレフィックス一致に応じて、インデックステーブルをヒットします。クライアントに戻し、インデックス名フィールドラインのそれぞれから抽出します。
我々は、冗長性のインデックスを構築していない場合は、インデックステーブルのカラム名が存在しません。この場合、インデックステーブルは、学生番号（ID）から読み取るために、テーブルをもう一度確認する必要があり、マスターは、名前列を読み取るために（単一ラインは、IDによる三回の読み取り）。分散シナリオでは、10/12/13 IDの3つのデータは、3台のマシンに分散させることができます。そのため、4回のRPCを、合計3回のRPCにメインテーブルで、最悪の場合、プラスチェックRPCインデックステーブルを戻って確認する必要があります。インデックスが重複している場合は、あなただけのRPCインデックステーブル一度チェックする必要があります。
そのため、分散型のシナリオ、大きなノードクラスタの特に多くで、パフォーマンスコストをチェックするメインテーブルの裏には、（RTは数回を育てること）巨大です。チェックして、パフォーマンスを向上させるためには避けてバック：我々は完全に冗長なインデックスを設計した理由です。
概要
値を作成するためにのみクエリデータ、HBaseのネイティブ高性能二次インデックスは、多次元クエリの有効な解決策を提供します。テーブルの設計では、ユーザーは、インデックスデザインのアイデアMySQLとインデックスのHBaseに設計された他のリレーショナルデータベースを参照することができます。ビジネス、コードを変更せずに、クエリオプティマイザは、自動的にインデックステーブルを選択することができます。強い一貫性、完全冗長インデックスと他の特性も効果的ビジネスの使用のためのしきい値を減少させました。
将来的には、我々はさらに、インデックスを最適化し、質の高いユーザーエクスペリエンスを提供するように拡張されます。HBaseのの拡張版を体験して歓迎。あなたはHBaseのに関連した質問があれば、（釘は「クラウドHBaseのデューティ」で検索）釘にてご連絡下さい。