ByConity 对象存储（OSS）带宽优化策略与实践

在分布式数据库系统 ByConity 的实际部署中，对象存储（OSS）作为核心存储组件，其网络带宽占用问题常成为企业级用户关注的焦点。本文将从技术原理、问题分析和优化方案三个维度，深入探讨如何有效降低 OSS 访问带宽。

一、带宽占用问题本质

当 ByConity 集群采用共享式 OSS 架构时，多部门共用存储资源会面临带宽争用问题。实测数据显示，单个 write worker 进程在数据写入阶段可产生双向 1Gbit/s 的流量峰值，主要来源于：

1. 数据写入流量：原始数据经压缩后写入 OSS
2. 合并操作（Merge）流量：后台进程读取已压缩数据、解压合并、再压缩写回

二、核心工作机制解析

1. 写入阶段优化
   ByConity 在数据落盘时自动执行列式压缩，例如 100MB 原始数据经压缩可降至 10MB 级别。系统采用批处理机制，建议用户通过增大单次写入批次（如 100K 行数据）来提升压缩率，减少高频小数据写入导致的压缩效率损失。

2. 合并操作原理
   合并过程涉及完整的数据生命周期：

   • 从 OSS 读取压缩数据块
   • 内存解压后执行归并排序
   • 重新压缩后写回 OSS 该过程虽然保证数据有序性，但会产生显著的回读流量。

三、深度优化方案

1. 写入策略调优

   • 调整 max_insert_block_size 参数增大单批次写入量
   • 启用 optimize_on_insert 设置，在内存中预排序后再压缩写入

2. 合并策略控制

   • 通过 system.server_part_log 表监控合并频率：

     SELECT toStartOfHour(event_time) AS t, 
            countIf(event_type = 1) AS writes,
            sumIf(num_source_parts, event_type = 2) AS merges
     FROM cnch(server, system.server_part_log)
     WHERE event_date >= today()
     GROUP BY t ORDER BY t;
     

   • 调整 merge_tree 相关参数（如 max_bytes_to_merge_at_max_space）控制合并触发阈值

3. 本地缓存策略
   对于时效性要求不高的场景：

   • 启用 local_disk_cache 暂存新写入数据
   • 设置合理的缓存超时（如 5-10 分钟），积累足够数据量后批量写入 OSS
   • 注意：此方案会导致缓存数据存在查询可见性延迟

四、生产环境建议

1. 对于带宽敏感场景，建议将合并操作调度至业务低峰期执行
2. 采用 TTL 策略自动清理过期数据，减少无效合并
3. 监控 OSS 流量时需区分正常写入流量与合并回流量的比例
4. 考虑使用 EC 编码等存储策略降低存储成本，间接缓解带宽压力

通过上述优化组合，企业用户可实现 OSS 带宽消耗的精细控制，在数据一致性与资源消耗间取得平衡。实际效果取决于具体业务的数据特征和查询模式，建议通过灰度测试确定最佳参数组合。