一、基本概念
诸如历史消息查询、历史记录查询等,当数据量变得超过数百万数千万乃至上亿级别,关系型数据库必然要走向sharding,
但具体的sharding方案往往绑定着一些列的业务和产品设计,比如特定的用户查询方式,如何设计sharding键等等。
本文试图探讨从另一种技术栈也就是nosql来解决大数据量查询与存储的问题,并比较传统关系型数据库与nosql在实践中各自的优势。
Hbase底层存储基于hadoop的hdfs,使用zk作为分布式协调的分布式nosql数据库。facebook用hbase来作为其消息数据库。
Phoenix是针对Hbase的sql解析引擎,相对于hive,凤凰专用于hbase,拥有更好的优化性能。phoenix支持jdbc协议。
二、软件架构
用springboot做基本架构,HirakiCP连接池来封装phoenix jdbc connection来连接hbase
三、关于HBase表的设计
HBase的表的查询都是从一个Rowkey出发,只能做基于Rowkey的精准查询、范围查询和全表扫描。实践中一般是用Rowkey + 1、2个列族来设计表。
举个列子:比如要存储上亿的订单数据、以及十亿级别的订单明细数据(1个订单会有多个商品的购买)。
如果数据量级不大,比如百万或以下级别,真没必要用HBase了,MySQL足够用且查询功能更丰富一些。
MySQL表:
订单表:订单ID,金额,用户ID,订单时间,店铺ID等
订单明细表:订单明细ID,商品ID,金额,订单ID等
实际使用可能是1、根据订单ID查订单基本信息,2、根据订单ID查订单明细,3、根据用户ID查其订单等等
那么对应到HBase表,可以这么设计:
订单表
Rowkey: 订单ID , CF1:订单信息、里边包括订单基本信息的列(金额,用户ID,订单时间,店铺ID), CF2:订单明细表的IDs
订单明细表
Rowkey:订单明细ID,CF1:订单明细表的信息,里边包括订单明细表的列(商品ID,金额,订单ID)
查询使用,根据Rowkey订单ID查订单表、可以获得订单信息以及该订单下的明细ID,根据Rowkey订单明细ID可以查询该明细的商品ID,金额,订单ID
如果要根据用户ID获得其订单数据和明细,那还需要再建立一张用户与订单的关联表:
Rowkey:用户ID + 订单ID + 时间, CF1:订单基本信息。对Rowkey做scan即可。
HBase的Rowkey是顺序排列的,然后为了使得Rowkey的分布具有离散性,能够比较均匀的分布在各个Region上,一般会对Rowkey加个hash,或者做Reverse反转,使得其具有无规则随机性。
参考:
NoSQL 的选择 -- Redis、MongoDB、Cassandra 与 HBase 的介绍与比较 : https://techlog.cn/article/list/10182729
入门HBase,看这一篇就够了: https://www.jianshu.com/p/b23800d9b227
大数据查询——HBase读写设计与实践: https://cloud.tencent.com/developer/article/1032875
分库分表技术演进暨最佳实践 - 简书 (jianshu.com)