性能指标参考
参考原理, 数据加工任务的总体速度取取决于源shard的数量、用户配置的规则逻辑和复杂度有关, 一般可以按照1MB每秒每shard(=85GB每天每shard)规划.
例如: 源logstore的数据写入速度是每天1TB, 那么需要分裂源logstore的shard数量为1024GB/85=12个.
数据加工与性能的关系
数据加工的速率与加工的规则有关, 具体体现如下:
输出写入相关:
- 事件大小相关: 写入事件越多(进行了分裂), 写入事件字段越多, 内容越长, 写入的数据包计算与网络量消耗越大, 速度越慢. 反之越快.
- 事件分组相关: 写入目标越多, 事件标签TAG越多, 输出的数据包日志组越多, 网络交互越多, 速度越慢. 反之越快.
加工逻辑相关:
- 加工逻辑约复杂, 搜索计算等越多, 使用频繁外部资源同步, 对计算与网络消耗越大, 速度越慢. 反之越快.
源logstore实时数据加工扩展
可以通过增加shard数量来实现扩展.
源logstore历史数据加工扩展
shard分裂仅仅对新写入数据有关. 如果历史数据量较大, 且shard数量较少的情况下. 可以对源logstore构建多个数据加工任务, 支持分别配置无重叠的加工时间即可. 注意: 加工时间是日志接收时间即可, 具体配置参考控制台配置
目标Logstore的扩展
目标Logstore的shard数量主要由2个方面决定:
- 数据加工的写入速率. Logstore单个Shard的写入速率上线是5MB/s, 因此可以根源logstore的shard数量, 加工的并发读来估算.
例如源logstore有20个shard, 那么推荐目标logstore至少有4个shard. - 目标logstore的是否有建立索引, 做查询统计的需求, 如果目标Logstre希望建立索引并且进行统计查询(SQL), 那么建议基于SQL统计每次查询的覆盖范围是: 每5000万条日志一个shard的粒度来规划.
例如, 每天加工并写入10GB日志, 每条1KB的话, 有1千万条日志每天规模, 每次查询和统计希望可以覆盖30天数据量, 其总体日志量大约是3亿条日志, 建议目标logstore的shard数量规划为6个shard.
进一步参考
欢迎扫码加入官方钉钉群获得实时更新与阿里云工程师的及时直接的支持: 
