Hbase案例分析（二）

情景1：

如英文所示， 这个最基本的优势是可以根据时间范围进行扫描。但不满足我们的需求，我们要统计某一个metric（指标）在某时间范围的数据。

情景2：

情景2注释：将指标名称放到时间戳前面，这样会相同metric的数据会在一块，实现了一定的数据本地性，加快了扫描速度。但依然不满足需求：因为每个key在row的所有column里都会存一份，昂贵了。有些metric 名称可能很长。

情景3：

那如何节省空间呢？ 对 metric name 进行编码，单独弄一个表存储metric name及其编码。 　　注意lookuptable的设计模式，key val 可以互换查询。
缺点：行数依然太多了。

take 4

一行存多个数据，有点：扫描一行就可以拿出很多数据。【法则1：宽的行比窄的行，scan要更加高效】

take5

“宽行”是否节省了空间呢？
实际的物理存储如图的下部所示，并没有节省空间。

是不是一个metric（指标）存一行（无数咧）呢？ 这样也不行，对hbase性能也有影响。
那什么时候开始一个新的行呢？

大约600列，10分钟后，切换到另外一个行。
是用程序检查，每600秒（10分钟）就换一个行。

那如何节省空间呢？  如图所示即可。将两行压缩为一行。