tsdb
http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/36632.pdf
http://vldb.org/pvldb/vol5/p1436_alexanderhall_vldb2012.pdf
https://druid.apache.org/druid-powered.html
https://medium.com/airbnb-engineering/druid-airbnb-data-platform-601c312f2a4c
https://druid.apache.org/druid.html
https://druid.apache.org/docs/latest/comparisons/druid-vs-elasticsearch.html
https://docs.influxdata.com/influxdb/v1.7/introduction/getting-started/
http://hbasefly.com/2017/11/19/timeseries-database-1/
TSDB核心特性：TSDB关注的核心技术点在哪里？
说了这么多，是应该看看TSDB到底在技术层面关注哪些核心点了，基于时序业务的基本特点，总结起来TSDB需要关注的技术点主要有这么几个：
高吞吐量写入能力。这是针对时序业务持续产生海量数据这么一个特点量身定做的，当前要实现系统高吞吐量写入，必须要满足两个基本技术点要求：系统具有水平扩展性和单机LSM体系结构。系统具有水平扩展性很容易理解，单机肯定是扛不住的，系统必须是集群式的，而且要容易加节点扩展，说到底，就是扩容的时候对业务无感知，目前Hadoop生态系统基本上都可以做到这一点；而LSM体系结构是用来保证单台机器的高吞吐量写入，LSM结构下数据写入只需要写入内存以及追加写入日志，这样就不再需要随机将数据写入磁盘，HBase、Kudu以及Druid等对写入性能有要求的系统目前都采用的这种结构。
数据分级存储/TTL。这是针对时序数据冷热性质定制的技术特性。数据分级存储要求能够将最近小时级别的数据放到内存中，将最近天级别的数据放到SSD，更久远的数据放到更加廉价的HDD或者直接使用TTL过期淘汰掉。
高压缩率。提供高压缩率有两个方面的考虑，一方面是节省成本，这很容易理解，将1T数据压缩到100G就可以减少900G的硬盘开销，这对业务来说是有很大的诱惑的。另一个方面是压缩后的数据可以更容易保证存储到内存中，比如最近3小时的数据是1T，我现在只有100G的内存，如果不压缩，就会有900G的数据被迫放到硬盘上，这样的话查询开销会非常之大，而使用压缩会将这1T数据都放入内存，查询性能会非常之好。
多维度查询能力。时序数据通常会有多个维度的标签来刻画一条数据，就是上文中提到的维度列。如何根据随机几个维度进行高效查询就是必须要解决的一个问题，这个问题通常需要考虑位图索引或者倒排索引技术。
高效聚合能力。时序业务一个通用的需求是聚合统计报表查询，比如哨兵系统中需要查看最近一天某个接口出现异常的总次数，或者某个接口执行的最大耗时时间。这样的聚合实际上就是简单的count以及max，问题是如何能高效的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合，要知道统计的原始值可能因为时间比较久远而不在内存中哈，因此这可能是一个非常耗时的操作。目前业界比较成熟的方案是使用预聚合，就是在数据写进来的时候就完成基本的聚合操作。
未来技术点：异常实时检测、未来预测等等
