如今时序数据的应用场景十分广泛，许多类型的数据都是时间序列数据：
金融市场交易
传感器测量（水冷、高温、地震...）
服务器监控（CPU、内存、磁盘...）
资源消耗（能源、电力...）
人体健康（心率、血氧浓度...）
网络访问
通过保留数据固有的时间序列性质，我们可以记录下事物是如何随时间变化的事实，正因如此，这一反应真实的客观属性使得时序数据在特定的场景中充满了商业价值：通过分析时序数据，决策者可以了解到生产和业务中的细微变化，从而对资源优化、跟踪、预测、商业智能等方面进行优化。
在时序数据库成为热点之前，时序数据通常使用 MySQL 或 PostgreSQL 等关系数据库进行处理。但自2010年以来，随着互联网和通信技术的发展，网络中产生的时间序列数据量有了爆炸式的增长，传统的数据库已经无法处理这种万亿级的海量数据。不仅如此，现代业务对数据价值挖掘的需求已不仅仅停留在简单计算和绘制图表的层面上，而是需要更多精细、复杂的计算分析。
如何以一种高性能的方式记录、查询和分析如此大规模的数据，成为了一个难题。时序数据库(time-series database)应运而生。以对数据价值嗅觉最敏感的金融领域为例，早在20年前，华尔街就已经开始使用时序数据库对股票交易数据进行实时的计算分析。
那么，时序数据库与“普通”数据库在技术上有哪些区别呢？
我们假定“普通”数据库是 MySQL、Oracle 之类的 OLTP (Online Transaction Processing) 事务型数据库。
01.
首先，大部分时序数据库的查询场景可以认为是 OLAP（Online Analytical Processing ）分析型数据库场景。具体地说，时序数据库的读取负载主要可以分为两种，一种是对指定时间序列在指定时间段内数据的查询，如查询某个设备或某支股票最新一小时的数据等；另一种是对大量数据进行统计分析，如分析某支股票、甚至是所有股票在过去一周内的平均价格。这两种场景都算是典型的 OLAP 的读取场景。因此，时序数据库具有大部分 OLAP 数据库的特点，如列存、会对数据做压缩、支持复杂的查询语句等等。
02.
其次，从写入负载来分析，时序数据库的场景有大量数据的实时写入，而非单行数据的写入与修改。由于时序数据库的写入负载通常很高，如每秒几百万甚至几千万条数据，所以时序数据库的存储引擎往往是基于对大量写入更加友好的 LSM Tree(Log Structured Merge Tree)，而非对主键点查询、主键范围查询以及单行修改与更新更友好的 B+ 树。开发高效的时序数据库存储引擎，需要扎实的操作系统、数据库系统、分布式系统、体系结构、数据结构与算法等计算机基础。
03.
第三，时序数据库需要支持很多时序场景特有的分析语句与函数。一些常见的语句与函数有：降采样、插值、滑动平均、时间滑动平均、累积和、window join、context by、pivot by 等等。要高效地（往往是向量化地）支持这些查询语句并不是一件非常容易的事情。
04.
第四，流数据的处理。对时序数据的离线分析属于批处理的范畴，而还有许多时序数据场景则可以抽象成另外一个我们称之为流数据的计算场景：有数据不停地产生，且需要低延时地对这些数据做即时的响应与计算。在时序领域，对于流数据的处理，以往的做法往往是使用 flink 等单独的流数据处理平台，这当然也能够解决问题，但会导致至少两个问题，第一是需要维护时序数据库与 flink 这两套系统，使得运维成本大大提升；第二个问题则可能更加致命，那就是流数据的处理是否能够与批数据处理一致，而如果产生不一致，则可能会对业务场景带来毁灭性的影响（熟悉机器学习的同学应该知道机器学习的训练场景、测试场景与服务场景必须达到高度的一致）。如果时序数据库能够推出针对时序场景的特殊流数据处理子系统，并且能够达到“流批一体”，就可以保证批数据与流数据处理的结果完全一致。
数据库的性能往往很大程度上由存储引擎决定。如何针对不同的应用场景设计高性能的存储引擎一直是数据库开发的难题。而在时序数据库的场景下，究竟该怎么设计一个存储引擎，至今仍是一个没有标准答案的开放性问题。
10月27日（本周四）19:30，DolphinDB 邀请到了「树根互联」解决方案高级总监陈超、「华夏基金」高级工程师李乾鹏以及「DolphinDB」研发副总监胡津铭，一同与大家探讨时序数据库极致性能背后的存储引擎。
本次直播中，你将收获：
来自数据库行业大佬的分享
