分布式数据库HBase表设计
比较常用的数据库是关系型数据库，但很多场景下nosql数据库会更加擅长，从sql到nosql实施的第一步就是设计表结构，这是两种不同的思维方式，这里说下HBase表设计。
需求：需要一张stock表用于保存市场所有股票的分钟走向，即每个股票每分钟记录一次价格。
方案一：瘦表。
- 用stockId+datetime作为RowKey，这样方便通过stockId或datetime快速扫描获取到相关记录。
| RowKey | ColumnFamily “stock_cf” |
|---|---|
| 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个。
| RowKey | ColumnFamily “stock_cf” | ||
|---|---|---|---|
| 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源码及其维护的相关的文章。
智能推荐
注意！
本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。