一个服务器轻松存储上亿数据，TDengine 在北京智能建筑边缘存储的应用

小 T 导读：在北京智能建筑边缘侧采集数据存储的方案中，面临着在有限的计算资源下，如何实现最高效的数据存储、分析和计算的问题。经过调研与测试，最终选择了由 TDengine 处理时序数据，SQLite 处理关系数据，以此更好地实现边缘侧的数据自治。本文讲述了他们的选型和建模思路以及落地后的效果展示，作为经验参考分享给有需要的读者。

公司简介

北京智能建筑科技有限公司作为北京市在智能建筑和智慧城市领域的创新平台，是冬奥科技平台公司、智慧冬奥国家重点项目设计单位和核心实施单位，同时，北智建作为国家高新技术企业，致力于打造中国最大的智能建筑 AIoT 平台。

在云计算模式中，采集的数据必须要传到云上进行集中式的存储、归档及分析，依托云端计算资源进行复杂的计算，再将所得到的指导性结论通过网络下发给终端。而对于边缘计算，即把一部分的存储和计算的能力下沉到边缘侧（即设备侧），由于终端设备可以较独立地进行数据存储、计算、决策和应用，因此边缘侧会更加智能，对云端依赖更小，数据处理的时效性也更高，且不再受网络影响。

一般来说，边缘侧往往是一些能够大量铺设的小型智能终端，出于成本考虑，其配置的内存、CPU 等硬件资源和计算能力都很有限。边缘计算的难点就在于能否在有限的计算资源下，实现最高效的数据存储、分析和计算。总结下来，边缘计算对数据库能力的要求主要反映在以下几个方面，这也是我们在选择数据库时的重点考量维度：

• 超高读写性能
• 低硬件开销
• 通用接口，适配边缘侧多样计算需求
• 实时数据的缓存能力、流式计算能力
• 历史数据持久化存储、高效压缩能力
• 历史数据回溯能力、按时间窗口的统计聚合能力

一、技术选型

整体而言，时序数据库具备上述各项能力，也是边缘侧采集数据存储的最佳选择。但市面上时序数据库产品(Time-Series Database)众多，如何筛选也是一个难点。

如 OpenTSDB（底层基于 HBase 改造）、InfluxDB 等一类的时序数据库，其运行起来的硬件资源开销过高，对于边缘侧来说还是太重了。后来我们观察到了一个极轻量化的开源时序数据库 —— TDengine，当时它的整个安装包只有 2 MB 多，使用 C 语言完全自主研发，核心功能就是一个高性能分布式时序数据库。具体优势汇总如下：

• TDengine 社区已经发布了支持 ARM64 处理器的版本，可以顺畅地运行在树莓派等主流的边缘侧硬件上，同时提供对实时数据的缓存、历史数据的回溯、按时间段进行聚合计算等多种能力。
• TDengine ARM 版本支持的接口也有很多种，与正常集群版几乎没有区别。同时，它还提供了一个 taos shell 客户端，让调试人员可以方便地去查看 TDengine 的运行状态。
• 支持包括 C/C++、JAVA、Python、RESTful、Go 在内的多种语言，学习成本低
• 安装超级简单，无任何依赖
• 安装无任何依赖
  
• 使用便捷

SQLite VS TDengine
另外提起边缘侧、嵌入式设备中的数据存储，那就不得不提 SQLite。SQLite 是一个不需要后台的超轻量级数据库，即插即用的特点也让它成为世界上装机量最高的数据库。SQLite甚至在官网上将自身定位与 fopen() 对标，而不再是作为一款数据库。SQLite 提供的一系列 API 都是对标关系型数据库的，它甚至还支持了事务，因此业界常常把它用作嵌入式关系型数据库。其与 TDengine 的各项对比如下：

从上面的比较中我们可以看到，TDengine 和 SQLite 要处理的问题侧重点不同，各有所长。从我们自身业务的切实需求出发，两者并非必须要进行取舍，而是可以根据业务需求灵活搭配使用——由 TDengine 处理时序数据，由 SQLite 处理关系数据，以此更好地实现边缘侧的数据自治。基于此，在存储方面我们决定采用 TDengine + SQLite 的组合形式。

二、架构与具体实现

技术架构

• 物理视图
  
• 逻辑视图
  

在边缘端日志功能（为边缘端的设备提供日志上报）的设计上，我们采用 TDengine Database 对日志进行存储，该功能的设计是为出现异常状况的设备提供溯源依据，在与告警功能配合下可以让开发人员快速定位到问题，及时进行解决。此外在边缘端进行日志处理，就能利用边缘端的算力减轻中台的压力，还可以支撑 2 万设备异常情况下的日志并发写入。

对于设备的采集值，我们同样采用 TDengine 进行存储和检索。以往采用关系型数据库进行存储时，在设备比较多、数据量庞大的情况下，查询会非常的慢，体验感极差。反观 TDengine 高压缩算法能提升 10 到 20 倍的压缩性能，降低存储压力的同时也解决了数据存储成本高的问题，还达到了降低硬件成本的效果。

建表建库思路

• 直接输入 taos 进入 TDengine 界面
• SHOW DATABASES 查看数据库
• USE db_name; 选择数据库
• SHOW TABLES; 查看表
• CREATE DATABASE 创建库
• CREATE TABLE 创建表
• INSERT INTO 插入数据
• SELECT 查询数据

三、落地效果

在产品开发初期阶段，我们也尝试过其他类型的数据库解决方案，但都因为各种问题而搁置了。因为研发团队精力人力有限，我们没有考虑过自己搭建一套大数据处理平台，毕竟要充分整合 Kafka、HBase、Hadoop、Spark 这一系列开源框架不仅意味要花费大量人力，还需要更多的时间去调试开源框架本身的问题，融合及联调不同框架也存在着很多数据一致性的问题，同时也意味着后期运维成本的大幅度增加，稳定性也是个不小的未知数。

所幸遇到了 TDengine Database，它帮助我们在边缘侧解决了一个很大的问题，即边缘存储的问题。因为很多时候边缘是布署在资源比较少的机器上面，甚至是 ARM 的工业盒子上面，在资源使用上非常的苛刻，而现在得益于 TDengine 超强的压缩算法，我们使用非常小的存储空间就存储了几千万数据，压缩率远超 1/20，在单机上面布署一个 TDengine 服务器就可以轻轻松松地存储上亿的数据。

此外它还拥有超强的计算能力，占用的资源也非常小，在我们的业务中千万级数据检索时间达到了毫秒级，从用户角度来说产品体验非常好。在运维层面，TDengine 提供标准的 SQL 语法，有过 SQL 使用经验的同学基本上很快就能上手，学习成本接近于零。

四、写在最后

事实上，TDengine 这款 Database 我已经关注很久了，我也和涛思的同学们提出过一些在使用过程中发现的 Bug，从最初的版本到现在的产品，TDengine 变得更加强大和成熟。作为它的“老朋友”，我在此也提出两个改进优化建议，以便帮助它更好的成长：

• 现在安装 TDengine Server 时要向下兼容 TaosClient，如果在升级 Server 时，我不需要再在自己的服务器上面同时升级 TaosClient，可以减少一些部署步骤。
• 如果我们用 kubernetes 进行部署，POD 删掉重启后服务就无法启动了，还需要在挂载的数据文件夹里面手动去修改配置，非常地不灵活。

我们与TDengine的合作不会止于此，未来等到 TDengine 更加成熟稳定后，不仅我们的边缘计算存储要使用它，甚至我们的中台数据也要迁移到上面。

---

想了解更多 TDengine Database 的具体细节，欢迎大家在GitHub上查看相关源代码。