艾超：TDSQL for PostgreSQL监控架构演进思路

艾超腾讯云高级工程师 监控业务的挑战1 监控架构的历来演进2 监控场景的时序数据 PG中的时间序列数据 未来展望 在数据库管控运维业务中，监控是最重要的基础能力之一。是保持数据库可靠性、可用性、性能的不可或缺的一环。 规模化 高性能 实时性 准确性 准确性 实时性 高性能 规模化 优点：1、拥抱开源2、定制少、开发量小 认知： 1、精简架构便于提升线下交付效率2、线下与公有云不同，一般规模较小 缺点： 策略：1、基于当前线下交付架构，不新增任何组件2、利用高度可扩展的设计，配置化一切 1、新增组件，增加复杂度2、受限于框架，精度、性能可调节性不高 3、架构长期演进的成本 使用场景 多维度聚合 读写特点 分组聚合按照指定的维度进行分组，然后在每个分组中进行聚合计算。 Web页面 •图表•报表•多维度•多粒度•环比•同比 以固定的时间间隔不断写入，而且写入频率通常很高；不同序列按各自频率写入数据点 多标签聚合将多个维度组合成为一个标签，然后对标签进行聚合计算。 顺序范围读按照时间顺序进行读取，并支持时间范围的查询 HTTPAPI 写多读少 同时对多个维度进行聚合计算，以便更好地分析数据的交叉情况。 •高频查询•数据归档•异常检测•聚合计算•告警生成 从统计数据上看，写占比九成以上 冷热分离数据的价值随时间推移而下降，将不同时间段的数据分类管理 多序列聚合将时序数据划分为多个时间序列，然后对每个时间序列进行聚合计算。 受监控对象数量和时间的增长，读写效率会变得极低。 当表数据量变得很大时，运维会极其困难，数据备份和恢复风险也很大。 只能用于极简场景，非常不推荐。 查询时索引和执行计划更加复杂，但速度可能会更慢。 分区子表和单表一样，也会承受单表数据量上升带来的问题。 创建和维护需要一定的成本。在数据量和维度规模上来以后，维护复杂性会上升。 支持多个维度进行分区，可以根据业务需求对时序数据进行更细粒度的切分和管理。 分出来的子表足够小，查询性能基本可以保证，但也会出现多个分区表关联而增加IO次数。 创建和维护需要一定的成本。在数据量和维度规模上来以后，维护复杂性会上升。 兼容性和性能作为PG的一个扩展，与PG生态完全兼容。使用连续聚合（Chunk），通过异步任务闲时计算，提高查询时速度 多维度分区 可将时序数据根据多个维度进行切分，这使得它可以更好地处理复杂的时序数据。 便于使用和管理使用超表就像使用普通单表一样，创建和维护工作量大减 内置任务调度框架异步压缩行存列存转换持续聚合 标准化