有限资源下如何实现最高效的数据处理？四个“智慧城市”项目寻找“最优解”
随着 5G 基站等通信工程的加快建设，城市治理、城市安全管理成为热门话题，物联设备在我们的社会中扮演的角色也变得越来越重要，智慧燃气、智能电表、智能井盖、智能交通等项目在众多城市开始布局，随着一众智慧城市项目的深入落地，海量时序数据的高效处理和成本管控也成为一个待解的难题。
为帮助大家寻找解决上述问题的最优解，我们汇总了四家比较具有代表性的智慧城市升级项目的架构改造案例，一起来看看他们都是如何做的。
SENSORO x TDengine
“我们进行的数据库调研测试结果显示，TDengine 的空间占用只有 Druid 的 60%（没有计算 Druid 使用的 Deep Storage）。针对单一设备的查询与聚和的响应时间比 Druid 有倍数的提升，尤其时间跨度较久时差距更明显（在十倍以上），同时 Druid 的响应时间方差也较大。在实际业务环境中，我们创建了多列的超级表，虽然会存在大量的空列，但得益于 TDengine 的优化，能达到恐怖的 0.01 的压缩率，简单计算下来大约需要 3.67GB 每亿条。”
业务背景
SENSORO 面向城市基础设施与核心要素提供全域数字化服务方案，建立城市级传感器网络所涉及的传感器种类十分多样，由此产生的数据量也十分庞大。在系统开发初期，SENSORO 先是选择了 Apache Druid 作为存储传感数据的数据库，然而在使用过程中却遇到了各种各样的问题，这使得其将目光转移到了 TDengine 上，但因为平台涉及的特殊数据模型，合作便一直搁置了下来。随后 TDengine 经过了多个版本迭代，支持了 join 查询，而 SENSORO 的数据模型也发生了变化，迁移到 TDengine 时不再需要做出很多的系统模块改动，由此双方的合作也开始快速展开。
架构图
北京智能建筑 x TDengine
“TDengine 帮助我们在边缘侧解决了一个很大的问题，即边缘存储的问题。因为很多时候边缘是布署在资源比较少的机器上面，甚至是 ARM 的工业盒子上面，在资源使用上非常的苛刻，而现在得益于 TDengine 超强的压缩算法，我们使用非常小的存储空间就存储了几千万数据，压缩率远超 1/20，在单机上面布署一个 TDengine 服务器就可以轻轻松松地存储上亿的数据。此外它还拥有超强的计算能力，占用的资源也非常小，在我们的业务中千万级数据检索时间达到了毫秒级，从用户角度来说产品体验非常好。”
业务背景
北京智能建筑是北京市在智能建筑和智慧城市领域的创新平台，同时也是冬奥科技平台公司、智慧冬奥国家重点项目设计单位和核心实施单位。在边缘侧采集数据存储方案中，其面临着在有限的计算资源下，如何实现最高效的数据存储、分析和计算的问题。经过调研与测试，其最终选择根据业务需求灵活搭配使用 TDengine 与 SQLite——由 TDengine 处理时序数据，SQLite 处理关系数据，以此更好地实现边缘侧的数据自治。
架构图
交通数据资源管理系统 x TDengine
“所有车辆最新位置信息的查询是交通运行监控中的重中之重，最初‘使用何种查询语句实现高效查询’是非常困扰我们的一件事，后面在 TDengine 社区团队的帮助下，我们利用了隐藏字段名 tbname 和 group by 方法，高效地查询了车辆的最新定位信息。在频繁查询的情况下，接近六万辆车的位置信息，只用了不到 1 秒的查询时间，简单而又高效，完全符合我们的业务需求；在数据统计分析上，一个 64 天数据量的表，进行每日数据条数的降维统计，所需时间也不到 1 秒。”
业务背景
为了强化全市交通运输管理、统筹综合交通发展、提升交通运行和管理效率，某市级管理单位建立了大交通数据资源管理系统及相关应用 “一图一库”。其中“一库”部分主要内容包括：数据接入、数据存储、数据共享；“一图”部分主要内容包括：GIS 信息及其关联数据信息在二维、三维地图上的形象表达。在数据中台的建设中，存在大量的时序数据应用场景，其中最为关键的就是车辆运行产生的时序数据的存储与使用。为了实现高效的业务处理， 研发人员决定从 InfluxDB、ClickHouse 和 TDengine 三款时序数据库（Time Series Database）中进行选型调研，最终凭借强大的产品力，TDengine 脱颖而出。
架构搭建上的考虑
由于该系统业务开发框架使用的是 Srping 框架，在使用 TAOS-JDBCDriver 进行开发时，可以选择两种方式进行数据入库——JDBC-JNI 方式或者是 JDBC-RESTful 方式。在 TDengine 官网，明确记载了“JDBC-RESTful 性能是 JDBC-JNI 的 50%～90%”，因此，其选择了 JDBC-JNI 方式进行多线程入库——以数据库连接池（Hikari、druid）+原生 SQL 执行写入为主要写入模式
数字政通 x TDengine
“压缩方面，通过查看 3 个节点的 Vnode 目录总大小，可以得知目前数据占用总量为 8.7GB。而从上述表结构我们也能看出实际入库数据总量大概为 203GB，经过压缩后为 8.7GB，压缩率达到了 4% 左右，大幅节约了存储成本。在查询上，对 9 亿数据量的超级表使用降采样查询，展示设备指标日月年线，耗时仅仅 0.22 秒。”
业务背景
随着智慧城市的加速建设，物联设备的管理问题凸显，为此，数字政通研发“城市管理物联网平台”对物联网设备实行监督，提供各类设备的实时监测数据及报警数据，进一步满足各类设备的数据分析、关联分析、历史分析、对比分析等需求。简单来讲就是通过鸟瞰整体数据来发现设备问题，便于及时派单处理，助力智慧城市管理。面对海量物联网数据的处理，TDengine 的高效存储给了数字政通相当大的助力。
架构图
结语
通过上面的几大案例我们可以看到，在解决海量时序数据处理效率低、处理成本高等问题上，关键点就是要选对合适的时序数据库（Time Series Database），当前市面上时序数据库产品众多，在性能提升和降低资源消耗上究竟谁能更胜一筹？如果你也在思考这一问题，那或许《写入性能：TDengine 最高达到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》、《查询性能：TDengine 最高达到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍》这两篇文章能给到你答案。
如果你的项目中也存在难以调节的数据痛点问题，欢迎添加小T vx：tdengine1，我们会邀请你加入 TDengine 时序数据交流群，和专业的解决方案架构师点对点沟通，齐心协力攻克数据技术难题。
