随着 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 时序数据交换群，和业余的解决方案架构师点对点沟通，群策群力攻克数据技术难题。