苏州大学：从 PostgreSQL 到 TDengine

小 T 导读：除了要对几千台摄像头进行数据采集加在线检测，苏州大学还有 1500 多台交换机和 4000 多台服务器，在数据库的选择上，它需要在扛住如此大量设备 24 * 7 高频长期写入的同时，还要确保相当出色的查询效率。从 PostgreSQL 到 TDengine，本文分享了江苏纵目在面对业务难点时，在数据库的选择、应用和成效方面的经验。

企业简介

苏州大学（Soochow University），简称“苏大”，坐落于美丽的江苏省苏州市，是教育部与江苏省人民政府共建高校，国家“双一流”建设高校，国家“211 工程”、“2011 计划”首批入选高校，前身是 1900 年创办的东吴大学，是中国最早以现代大学学科体系举办的大学。

项目介绍

作为一所重点高校，苏州大学具备规模较大的 IT 基础设施及应用系统，资源压力大，网络故障波及用户数量多。为保障全校系统以及网络、服务器硬件、操作系统的可用性、可靠性和安全性，学校必须建立规范且全面的运维管理体系。在此背景下，我们江苏纵目与苏州大学与开展技术合作，打造了苏州大学智慧运维管理平台。

该业务场景面临着以下难点：

资源设备类型、品牌、版本繁杂，各厂商协议区别大，人员经验无法全覆盖，原厂难以及时响应。
业务应用、服务与资源的关联关系复杂，问题定位时间远超过解决问题的时间。
缺乏事前运维的有效工具，系统网络异常会波及各部门/院系师生的教学工作的开展，被动处理负担重，导致业务部门投诉。

海量设备数据的存储和查询问题首当其冲

对于这样一个规模较大的 IT 基础设施及应用系统来说，解决问题本身并不难，难的是如何高效地处理小问题、科学地预防大问题、迅速地定位问题的根本原因。就从监控数据层面来说，如果想对设备进行 24 * 7 不间断监控的话，那么海量的设备数据存储和查询对于 Database 的压力将会非常大。

苏州大学有几千台摄像头，光摄像头的数据采集加在线检测的数据量就已经很大了，更别提还有 1500 多台交换机、4000 多台服务器，在数据库的选择上，它需要在扛住如此大量设备 24 * 7 高频长期写入的同时，还要确保相当出色的查询效率。

此前，我们使用的是 PostgreSQL 数据库单机版，由于是关系型数据库（Relational Database），在该时序数据的场景下数达到亿级数据量时，查询分析延迟会达到大几秒，压缩率上也不太理想（后文会有实际对比），无法撑起一个全域一体化运维监控平台的持续运行。

数据的存储与读写是一切业务的根基，因此数据库选型这个环节尤为重要。早在此前，我们就针对此类业务对时序数据库（Time Series Database）做了充分的调研与实测。其中 TDengine 作为一个专为物联网、车联网、工业互联网、运维监测等优化而设计的时序数据库，十分契合该场景。最终我们选择将 TDengine 集成到我们自研且专用于监控时序数据的 Argus 平台中 https://zmops.com。