HBase里的优秀行键设计

Posted 大数据和人工智能躺过的坑

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HBase里的优秀行键设计相关的知识,希望对你有一定的参考价值。

 

  我们通过行键访问HBase。尽管使用扫描过滤器可以一次性指明大量的键,但是HBase仅仅能够根据行键识别出一行。

优秀的行键设计可以保证良好的HBase性能。

  1、行键存在于HBase中的每一个单元格中。如果行键越长,用于存储单元格的I/O开销就会越大。通常我们采用MD5加密的定长键来代替行键。

  2、对于组合式行键,每个组件的排序顺序取决于访问模式

    如果是一个以主机名和事件类型存储的日志数据库,可能的键值选取方法有以下几种:

    [主机名][事件类型][时间戳] :适用于访问模式使用主机名和事件类型查询日志的方式。

    [事件类型][时间戳][主机名] : 适用于访问模式使用事件类型和时间戳查询日志的方式。

    [事件类型][反转时间戳][主机名] : 反转时间戳的值是Long.MAX_VALUE减去时间戳,这样可以确保最近发生的时间排在前面。适用于按照事件发生顺序进行处理的场合。

 

  

  1.  单调递增的行键/时序数据

         在一个集群中,一个导入数据的进程一动不动,所有的client都在等待一个region(就是一个节点),过了一会后,变成了下一个region...如果使用了单调递增或者时序的key就会造成这样的问题。使用了顺序的key会将本没有顺序的数据变得有顺序,把负载压在一台机器上。所以要尽量避免时间戳或者(e.g. 1, 2, 3)这样的key。

  2. 尽量最小化行名和列名的字段大小

        在HBase中,值是作为一个单元(Cell)保存在系统的中的,要定位一个单元,需要行,列名和时间戳。通常情况下,如果你的行和列的名字要是太大(甚至比value的大小还要大)的话,你可能会遇到一些有趣的情况。在HBase的存储文件中,有一个索引用来方便值的随机访问,但是访问一个单元的坐标要是太大的话,会占用很大的内存,这个索引会被用尽。所以要想解决,可以设置一个更大的块大小,当然也可以使用更小的列名。压缩也能得到更大指数。大部分时候,小的低效不会影响很大。不幸的是,这里会是个问题。无论是列族,属性和行键都会在数据中重复上亿次。所以我们设计habse时候尽量遵循以下几点:

    一. 尽量使列族名小,最好一个字符

    二. 虽然详细属性名易读,最好还是用短属性名 (e.g., "via") 保存到HBase.不建议使用详细属性名

    三. 让行键短到可读即可,这样对获取数据有用(e.g., Get vs. Scan)。 短键对访问数据无用,并不比长键对get/scan更好。设计行键需要权衡。

    四. long 类型有 8 字节. 8字节内可以保存无符号数字到18,446,744,073,709,551,615. 如果用字符串保存--假设一个字节一个字符--,需要将近3倍的字节数。

  3. 倒序时间戳

        一个数据库处理的通常问题是找到最近版本的值。采用倒序时间戳作为键的一部分可以对此特定情况有很大帮助。也在Tom White的Hadoop书籍的HBase 章节能找到: The Definitive Guide (O‘Reilly), 该技术包含追加(Long.MAX_VALUE - timestamp) 到key的后面,如 [key][reverse_timestamp].表内[key]的最近的值可以用[key]进行 Scan 找到并获取第一个记录。由于 HBase 行键是排序的,该键排在任何比它老的行键的前面,所以必然是第一个。

  4. 行键永远不变

       行键不能改变。唯一可以“改变”的方式是删除然后再插入。这是一个网上常问问题,所以要注意开始就要让行键正确

以上是关于HBase里的优秀行键设计的主要内容,如果未能解决你的问题,请参考以下文章

HBase 行键设计

hbase 的最佳行键设计

HBase 模式行键设计 - 增量计数器?

hbase 利用rowkey设计进行多条件查询

Hbase 性能行键与列限定符

HBASE表设计