时序数据库 IoTDB 源码解析之前言（一）-低调大师

时序数据库 IoTDB 源码解析之前言（一）

2020-02-06 583

IoTDB 是一款时序数据库，相关竞品有 Kairosdb，InfluxDB，TimescaleDB等，主要使用场景是在物联网相关行业，如：车联网、风力发电、地铁、飞机监控等等，具体应用案例及公司详情可以查看：IoTDB在实际公司中的使用信息收集

IoTDB 模块主要分为Client，JDBC，Server，TsFile，Grafana，Distribution 以及各种生态的连接器。整个系列的文章会从行业背景开始讲起，了解一个行业具体的使用场景，然后介绍 TsFile 是以什么样的格式来保存数据的，再介绍 Server 里怎样完成一次查询，最后在介绍一条完整的 SQL是怎样从 Client 使用 JDBC 到 Server 直至返回具体结果。如果有能力的话再介绍一下集群的一些内容和工作方式。

打一波广告本人专注车联网领域多年，现任四维智联架构师。目前正在参与 IoTDB 社区，有志同道合的同伴欢迎加微信：liutaohua001

这一章主要想聊一聊：

为什么重复造轮子，从物联网行业的数据特点到 IoTDB 的发展过程
这个轮子造的怎么样，IoTDB 和竞品测试对比

时序数据

我个人理解时序数据是基于时间维度的同一个物体或概念的值构成的一个序列数据。在传统关系型数据库中，例如 MySQL，我们通常会放置一个自增的 Id 列作为主键标识，如下：

Id	人名	体温	测量时间
1	张三	36.5	2020-02-06 9:00:00
2	李四	36.9	2020-02-06 9:00:00
3	王五	36.7	2020-02-06 9:00:00
4	张三	36.3	2020-02-06 9:30:00
5	张三	36.9	2020-02-06 11:00:00

上面的表结构就是一个时序数据，将表结构做个变形更容易理解:

时间戳	人名	体温
1580950800	张三	36.5
1580950800	李四	36.9
1580950800	王五	36.7
1580952600	张三	36.3
1580958000	张三	36.9

如果把时间作为一个唯一键对齐展示，能够更像时序数据一些，这也是 IoTDB 中查询结果的展示方式：

时间戳	张三	李四	王五
1580950800	36.5	36.9	36.7
1580952600	36.3	NULL	NULL
1580958000	36.9	NULL	NULL

这里可能会存在疑问就是假如人数是逐渐增加的，那么是动态创建列呢？还是提前创建足够多的列？这个问题等后面文章有机会继续介绍

物联网

物联网的特点是都会存在一个或多个设备，他们以各种各样的形式组织到一起，用来观测或记录同一时间里相同环境所产生的数据。下面的介绍中，使用由简单到复杂的数据逐步介绍在物联网行业中，通用的一些问题和方向。

1.基本存储

假如我是一个公司，对外播报北京、天津、上海三地的温度数据，从而实现盈利。

时间戳	北京	天津	上海
1580950800	20.5	22.9	21.7
1580952600	20.5	NULL	22.9
1580958000	20.5	21.7	22.9

2.保证数据质量

数据保证的质量是多方面的，一步一步介绍。

2.1 更多设备

首先可以看到上面数据是存在 NULL 值的，这个 NULL 值有可能是因为当时设备所在的区域停电了，所以并没有办法上报当时的情况，这样客户如果想获取1580952600 这个时间戳对应的天津的数据的时候，肯定是拿不到了，所以传统思维上，我们应该增加一个容灾设备，保证一个设备在坏掉、停电、人为损坏等等的情况的时候，依然能够有数据上报回来。

基于这样的思想，以上的表结构就会变成：

时间戳	北京 1	北京 2	天津1	天津2	上海1	上海2
1580950800	20.5	20.9	21.7	20.9	20.7	21.7
1580952600	21.5	21.0	NULL	21.7	21.7	21.7
1580958000	22.5	22.7	22.9	22.7	NULL	NULL

2.2 更高采样频率

这时候依然存在问题， 1580958000 这一刻两个设备都没有数据，有可能是放置设备的区域同时出现了断网或者断电，这种情况下，我们可以采用提高采集数据的频率或者补传数据来解决(补传暂不讨论)。

我们将每天数据分为3组，每组采样3次，间隔为1个小时，假如时间分布为：上午（7、8、9）、中午（12、13、14）、下午（18、19、20）。当增加了采样频率之后，即便某一刻出现了 NULL 数据，我们也可以采用临近时间做为补充。为了方便对应，下表数据中增加时间点列辅助查看。

时间点	时间戳	北京 1	北京 2	天津1	天津2	上海1	上海2
7点	1580943600	20.5	20.9	21.7	20.9	20.7	21.7
8点	1580947200	21.5	21.0	NULL	21.7	21.7	21.7
9点	1580950800	22.5	22.7	22.9	22.7	NULL	NULL
12点	1580961600	20.5	20.9	21.7	20.9	20.7	21.7
13点	1580965200	21.5	21.0	NULL	21.7	21.7	21.7
14点	1580968800	22.5	22.7	22.9	22.7	NULL	NULL
18点	1580983200	20.5	20.9	21.7	20.9	20.7	21.7
19点	1580986800	21.5	21.0	NULL	21.7	21.7	21.7
20点	1580990400	22.5	22.7	22.9	22.7	NULL	NULL

可以看到经过各种各样的需求之后，上传的数据是成倍增长的，不难想象如果这个温度数据希望精准的获取到每个县城的温度，那么中国有 2854 个县城 * 2 个温度设备 * 9 条数据 = 1 天产生的数据总量 = 51372 条，那么一个月就是 1541160 条。

数据实时性及总量

假如上面的数据我们继续提高频率到每1分钟每个设备上报一次，那么数据量就会成为 2854 * 2 * 60 * 24 = 246585600 条/天。

在这样的数据量下，实时插入实时做一些聚合计算，应该传统数据库就有些处理不过来了。

IoTDB 的前身

某公司在实际业务中，20 万设备保存了 3 年的数据，TB级别的数据使得 Oracle 被拖的根本吃不消。关键的问题点还不仅仅是存量数据大，新增数据依然以非常快的速度在增长。后来公司联系到了 IoTDB 的第一批开发者，但是当时的方案还是基于 Cassandra 来做设计，当时规划了 5 台机器的集群，性能刚满足，但随着时间推移设备总量在增加，业务系统的查询请求量在增加。Cassandra 在经过大量的努力之后，最后发现如果再改可能就需要大面积的重构 Cassandra 数据的代码了，最终决定重新设计一个存储方式，来解决物联网场景下的时序数据高效写入、低延迟读取、高压缩比持久化。

PS: 以上都是黄向东 (IoTDB PPMC) ，在 meetup 中讲到的，我只是在脑中存留了一部分，具体的细节大家可以到 IoTDB 社区交流。

性能对比

测试工具使用的是由清华大学大数据实验室开发的iotdb-benchmark

1.写入性能对比

数据集2	客户端	存储组	设备	变量	batchsize	LOOP	数据量	写入速度(point/s)	硬盘数据大小
IoTDB	10	10	10	10	1000	1000000	1E+11	24750321.93	38306092
InfluxDB	10	10	10	10	1000	1000000	1E+11		304682932
TimescaleDB	10	10	10	10	1000	1000000	1E+11	737689.22	1610219064

数据集1	客户端	存储组	设备	变量	batchsize	LOOP	数据量	写入速度(point/s)	硬盘数据大小
IoTDB	10	10	10	10	1000	100000	10000000000	20706345.15	3599732
InfluxDB	10	10	10	10	1000	100000	10000000000	1729907.81	30546560
TimescaleDB	10	10	10	10	1000	100000	10000000000	715857	161026468
KairosDB	10	10	10	10	10000	10000	10000000000	24924.97	76263380

上面一组数据可以看出写入性能高于同款数据库10倍有余，单机写入速度高达到每秒2千万。且硬盘占用是最小的，这在数据比较大的线上业务中，可能每个月会差出来 1 到 2 块硬盘。

2. 查询性能对比

原始数据查询

	客户端	存储组	设备	序列-数据量	变量	查询点数	LOOP	速度(point/s)	AVG	MIN
IoTDB	10	10	10	1.00E+09	1	1000000	100	12942984.85	740.27	457.04
InfluxDB	10	10	10	1.00E+09	1	1000000	100	1779606.4	5591	4666.39
TimescaleDB	10	10	10	1.00E+09	1	1000000	100	3781467.52	2345.69	1193.78

聚合数据查询

	客户端	存储组	设备	序列-数据量	变量	LOOP	范围	速度(point/s)	AVG	MIN
IoTDB-1	10	10	10	1.00E+09	1	100	0.0001	49.75	27.87	18.03
IoTDB-2	10	10	10	1.00E+09	1	100	0.001	49.75	49.14	19.87
IoTDB-3	10	10	10	1.00E+09	1	100	0.01	49.76	48.69	22.32
IoTDB-4	10	10	10	1.00E+09	1	100	0.1	48.68	99.14	25.56
IoTDB-5	10	10	10	1.00E+09	1	100	1	14	595.61	45.54
InfluxDB-1	10	10	10	1.00E+09	1	100	0.0001	234.32	40.28	21.63
InfluxDB-2	10	10	10	1.00E+09	1	100	0.001	28.88	341.9	238.1
InfluxDB-3	10	10	10	1.00E+09	1	100	0.01	3.07	3226.87	2664.86
TimescaleDB-1	10	10	10	1.00E+09	1	100	0.0001	42.39	220.57	120.5
TimescaleDB-2	10	10	10	1.00E+09	1	100	0.001	5.8	1502.9	754.15
TimescaleDB-3	10	10	10	1.00E+09	1	100	0.01	1.02	9711.55	7148.69

3. 对比图

整体来看 IoTDB 无论在写入、原始数据查询还是聚合查询，都几乎是10倍的性能于竞品数据库，而且硬盘占用又小于同款数据库10倍，那么 IoTDB 是怎样完成如此高的压缩比、如此恐怖的写入速度、如此高效的查询呢？欢迎继续关注。。。

微信关注我们

原文链接：https://my.oschina.net/u/3374539/blog/3163843

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Serverless 公司的远程团队沟通策略

本文系译文，Serverless 团队分散在全球各地，本文介绍我们如何管理沟通策略和远程协作。原作者：FelixDesroches 译者：Aceyclee 首先向不了解我们的人说明一下，Serverless 团队成员总共跨越了 18 个时区，不同成员之间重合的工作时间非常少。对于所有成员都在一处工作的团队来说，沟通已是难事，而像我们这样的远程团队来说，沟通更是难上加难。没有了面对面的互动，很容易感到孤立：不仅与同事疏离，也与公司愿景脱节。为了解决这个问题，我们采取的一项举措是每年举行两次团建活动。就在几周前，我们刚刚举行了一次团建活动，我们讨论的主要话题是「沟通」。那么，如何更好地进行沟通呢？我们进行了深入探讨，不可避免地涉及到一些棘手的话题，但也使我们的方向更加明晰，为继续前进打下了一个更坚实的基础。以下几点，可能会适用于远程团队。 Radical Candor（坦诚相待）和换位思考此次团建活动开始前，我们要求团队成员们先阅读 Radical Candor。 Radical Candor 的核心原则之一是真切实际地去了解他人，而非揣测别人是什么样的人。这包括很多方面，例如...

2020-02-06

580

新增 added: 模板切换命令 added: 优惠码接口 added: 课程推荐功能 added: 课程分类过滤优化优化：支付渠道和方式根据平台自动选择优化：OpenAPI文档优化：搜索由原先的视频搜索改为课程搜索优化：用户中心社交登录的App名称修复 fixed: 短信验证码接口数据返回 fixed: 订单创建接口的优惠码使用 fixed: 后台插件读取移除 deleted: 发送验证码限流策略 deleted: emoji依赖 deleted: page-speed依赖小程序更新注意，小程序目前还在开发当中，尚不稳定，不推荐生产环境使用。 added: 订单支付支持优惠码 added: 优惠码分享优化: 部分页面禁止分享优化: vip界面样式调整 fixed: 登录界面发送验证码 added: 使用说明 Github：https://github.com/Qsnh/meedu Gitee：https://gitee.com/myteng/MeEdu 官网：https://meedu.vip MeEdu 是基于 Laravel 开发的个人在线教育系统。MeEd...

2020-02-06

686

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。