OpenTSDB设计解读

关于OpenTSDB的表设计，这两篇文章已经写得很好了：

[url]http://blog.csdn.net/bluishglc/article/details/31052749[/url]
[url]http://www.jianshu.com/p/0bafd0168647[/url]

但对于tsdb-uid这个表，我觉得还是可以说得更详细一点的。以第一个链接提到的例子为例：
我们插入2个metrics：

proc.stat.cpu
proc.stat.mem

以及一条记录：

proc.stat.cpu 1297574486 54.2 host=foo type=user

来观察一下结构

hbase scan：

[img]http://dl2.iteye.com/upload/attachment/0118/6826/31d25a64-2be4-3989-9010-b52cea4250a4.png[/img]


画个图更形象一点：

[img]http://dl2.iteye.com/upload/attachment/0118/6828/021eb6c3-6e1e-3dc5-9d01-0bb89811dac7.png[/img]

看到这个图，其实已经很清晰了：

1.rowKey=0的那一行，只有右边的columnFamily:id才会有值，它记录了metrics/tagk/tagv的个数。可以看到，现在metrics是两个（proc.stat.cpu和proc.stat.mem），tagk也是两个（host和type），tagv也是两个（foo和user）

2.rowKey=1和rowKey=2的这两行，只有左边的columnFamily:name才会有值，提供了根据ID找到名字的功能：
rowKey=1，它记录了id=1的metric/tagk/tagv的名字。也就是，它代表的含义是：proc.stat.cpu是第1个metric，host是第1个tagk，foo是第1个tagv。
rowKey=2跟rowKey=1是类似的含义，它记录了id=2的metric/tagk/tagv的名字。

3.剩余的几行，相当于是rowKey=1和rowKey=2这两行的一个反向关系的存储，提供的功能是根据名字找到ID：
例如rowKey=proc.stat.cpu这一行，它代表proc.stat.cpu是一个metric，且它的id是1（id:metrics=1，表明了类型和ID）


最后，很容易看到，tsdb-uid这个表是很稀疏的，表中空白的地方，永远都不会有值写进去的。但好在hbase是列存储，并不会像关系型数据库那样造成空间的浪费。

从表中也可以看到，即使是不同的metric，只要你的tagk（或者tagv）的名字相同，那这个tagk的ID就相同。例如你新创建一个名为proc.stat.wtf的metric，它也有一个tagk=host，那“host”的ID还是1，不会增加：
proc.stat.wtf 1297574486 54.2 host=bar