HBase版本：0.97
1.Get
Gets实在Scan的基础上实现的。
2.联合查询(Join)
HBase是否支持联合是一个网上常问问题。简单来说 : 不支持。至少不像传统RDBMS那样支持。
但并不表示等价联合不能在应用程序中支持，只是必须自己做。 两种方法，要么指示要写到HBase的数据，要么查询表并在应用或MapReduce代码中做联合。
3.列族
一个表存在多列族，注意基数(如, 行数). 如果列族A有100万行，列族B有10亿行，列族A可能被分散到很多很多区(及区服务器)。这导致扫描列族A低效。
无论是列族，属性和行键都会在数据中重复上亿次。所以尽量使列族名小，最好一个字符。
每个Column Family单独存储：storeFile。
TTL
列族可以设置TTL秒数，HBase 在超时后将自动删除数据。影响 全部 行的全部版本 - 甚至当前版本。HBase里面TTL 时间时区是 UTC.
4.行键(RowKey)设计
OpenTSDB的Key的格式是[metric_type][event_timestamp]，乍一看，似乎违背了不将timestamp做key的建议，但是他并没有将timestamp作为key的一个关键位置，有成百上千的metric_type就足够将压力分散到各个region了。
5.倒序时间戳
一个数据库处理的通常问题是找到最近版本的值。采用倒序时间戳作为键的一部分可以对此特定情况有很大帮助。追加(Long.MAX_VALUE - timestamp) 到key的后面，如 [key][reverse_timestamp].
表内[key]的最近的值可以用[key]进行 Scan 找到并获取第一个记录。由于 HBase 行键是排序的，该键排在任何比它老的行键的前面，所以必然是第一个。
6.行健
行键不能改变。唯一可以“改变”的方式是删除然后再插入。
7.强一致性
同一行数据的读写只在同一台regionserver上进行；
仅支持单行事务，对行的写操作是始终是“原子”的
8.行事务
同一行的列的写入是原子的；
Column Oriented + 三维有序
SortedMap(RowKey,
List(SortedMap(Column,
List(Value,Timestamp))
)
)
rowKey (ASC) + columnLabel(ASC) + Version (DESC) --> value
9.不支持
1) 二级索引；
2) sql/join/跨行跨表等RDBMS特性；
特性
Being a FS, HDFS lacks the random read/write capability. It is good for sequential data access. And this is where HBase comes into picture. It is a NoSQL database that runs on top your Hadoop cluster and provides you random real-time read/write access to your data.Hadoop is most suited for offline batch-processing kinda stuff while HBase is used when you have real-time needs.HBase can't be used for classic transactional applications or even relational analytics.
HBase优化：
1.压缩
可以在列族上设置压缩算法。比较高效的压缩算法有snappy
2.写速度关键因素
Table region分布均衡；
单台region server的region数；
hbase.regionserver.handler.count
hbase.regionserver.global.memstore.upperLimit
hbase.hregion.memstore.block.multiplier
hbase.hstore.blockingStoreFiles
hbase.hregion.max.filesize
3.读速度关键因素
单台Region Server上的Region数；
StoreFile数；
bloomfilter；
in-memory flag;
blockcache设置；
hfile.block.cache.size;
修改compaction配置
hbase.regionserver.thread.splitcompactcheckfrequency 20s compaction检查周期
hbase.hstore.compactionThreshold 3 最小minor compaction的文件个数
hbase.hstore.blockingStoreFiles 7 Block flush操作的Store个数
hbase.hstore.blockingWaitTime 90s Block flush操作的等待时间
hbase.hstore.compaction.max 10 最大minor compaction的文件个数
hbase.hregion.majorcompaction 1 day Major compaction的周期
修改数据压缩格式
disable 'test'
alter 'test', NAME => 'f', COMPRESSION => 'snappy'
enable 'test'
major_compact 'test'
服务启动
启动集群中所有的regionserver
./hbase-daemons.sh start regionserver
启动某个regionserver
./hbase-daemon.sh start regionserver
安全：
1. 开启Kerberos安装认证、ACL控制
监控：
Minos:集群自动化发布和监控系统（小米开源）
目标>
1) 集群易配置、自动化部署和监控
2) 管理Hadoop集群：hbase/hdfs/zookeeper/yarn的统一方案
地址：https://github.com/xiaomi/minos
其它：
get请求会转换成scan
http://www.aboutyun.com/thread-7686-2-1.html
HBase架构
HBase的系统架构如图5-1所示，由如下几个核心部件组成:
- Client:
包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。
- ZooKeeper:
1 保证任何时候，集群中只有一个master；
2 存贮所有Region的寻址入口；
3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master；
4 存储Hbase的schema,包括有哪些table，每个table有哪些列族。
- Master:
1 为Region server分配region；
2 负责region server的负载均衡；
3 发现失效的region server并重新分配其上的region；
4 HDFS上的垃圾文件回收；
5 处理schema更新请求。
- Region Server:
1 Region server维护Master分配给它的region，处理对这些region的IO请求；
2 Region server负责切分在运行过程中变得过大的region；
可以看到，client访问HBase上数据的过程并不需要master参与(寻址访问zookeeper和region server，数据读写访问regione server)，master仅仅维护者table和region的元数据信息，负载很低。 
图5-1 HBase架构
HBase数据结构如图5-2所示， HBase的数据组织有如下几个特点：
- HBase中一张表(HTable)由多个HRegion组成，这些Region可能被HMaster分配到不同的HRegionServer中。每一个HRegion中包含一个或多个Store，每个Store代表一个列族。一个Store由一个MemStore和0到多个StoreFile组成，其中StoreFile是HFile(HBase实际数据存储文件格式)的轻量级包装。同一个HRegionServer中的所有HRegion共享一个预写日志HLog。
- HRegion是HBase分布式存储和负载均衡的最小单元，一个HRegion不会被拆分到不同的HRegionServer上。
- HRegion并不是HDFS的最小存储单元，上面这些文件按照HDFS块的方式存储在HDFS的多个DataNode中。
图5-2 HBase数据结构