thanos作为一个解决prometheus各种不足的组件，功能上已经是比较强大了，而且针对prometheus的缺陷进行了补充和完善的方案。今天主要说一下他对prometheus存储的补充和坑点。
prometheus的存储模式
prometheus有两种方式对数据进行存储，一种是直接存储到本地磁盘，一种是远程写。远程写可以写opentsdb等。就是把抓取的数据全部写到远程的时序数据库。
本地存储的主要问题就是机器的磁盘有限，而且并不是分布式的存储，有单点故障的问题。
远程写的问题是写的速度要慢，尤其是写到opentsdb这种分布式数据库（底层是hbase）。他需要做多副本，所以写的速度要远比本地磁盘慢。
thanos是解决方式
thanos 做了一层抽象存储的方式进行了优化，解决了速度的问题，也解决了单点故障的问题。
| qurey | query |
|---|---|
| store | sidecar |
| ceph | prometheus |
| 其余时间数据 | 7d |
prometheus从上往下表示了层级结构，query可以代理所有的查询，他可以从两部分进行数据的查询，一部分是代理prometheus的sidecar，一部分是代表高可用存储的store(store本身会加载索引到store的本地的机器)。
prometheus存储一段时间的数据，例如上图的7d。超多7d的数据就丢弃掉。ceph里存储所有的数据，数据是sidecar存prometheus里直接搬运到ceph的。这里搬运的是块，算是批处理的处理数据，这个解决了远程写慢的问题，查询的实时性则是需要prometheus和ceph同时出数据，最后做一次合并处理。例如查13d的数据，sidecar 2h同步一次数据，那么prometheus里可以查到最近7d的数据，ceph里存储的数据只差最近2h的，query会发起查询store从ceph获取最近2小时到13d的数据，promethes会提供，最近7d的数据，最后在query里进行去重处理，最后整合出最近13d的数据。
单点的问题的解决则是通过promethues双活的机制实现的。
thanos的坑
在上面的方案，可以明显的感到一个问题，就是所有的数据都存放在ceph，随着数据越来越多，查询肯定会越来越慢。
prometheus现在提供了一个compactor组件来处理这个事情，他有两个功能，一个是做压缩，就是把旧的数据不断的合并。另外一个是降采样，他会把存储的数据，按照一定的时间，算出最大，最小等值，会根据查询的间隔，进行控制，返回采样的数据，而不是真实的点，在查询特别长的时间的数据的时候，看的主要是趋势，精度是可以选择下降的。
通过以上的方式，有效了优化了查询，但是并不是万能的。毕竟数据可以再增长，一直可以增长到他查询变慢。
这里就需要考虑业务了，我们需要对业务有一定的估算，例如存储ceph的时候不同的业务存储在不同bucket里。做数据的水平切割，例如有5个bucket，我们准备5个store进行代理查询。
事先规划是比较好的方案，否则的话就只能选择数据的拆分，这个就相对比较麻烦了，数据的搬运也是一个很耗时的操作。
第二个方案是时间切片，现在thanos的分支里有一个时间切片的分支，就是store可以选择查询多长时间的数据。支持两种表达，一种是基于相对时间的，例如3d前到5d前的。一种是基于绝对时间的，19年3月1号到19年5月1号。例如想查询3个月的数据，一个store代理一个月的数据，那么就需要3个store来合作。
小结
针对存储的问题，最好是可以有效的规划，在存储上做到数据的拆分。当数据达到一种级别后，可以选择store做时间的切片，当时间切片也不能满足的时候，就需要考虑数据存储的再次拆分，或者说有合理的删除策略，保证数据不会一直无限变大。