共计 2880 个字符，预计需要花费 8 分钟才能阅读完成。
小 T 导读：在北京智能建筑边缘侧采集数据存储的计划中，面临着在无限的计算资源下，如何实现最高效的数据存储、剖析和计算的问题。通过调研与测试，最终抉择了由 TDengine 解决时序数据，SQLite 解决关系数据，以此更好地实现边缘侧的数据自治。本文讲述了他们的选型和建模思路以及落地后的成果展现，作为教训参考分享给有须要的读者。
公司简介
北京智能建筑科技有限公司作为北京市在智能建筑和智慧城市畛域的翻新平台，是冬奥科技平台公司、智慧冬奥国家重点项目设计单位和外围施行单位，同时，北智建作为国家高新技术企业，致力于打造中国最大的智能建筑 AIoT 平台。
在云计算模式中，采集的数据必须要传到云上进行集中式的存储、归档及剖析，依靠云端计算资源进行简单的计算，再将所失去的指导性论断通过网络下发给终端。而对于边缘计算，即把一部分的存储和计算的能力下沉到边缘侧（即设施侧），因为终端设备能够较独立地进行数据存储、计算、决策和利用，因而边缘侧会更加智能，对云端依赖更小，数据处理的时效性也更高，且不再受网络影响。
一般来说，边缘侧往往是一些可能大量铺设的小型智能终端，出于老本思考，其配置的内存、CPU 等硬件资源和计算能力都很无限。边缘计算的难点就在于是否在无限的计算资源下，实现最高效的数据存储、剖析和计算。总结下来，边缘计算对数据库能力的要求次要反映在以下几个方面，这也是咱们在抉择数据库时的重点考量维度：
- 超高读写性能
- 低硬件开销
- 通用接口，适配边缘侧多样计算需要
- 实时数据的缓存能力、流式计算能力
- 历史数据长久化存储、高效压缩能力
- 历史数据回溯能力、按工夫窗口的统计聚合能力
一、技术选型
整体而言，时序数据库具备上述各项能力，也是边缘侧采集数据存储的最佳抉择。但市面上时序数据库产品泛滥，如何筛选也是一个难点。
如 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 对日志进行存储 ，该性能的设计是为出现异常情况的设施提供溯源根据，在与告警性能配合下能够让开发人员疾速定位到问题，及时进行解决。此外在边缘端进行日志解决，就能利用边缘端的算力加重中台的压力，还能够撑持 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，它帮忙咱们在边缘侧解决了一个很大的问题，即边缘存储的问题。因为很多时候边缘是布署在资源比拟少的机器下面，甚至是 ARM 的工业盒子下面，在资源应用上十分的刻薄， 而当初得益于 TDengine 超强的压缩算法，咱们应用十分小的存储空间就存储了几千万数据，压缩率远超 1/20，在单机下面布署一个 TDengine 服务器就能够轻轻松松地存储上亿的数据 。
此外它还领有超强的计算能力，占用的资源也十分小，在咱们的业务中千万级数据检索工夫达到了毫秒级，从用户角度来说产品体验十分好 。在运维层面，TDengine 提供规范的 SQL 语法，有过 SQL 应用教训的同学基本上很快就能上手，学习老本接近于零。
四、写在最初
事实上，TDengine 这款产品我曾经关注很久了，我也和涛思的同学们提出过一些在应用过程中发现的 Bug，从最后的版本到当初的产品，TDengine 变得更加弱小和成熟。作为它的“老朋友”，我在此也提出两个改良优化倡议，以便帮忙它更好的成长：
- 当初装置 TDengine Server 时要向下兼容 TaosClient，如果在降级 Server 时，我不须要再在本人的服务器下面同时降级 TaosClient，能够缩小一些部署步骤。
- 如果咱们用 kubernetes 进行部署，POD 删掉重启后服务就无奈启动了，还须要在挂载的数据文件夹外面手动去批改配置，十分地不灵便。
咱们与 TDengine 的单干不会止于此，将来等到 TDengine 更加成熟稳固后，不仅咱们的边缘计算存储要应用它，甚至咱们的中台数据也要迁徙到下面。
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。
