【IT168 评论】为什么要为时间序列来建立专门的数据库?明明我们就有很多方法来处理时序数据，例如在SQL数据库中通过时间列的排序来解决或者是选择Cassandra这样的分布式数据库。但是，这些方法虽然能够解决时序数据的问题，但是却需要进行大量的工作，十分耗时。那么怎么才能更好的解决时序数据呢?

　　首先，我们先来看一下时序数据的种类：常规和不规则。

　　开发人员比较常见和熟悉的是常规时间序列，它只在规定的时间间隔内进行测量，如每10秒钟一次，通常会发生在传感器中，定期读取数据。常规时间序列代表了一些基本的原始事件流或分发。

　　不规则时间序列则对应离散事件，主要是针对API，例如股票交易。如果要以1分钟间隔计算API的平均响应时间，可以聚合各个请求以生成常规时间序列。

　　现代TSDB需要能够处理常规和不规则的事件和度量，它们要有通用的元数据来描述用户可能要查询的东西。例如主机名，应用程序，区域，传感器ID，建筑物，股票名称，投资组合名称或者是其它任何维度的数据。时间序列添加元数据要允许客户切片，并创建摘要。

　　时间序列应用与规模

　　时序数据库与其他数据库用例和工作负载的区别。

　　时间序列数据专注于快速摄取。也就是说，时序数据库需要经常插入新数据。使用传感器数据用例时，我们常常会发现滞后的数据收集，这时也要将数据附加进行。

　　高精度数据保存时间较短，中等或更低精度的摘要数据保留时间较长。这也意味着用户必须不断从数据库中删除数据。这是一个非常不同于正常数据库设计来处理的工作量。

　　代理或数据库本身必须连续计算来自高精度数据的摘要以进行长期存储。这些计算既包括一些简单的聚合，同时也有一些复杂计算。

　　时间序列的查询模式可能与其他数据库工作负载有很大的不同。在大多数情况下，查询是在所请求的时间范围内提取一段数据。但对于即时计算聚合和缩减样本的数据库，常常会流失很多数据，所以快速迭代数据来计算聚合对于时间序列用例至关重要。

　　使用SQL数据库时间序列的问题

　　许多用户在使用时间序列之前，是将其数据存储在常见的SQL RDBMS(如PostgreSQL或MySQL)中。一般来说，短期内还是可以满足需求的，但随着数据规模的增加，事情就开始失控了。

　　结论：关系型数据库不是为了解决具体的时间序列问题而设计的，所以试图让他们解决问题是不现实的。

　　基于分布式数据库

　　与SQL变体一样，在类似Cassandra的分布式数据库之上构建时间序列解决方案需要相当多的应用级代码。

　　首先，需要决定如何构建数据。Cassandra中的行被存储在一个复制组，这意味着需要考虑如何构造行键，以确保集群得到正确利用。之后还需要编写应用程序逻辑来对时间序列用例进行其他查询处理。然后，编写采样逻辑来处理创建可用于长期可视化的较低精度样本。最后，在查询不同维度的许多时间序列和计算聚合时，需要确保查询性能。

　　结论：编写所有这些应用程序代码通常需要有能力的后端工程师进行几个月的时间。

　　为什么要建立一个时间序列数据平台?

　　减轻开发者的工作

　　我们经常会看到开发者不断编写代码来解决相同的问题，如果我们将其引入到平台或者是数据库中，开发者的代码量就会减少，解决问题的时间就会被优化。

　　时间是特殊的

　　除了可用性目标之外，我们还可以围绕时间序列的特性进行一些数据库的优化，例如，在插入时聚合和缩小样本，在用户想要释放空间时自动排除高精度数据。甚至还可以构建针对时间序列数据进行优化的压缩。

　　超越数据库，使开发更容易

　　专为时序数据构建数据库的一个优点就是它可以超越数据库。我们发现大多数用户遇到了一系列需要解决的问题，如何收集数据，如何存储数据，如何处理和监视数据，以及如何可视化。

　　使用通用API可以使社区更容易的构建解决方案。用 line protocol来表示时间序列数据，用于写入和查询的HTTP API，以及用于处理的Kapacitor……随着时间的推移，我们可以对常见的用例来预先构建组件。

　　主流的时间序列数据库

　　前文对于时间序列数据库解释了那么多，最后我们就来看看主流的时间序列数据库有哪些?根据DB-Engines排行榜，在300多个数据库中，时间序列数据库共有17个，但可惜的是目前市场份额还是有点低。