hbase rowKey设计

1，高表VS宽表

首先明确一个前提：将横坐标理解为列，将纵坐标理解为行

高表：行多列少

宽表：行少列多

下面以邮件系统为例：

 

HBase只能按行分片，因为Region拆分基于rowkey，所以当用户的某一行数据量太大（超过了最大HFile的限制），此时这个Region无法拆分（后果之一：不利于keyValue的筛选），对应的解决方案是将用户的每个电子邮件都存储在单独的一行中（方案一：高表）

 

高表设计方案是否是符合所有应用场景的呢？

当用户需要一次修改整个收件箱中的所有邮件的消息，因为数据分布在每一行中，所以需要跨多行处理此次修改，原子性成了突出的问题。因为hbase是基于rowkey划分region，而region分散（尽量避免region热点）在所有region服务器中，所以hbase客户端需要去访问所有的region服务器（查询的吞吐量会有所提升，因为需要扫描所有rowkey所在region的HFile，且只有部分rowkey对应的数据是我们需要的），尽管有一种解决方案能解决原子性问题（协处理器endpoint：在服务器进行跨Region处理），但是此种应用场景下使用宽表可能会更加合适

 

2，时间序列

有些数据（股票交易软件，监控系统等产生的数据）的行健都代表了事件发生的时间，这样的数据在存储时会出现一个问题：这些数据会被有序存储到一个特定的范围内，由于一个region只能被一个regionserver管理，所以所有的更新都会集中在一台服务器上，这样导致系统产生热点读写，由于写入数据过分集而导致整个系统性能下降，我们应该尽量避免这样的设计。解决方案有以下两种：

a，salting。可以使用salting前缀（将组合键中的时间戳向右移动）来保证数据分散到所有region服务器中，这样的缺点是用户要扫描一个连续的范围时，可能需要对每个region服务器发送请求，查询的吞吐量会有所提升。

b，行健随机化。这种方案适用于每次只读取一行的应用场景，因为行健随机化处理后，对于时间连续的数据，用户将不能再按时间范围扫描数据

 

3，时间顺序关系

当需要按时间顺序检索数据时，可以使用Long.MAX_VALUE-<data-as-long>方式组合行健，因为行健是顺序存储，反之使用<data-as-long>方式