hbase快速入门之---表设计(使用建议)

本文探讨了HBase表设计的几个关键方面,包括ColumnFamily的使用限制、压缩技术的选择、Bloomfilter的应用以及Rowkey的设计策略。文章还讨论了不同场景下Rowkey设计的最佳实践,如数字Rowkey的逆序存储、多字段查询的整合等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

ØColumn Family
建议不要在一张表里定义多个的column family。目前Hbase并不能很好的处理超过2~3column family的表。因为某个column familyflush的时候,它邻近的column family也会因关联效应被触发flush,最终导致系统产生更多的I/O
Ø使用压缩
由于HBaseKeyValue的存储特性,使用压缩减少对硬盘和网络的压力,从而提高集群的整体吞吐量。推荐使用snappy压缩。
Ø开启Bloom filter
开启Bloom filter HBase可以利用Bloomfilter来提高查询性能,但是会增加存储的开销。
ØRowkey设计
数字rowkey的从大到小排序:hbase只支持从小到大的排序,这样就对于排行榜一类的查询需求很尴尬。那么采用rowkey = Integer.MAX_VALUE-rowkey的方式将rowkey进行转换,最大的变最小,最小的变最大。在应用层再转回来即可完成排序需求。
对于多字段查询的情况,可以把考虑多个查询条件拼在rowkey中。这样既能满足多条件查询,又能有很快的查询速度。
如果rowkey是类似时间戳的方式递增的生成,建议不要使用正序直接写入rowkey,这样容易产生所有新数据都在一个regionserver上堆积的现象,影响性能。可以考虑采用reverse的方式反转rowkey,使得rowkey大致均衡分布,这样设计有个好处是能将regionserver的负载均衡。

以下我给了一些使用 HBase 时候对表格设计的一些建议,读者也可以理解背后的含义。不过我并不希望这些建议成为使用 HBase 的教条,毕竟也有不尽合理的地方。首先,一个 HBase 数据库是否高效,很大程度会和 Row-Key 的设计有关。因此,如何设计 Row-key 是使用 HBase 时,一个非常重要的话题。随着数据访问方式的不同,Row-Key 的设计也会有所不同。不过概括起来的宗旨只有一个,那就是尽可能选择一个 Row-Key,可以使你的数据均匀的分布在集群中。这也很容易理解,因为 HBase 是一个分布式环境,Client 会访问不同 Region Server 获取数据。如果数据排布均匀在不同的多个节点,那么在批量的 Client 便可以从不同的 Region Server 上获取数据,而不是瓶颈在某一个节点,性能自然会有所提升。对于具体的建议我们一般有几条:
  1. 当客户端需要频繁的写一张表,随机的 RowKey 会获得更好的性能。
  2. 当客户端需要频繁的读一张表,有序的 RowKey 则会获得更好的性能。
  3. 对于时间连续的数据(例如 log),有序的 RowKey 会很方便查询一段时间的数据(Scan 操作)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值