时序数据特点时序数据特点

基本上是插入操作较多且无更新的需求数据带有时间属性，且数据量随着时间递增插入数据多，每秒钟插入需要可到达千万甚至是上亿的数据量查询、聚合等操作主要针对近期插入的数据时序数据能够还原数据的变化状态可以通过分析过去时序数据的变化、检测现在的变化，以达到预测未来如何变化的目的时序数据使用需求：能够按照指标筛选数据能够按照区间、时间范围、统计信息聚合展示数据。

BlueSky高性能时序数据库算法

算法 是将之前使用的一个大的查找结构（造成随机读写，影响写性能的结构，比如 B+ 树），变换为将写操作顺序的保存到有序文件中，且每个文件只保存短时间内的改动。文件是有序的，所以读取的时候，查找会非常快 。且文件不可修改，新的更新操作只会写入到新的文件中。读操作检查有序的文件。然后周期性的合并文件来减少文件的个数。

写入操作

数据先在内存中缓存（memtable) 中，memtable 使用树的结构来保持 key 是有序的，同时使用 WAL 的方式备份数据到磁盘。当 memtable 中数据达到一定规模后会刷新数据到磁盘生成文件。更新写入操作

文件不允许被编辑，所以新的内容或修改只是简单的生成新的文件。当越多的数据存储到系统中，就会有越多的不可修改、顺序的有序文件被创建。但比较旧的文件不会被更新，重复的激流只会通过创建新的记录来达到覆盖的目的，但这这就产生了冗余的数据。

系统会周期性的执行合并的操作，合并操作用于移除重复的更新或者删除记录，同时还能够减少文件个数的增加，保证读操作的性能。读取操作

查询的时候首先检查内存数据（memtable)，如果没有找到这个 key，就会逆序的一个个的检查磁盘上的文件，但读操作耗时会随着磁盘上文件个数的增加而增加。（O(K log N), K为文件个数， N 为文件平均大小）。可以使用如下策略减少耗时将文件按照 LRU 缓存到内存中周期性的合并文件，减少文件的个数使用布隆过滤器避免大量的读文件操作（如果bloom说一个key不存在，就一定不存在，而当bloom说一个文件存在是，可能是不存在的，只是通过概率来保证）

BlueSky高性能时序数据库时序业务有哪些特点？

时序业务和普通业务在很多方面都有巨大的区别，归纳起来主要有如下几个方面：持续产生海量数据，没有波峰波谷。举几个简单的例子，比如类似哨兵的监控系统，假如现在系统监控1w台服务器的各类指标，每台服务器每秒采集100种metrics，这样每秒钟将会有100w的TPS。再比如说，现在比较流行的运动手环，假如当前有100w人佩戴，每个手环一秒只采集3种metrcis（心跳、脉搏、步数），这样每秒钟也会产生300w的TPS。数据都是插入操作，基本没有更新删除操作。时序业务产生的数据很少有更新删除的操作，基于这样的事实，在时序数据库架构设计上会有很大的简化。近期数据关注度更高，未来会更关注流式处理这个环节，时间久远的数据被访问，甚至可以丢弃。这个很容易理解，哨兵系统我们通常关心近一小时的数据，很多看看近3天的数据，很少去看3天以前的数据。随着流式计算的到来，时序数据在以后的发展中必然会更关注即时数据的价值，这部分数据的价值毫无疑问也是很大的。数据产生之后就可以根据某些规则进行报警是一个非常常见并重要的场景，报警时效性越高，对业务越有利。数据存在多个维度的标签，往往需要多维度联合查询以及统计查询。时序数据另一个非常重要的功能是多维度聚合统计查询，比如业务需要统计近一小时广告主google发布在USA地区的广告点击率和总收入分别是多少，这是一个典型的多维度聚合统计查询需求。这个需求通常对实效性要求不高，但对查询聚合性能有比较高的要求。

序列化框架的对比

性能方面：

（1） 解析速度：protobuf<thrift<***ro

（2） 序列化后的数据大小：***ro<protobuf<thrift(compact)<thrift(binary)

非功能方面：

开源协议、schema表达、是否需要代码动态生成、是否自动生成RPC接口，是否自动生成RPC实现等，按照实际需求选择。