时序数据库 vs OLAP

金融投资出身，半路出家转型 Infra 领域创业，一半金融民工一半 Infra 狗，作为身上流淌着两股完全不搭杆血液的半个 Infra 圈内人，今天我想从自己非专业的角度，来聊聊时序数据库与 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 简介

CnosDB 是一款高性能、高易用性的开源分布式时序数据库，现已正式发布及全部开源。