时序数据库 vs OLAP

时序数据库 vs OLAP

根据wikipedia的定义：“A time series database (TSDB) is a software system that is optimized for storing and serving time series through associated pairs of time(s) and value(s). ”

我个人并不质疑wikipedia定义的准确性，但是对于大多数人来说，这个定义还是过于抽象了，他并没有描述出一个时序数据库完整的样子。

以我的角度来看，先给大家结论，时序数据库不是OLTP，虽然会保证原子性，但其并不处理事务。理论上讲，时序数据库应该属于OLAP的一个子类别，但同时由于时序数据库的读写模式足够的不同，其也经常被大家单独划分为一类。

下面，我想从数据库持久存储的四个基本操作——创建、读取、更新和删除的角度来看时序数据库与一般的OLAP数据库有何不同。

第一，我先来看时序数据库的创建（Create）操作，时序数据库的写入性能是非常强大的，其写入量可高达每秒千万次。与之相比，OLAP数据库系统中写入性能是次要性能，系统的设计更加倾向于用磁盘/内存空间去换取查询分析的相应时间。所以，这就会导致在出现大量数据写入时，OLAP数据库更优先批处理而不是事件流处理。同时，时序数据库的写入是连续的，这是因为时序数据通常是前端的机器设备产生的。而OLAP数据库的数据写入峰值，往往是在一个时间段的结束，比如一小时、一天、或者1个月的结束。

第二，我们来看读（Read）操作，时序数据库与OLAP数据库也很多不同之处。在时序数据库的应用场景中，最新的数据会被更频繁的读取，其比历史数据更重要。而伴随着更加新的数据被写入，曾经的新数据变为了旧数据，其读取次数就会出现几何式的下降。而在OLAP数据库中，新数据价值更大的情况并未如此的明显。例如，我们在金融交易时，历史数据也非常有价值，经常被用于分析决策，反而近期的数据可能没有那么有价值。进一步来看，在时序数据库中，我们通常只读小部分数据，一小部分数据的读取非常频繁，其余的数据都只是写入，所以当每个人都去频繁读取这小部分数据时，这也就引发了倾斜读取的问题。而在OLAP数据库中，我们一般会读取所有的数据。比如，公司的营销数据一般都要经过汇总，再用来进行分析，所以所有数据至少会被访问一次。由于数据是统一访问的，因此数据访问模式也没有时序数据库那么倾斜。

第三，来看看更新（Update）操作，此前已经说过，时序数据大多是前端的机器设备生产的，所以时序数据库基本承载的还是保留下这些机器设备所产生的原始数据的职能，因此时序库中的数据是一般是不可变的，基本不进行更新操作。在极少数情况下，时序数据库会对数据进行修改，比如传感器的原始数据有误。而在OLAP数据库中数据并非不可变。最后，说下删除（Delete）操作，在时序数据库中，我们一般会设置保留策略，也就是数据在保留一段时间后，就会被自动删除。因此，当我们每分每秒以恒定的速度向系统中写入数据时，我们也在删除相同的数据量。也就是说，在时序数据库中，对数据的有效写入操作是实际写入次数的2倍。大多数数据都会被批量的删除。相比之下，在OLAP数据库中删除操作并不经常发生，一般也不会有大的数据量被删除。

综上所述，时序数据库应该算是一种特殊的OLAP，但与OLAP不同，其有自己所承载的场景特点和功能。最近，也看到一些朋友会问，传统的OLAP数据库会不会更多的被优化去支持类似时序数据库类型的操作呢？个人来看，为了应对更快速的查询和各种业务分析，OLAP数据库的设计优先考虑的是去支持传统的数据仓库，其本质的设计思路就与时序数据库有所不同。一款产品永远不可能处处都完美，在开源基础软件高度发展的今天，也许大家各司其职，互为生态，形成完整的技术栈，才是我们应该考虑的，不知道大家如何看待，今天就到这里吧，我们改日再见。

参与CnosDB社区交流群：

扫描下方二维码，加入CC进入CnosDB社区进入社区交流，CC也会在群内分享直播链接哒