比较常用的数据库是关系型数据库,但很多场景下nosql数据库会更加擅长,从sql到nosql实施的第一步就是设计表结构,这是两种不同的思维方式,这里说下HBase表设计。
需求:需要一张stock表用于保存市场所有股票的分钟走向,即每个股票每分钟记录一次价格。
方案一:瘦表。
- 用stockId+datetime作为RowKey,这样方便通过stockId或datetime快速扫描获取到相关记录。
stockId+datetime | stock_cf:price |
“00000120160615100000” | 10.02 |
“00000120160615100001” | 10.10 |
“00000120160615100002” | 10.08 |
“00000220160615100000” | 8.00 |
“00000220160615100001” | 8.10 |
“00000220160615100002” | 8.20 |
craete 'stock' , 'stock_cf'
优点:不受记录数限制,通过id查询时能很快跳过行,拥有很好的扩展性,高表也是推荐的用法。
缺点:不利于原子性,hbase只有行具备原子性。
方案二:宽表。
- 用stockId作为RowKey,datetime作为列,随着时间增长列会不断地增加,获取某个时间的记录将时间作为列。一个表的列族不要超过3个。
stockId | “stock_cf:20160615100000” | “stock_cf:20160615100001” | “stock_cf:20160615100003” |
000001 | 10.02 | 10.10 | 10.08 |
000002 | 8.00 | 8.10 | 8.20 |
craete 'stock' , 'stock_cf'
优点:更好的事务性。
缺点:宽表列数最多到百万级别,可扩展性较差。
后面有时间会写些hbase源码及其维护的相关的文章。