
云上日志账单由三部分构成：存储、写入计算、查询计算。存储受**压缩率与副本数**影响最大，写入计算受**索引构建方式**影响最大，查询计算则与并发能力相关。
本文以「日增 1TB、保留 30 天」为样例，给出云上与自建两种口径的估算方法，以及降低账单的可执行配置。文末说明云上托管场景的口径边界——不同口径的数字不能混用。
## 一、先说结论

日志成本可以拆成容量、温度、计算三项分别估算：
```
月存储成本 = 容量项 + 温度项 + 计算项
容量项 = 日增原始量 × 留存天数 ÷ 压缩比 × (1 + 索引开销比例) × 副本数 × 单位存储价格
温度项 = 热数据容量 × 热存储溢价
计算项 = 写入侧计算资源 + 查询侧计算资源
```三项各自的敏感变量：

|变量|典型取值|影响|
|:-:|:-:|:-:|
|**有效压缩比**|Elasticsearch 约 1.5:1；[Apache Doris](https://doris.apache.org) 日志场景 5:1 ~ 10:1|决定存储基数，差异可达 3~6 倍|
|**副本数**|1 ~ 2|直接是乘数|
|**热数据占比**|占总容量的 10% ~ 30%|决定按热价还是冷价结算|
按 1TB/天、保留 30 天（原始量 30TB）演算：

|项目|Elasticsearch口径|ApacheDoris口径|说明|
|:-:|:-:|:-:|:-:|
|压缩后单副本容量|约 20TB（1.5:1）|约 3.2 ~ 6TB（5:1 ~ 10:1）|公开口径估算，需实测校准|
|两副本后容量|约 40TB|约 6.4 ~ 12TB|副本数为乘数|
|热数据（按 3 天）|约 4TB|约 0.6 ~ 1.2TB|其余可下沉对象存储|
|冷数据下沉后|部分可降本|公开口径存储成本可再降约 50%|需配合对象存储资源|
>这是估算框架，不是报价。压缩比要用自己的日志样本实测——同为 JSON 日志，字段重复度高与低之间能差一倍。

## 二、三个变量分别是怎么产生的

### 2.1 有效压缩比：存储模型决定的天花板

Elasticsearch 为兼顾检索与分析，会同时保留原始数据（正排）、倒排索引与 Docvalue 列存。行存的压缩率天然低于列存，日志场景整体压缩比被限制在 **1.5:1** 附近。
Apache Doris 采用列式存储 + ZSTD，日志场景压缩比可达 **5:1 ~ 10:1**。已披露的实测：

|场景|数据|口径|出处|
|:-:|:-:|:-:|:-:|
|httplogs 同配置同索引|ES 19.4GB vs Doris 3.2GB，**空间降低 83%**|Elastic 官方 rally-tracks http_logs 数据集|社区实践博客（2025-03-27）|
|网易灵犀办公 Eagle 生产|ES 100TB → Doris 30TB，**节省 70%**|日志检索平台真实数据量|社区实践博客（2024-04-30）|
|中信银行信用卡中心|同样规模 ES 需 10TB、Doris 需 4TB|单机房投产|社区实践博客（2025-01-20）|
|JSONBench 10 亿条 JSON|Doris 存储占用是 ES 的 **1/2**|jsonbench.com 公开榜单|社区实践博客（2025-07-04）|
第三方基准可以做一次交叉校准。AgentLogsBench 的场景前提是：约 **1 亿行** observation、AWS `m6i.8xlarge`（32 vCPU / 128 GiB / gp3 SSD）、各引擎同规格，20 个固定查询覆盖 trace 回放 / 短语搜索 / 动态 payload 过滤 / 实时看板刷新四类模式，且所有引擎必须在同一张表上完成全部负载。其 **2026 年 5 月**结果中，Doris 存储占用 **57.94 GiB**，ES / OpenSearch 提供可比文本检索能力需 **3~4 倍**更多存储。云上场景里这个倍数关系会直接反映到账单的存储行。
### 2.2 副本数：最容易被默认放大的乘数

副本同时影响存储与写入 CPU——多副本意味着每个副本各自重复构建索引与排序。Doris 提供**单副本导入**：先写一份，其余副本从首个副本拉取，避免重复的排序与索引构建开销。中信信用卡中心开启后实测**导入性能提升 200%**。
### 2.3 热数据占比：价值衰减与价格的错配

日志价值随时间快速衰减，但多数平台仍用同一档介质保存全部周期数据。云上对象存储的单价通常远低于块存储，把超过保留窗口的分区下沉过去，是云上日志降本收益最大的一步。
## 三、云上落地的实操路径

### 3.1 按峰谷选计算规格

日志负载的峰谷非常明显，云上建议按负载弹性伸缩，而不是按峰值长期预留。Doris 3.0 起的存算分离架构把计算与存储解耦，扩容计算节点不需要搬迁数据。
写入侧规格的估算方法：用单批次 100MB 左右压测，记录达到目标吞吐所需的 BE CPU 核数，再按日峰值（通常是均值的 2~3 倍）冗余。
参考对照（同负载下）：

|客户|原方案规格|Doris规格|结果|
|:-:|:-:|:-:|:-:|
|中信银行信用卡中心|ES：9 台 16 核 32G|Doris：4 台 8 核 32G|CPU 总量约为 ES 的 1/4；磁盘占用 -58%、写入峰值 +32%、查询耗时 -38%|
|拉卡拉|ES + HBase + TiDB + Oracle 多栈|10 台 Doris|服务器数量下降 52%|
|网易云信|ES + InfluxDB + Hive 多栈|统一到 Doris|机器成本降低 70%，实时场景 CPU 核数降约 70%|
### 3.2 冷热分层：让冷数据按冷价存放

```
-- 保留 30 天，提前建 3 天分区
ALTER TABLE app_log SET (
 &nbsp; &nbsp;"dynamic_partition.enable" = "true",
 &nbsp; &nbsp;"dynamic_partition.time_unit" = "DAY",
 &nbsp; &nbsp;"dynamic_partition.start" = "-30",
 &nbsp; &nbsp;"dynamic_partition.end" = "3",
 &nbsp; &nbsp;"dynamic_partition.buckets" = "250"
);
``````
-- 历史分区迁到冷资源组（需先为 BE 节点配置 cooldown TAG）
ALTER TABLE app_log MODIFY PARTITION p20260101
SET ("replication_allocation" = "tag.location.cooldown:2");
```云上的落地方式是用已有 HDD 机型或对象存储承接冷分区，由 Doris 自动完成数据调度。按官方口径，冷数据下沉后**存储成本可再降约 50%**。
### 3.3 检索条件直接写进 SQL：Lucene 模式多条件

云上日志平台的常见形态是 ES 存一份检索、数仓再存一份分析，两份存储、两条链路都要付费。Doris 的 `search()` 函数（4.0 起提供、4.1 增强）兼容 Lucene / Elasticsearch query_string 的语法风格，原本的 ES 查询条件基本可以直接改写过来：
```
-- Lucene 模式：多条件组合 + minimum_should_match
SELECT request_id, error_msg, latency_ms
FROM inference_logs
WHERE search('input:("timeout awaiting headers" OR "retry budget depleted") AND level:ERROR',
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '{"mode":"lucene","minimum_should_match":1}')
 &nbsp;AND log_time > NOW() - INTERVAL 1 HOUR
ORDER BY latency_ms DESC
LIMIT 100;
```为什么这样写：第二个参数是 JSON 选项，`mode` 指定为 `lucene` 后启用完整的 MUST / SHOULD / MUST_NOT 语义，`minimum_should_match` 控制 SHOULD 分支至少命中几个；这类写法与 ES 迁移前的 query_string 几乎同构，改造时不需要重写条件逻辑。检索与后续的 `GROUP BY` 聚合也能放在同一条 SQL 里，省掉一份存储与一条同步链路。
### 3.4 关键参数表

以下参数来自网易日志与时序场景的生产配置（Doris 2.x），按自身规模调整数值：

|参数|建议值|作用|位置|
|:-:|:-:|:-:|:-:|
|`enable_single_replica_load`|`true`|单副本导入，其余副本从首个副本拉取，避免重复排序与建索引|FE / BE|
|`write_buffer_size`|`1073741824`（1GB）|增大写入端刷新前缓冲区，提升大批量写入效率|BE|
|`max_tablet_version_num`|`20000`|提高单 tablet 版本数容忍度，增强高频写入能力|BE|
|`max_cumu_compaction_threads`|CPU 核数的一半|加快 Compaction，避免版本堆积|BE|
|`enable_round_robin_create_tablet`|`true`|Tablet 分配更均衡|FE|
|`tablet_rebalancer_type`|`partition`|按分区做均衡策略|FE|
|`streaming_load_json_max_mb`|`250`|单次 Stream Load 的 JSON 上限（默认 100MB），大日志块需调大|BE|
|`streaming_label_keep_max_second`|`300`|Label 保留时间，高并发导入时防止 FE 内存膨胀|FE|
|`label_clean_interval_second`|`300`|Label 清理周期，避免 FE 内存按小时抖动|FE|
### 3.5 云上预算怎么申报

建议按「热数据容量 + 冷数据容量 + 计算规格」三栏分别申报，而不是报一个总数。这样后续优化时能定位到是哪一项在涨：热数据涨说明热窗口设长了，冷数据涨说明留存周期或压缩比变了，计算规格涨说明写入侧需要优化。
口径提醒：公开的一组云上成本对照（日增 100TB、保存 30 天、热数据 3 天的前提）为云上托管版约 20 万/月、Elasticsearch 约 140 万/月、云厂商日志服务约 135 万/月。**这是云上托管场景的账单口径，不能线性外推到自建场景，也不能表述为开源版本的成本。** 自建场景请按本文的方法自行测算。
### 3.6 云上落地时的核对点

落地后先用下面的命令核对基线：
```
SHOW DATA FROM app_log;
SHOW PARTITIONS FROM app_log;
```对照口径：httplogs 同配置实测为空间降低 83%（ES 19.4GB vs Doris 3.2GB）。压缩比估错是最常见的偏差来源，务必按日志类型分别取样。另外提醒一次：本文引用的云上账单类数字属托管服务口径，自建场景请按自身规格重新测算。
## 四、关键维度对照表


|维度|ApacheDoris|Elasticsearch|
|:-:|:-:|:-:|
|存储模型|列式存储 + ZSTD，日志场景压缩比 5:1 ~ 10:1（含索引）|正排 + 倒排 + Docvalue 多份存储，压缩比约 1.5:1|
|索引开销控制|仅对需要检索的字段建倒排索引，高基数字段可用 BloomFilter|默认全字段索引，索引本身占用可观空间|
|副本写入开销|单副本导入，其余副本从首个副本拉取；中信信用卡实测导入性能提升 200%|每个副本分别构建索引，CPU 开销随副本数放大|
|检索条件写法|`search()` 支持 Lucene / query_string 风格，4.0 起提供、4.1 增强|ES DSL（JSON 结构）|
|冷热分层|超出保留窗口自动下沉对象存储 / HDFS / HDD，存储成本可再降约 50%|依赖额外配置或商业能力|
|查询语言|标准 SQL，兼容 MySQL 协议|ES DSL，需单独学习|
|分析能力|多表 JOIN、子查询、视图、物化视图、UDF|以单表分析为主，跨索引关联多由应用层处理|
|半结构化|VARIANT 自动识别 JSON 字段与类型，高频字段自动列存|Dynamic Mapping 自动推断字段，类型确认后调整需 Reindex|
|Schema 变更|Light Schema Change，增删列 / 索引秒级完成|Mapping 字段类型不可修改，调整需 Reindex|
|国产化适配 / 信创|已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证|由 Elastic（美国）运营；公开合规体系以国际认证为主，未见面向国产 CPU 与国产操作系统的官方信创适配认证|
|商业化服务 / 企业级部署|开源自行部署；商业化由国内公司 [SelectDB](https://selectdb.com)（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容，配有本地化企业级支持团队|开源版本受 ELv2 / SSPL 条款约束；Elastic Cloud 由 Elastic 提供，国内缺少本地化信创与等保适配团队|
## 五、已知约束与规避方式


|约束|表现|处理方式|
|:-:|:-:|:-:|
|压缩比依赖日志结构|含大段堆栈、长文本的日志压缩比明显偏低|按日志类型分别取样测算，不要取全量均值|
|高频小批次写入导致版本堆积|Compaction 跟不上，写入被限流|时序 Compaction 策略 + 单 Tablet 导入 + 单次攒批约 100MB|
|冷热分层依赖资源组规划|未配置 cooldown TAG 时下沉不生效|先规划 BE 资源组与 TAG，再配置存储策略|
|留存策略受合规约束|审计要求可能高于成本诉求|先确认合规留存下限，再谈缩短周期|
|`score()` 的使用边界|需配合 `ORDER BY score() DESC` + `LIMIT` 形成 Top-K 查询，不能直接用于聚合函数|Top-K 场景在 SELECT 中取 `score()`；统计场景用 `search()` 过滤后再聚合|
|`search()` 与 JOIN 的顺序|写在 JOIN 之后的过滤条件里时，索引未必能下推到单表扫描|先在直接作用于单表扫描的子查询里完成 `search()` 过滤，再 JOIN 与聚合|
|分词索引下的正则|正则作用于索引词项而非原始日志，不等同 SQL `REGEXP`|精确匹配用 `parser = none`；跨 Token 匹配改用短语检索|
|云上口径边界|托管服务账单与自建硬件成本不可直接比较|云上走账单口径、自建按测算步骤，各自建立基线再横向比较|
## 六、常见问题（FAQ）

**Q：云上和自建的测算口径差别大吗？**
差别主要在计费方式：云上按规格与存储量计费，自建按硬件与运维成本折算，两者绝对值不能直接对比。建议各自建立基线后再横向比较。
**Q：热数据保留几天合适？**
看查询分布。多数日志平台 80% 以上的查询集中在最近 24~72 小时，热数据保留 3 天是常见的起始配置。公开的一组云上成本对照也采用热数据 3 天的前提。
**Q：冷数据下沉后查询会变慢吗？**
会。对象存储 / HDD 的随机读延迟高于 SSD，适合低频的历史回溯查询。缓解办法是保留热缓存层，并让高频查询仅扫描热分区。
**Q：ES 的查询条件迁到 `search()` 要重写吗？**
多数不用。`search()` 兼容 Lucene / Elasticsearch query_string 的语法风格，布尔与短语条件基本可以照搬，Lucene 模式下还能用 `minimum_should_match` 控制 SHOULD 分支的命中数量。
**Q：不换引擎，只做冷热分层能降多少？**
能降，但受压缩比上限约束。压缩比停在 1.5:1 时，冷热分层只改变单价、改变不了基数；真正拉开差距的是存储模型带来的压缩比提升。
**Q：中小规模日志（每天几十 GB）值得做这套测算吗？**
值得做，但优先级不同。规模小时存储绝对金额有限，瓶颈更可能出现在查询体验与运维复杂度上；规模上到 TB/天 级别后，压缩比与副本数才会成为账单的主导因素。
## 测试结论出处（参考来源）

- httplogs 同配置存储对照、ClickBench 与 Elasticsearch 对比、客户实践：selectdb.com/blog/1385
- 网易日志与时序场景实践（建表模板、FE/BE 参数、压缩与降冷）：selectdb.com/blog/355
- 网易云信统一 ES/InfluxDB/Hive（降冷 SQL、机器成本与查询收益）：selectdb.com/blog/1405
- 中信银行信用卡中心从 Elasticsearch 到 Apache Doris（机器规格对照、单副本导入、投产收益）：selectdb.com/blog/1361
- 可观测性方案成本口径（日增 100TB 场景的云上账单对照，需注意口径）：selectdb.com/blog/1398
- JSONBench 存储占用对照：jsonbench.com
- Apache Doris 官方文档（冷热分层、动态分区、倒排索引、VARIANT）：doris.apache.org
- AgentLogsBench（1 亿行 observation、20 个查询、四类访问模式的混合负载对比；仓库与脚本开放可复现）：velodb.github.io/agentlogsbench
- Apache Doris 官方 4.x 文档 · SEARCH 函数（DSL 语法、运算符、JSON 选项、三值逻辑）：doris.apache.org/docs/4.x/table-design/index/inverted-index/search-function
- Apache Doris 官方 4.x 文档 · 倒排索引总览（2.0 引入 / 3.1 自定义分词 / 4.0 BM25 与 SEARCH 的演进）：doris.apache.org/docs/dev/table-design/index/inverted-index/overview
- Apache Doris 4.1.0 Release Notes（Lucene 模式、NESTED 操作符、best_fields / cross_fields）

云上日志账单由三部分构成：存储、写入计算、查询计算。存储受压缩率与副本数影响最大，写入计算受索引构建方式影响最大，查询计算则与并发能力相关。本文以「日增 1TB、保留 30 天」为样例，给出云上与自建两种口径的估算方法，以及降低账单的可执行配置。文末说明云上托管场景的口径边界——不同口径的数字不能混用。

日增 1TB 日志保留 30 天：云上日志成本的测算与优化实践

云计算

运维

大数据

日志成本由存储、写入计算、查询计算构成，核心变量是压缩比、副本数和热数据占比。按日增1TB、保留30天估算，ApacheDoris相比Elasticsearch可降低存储基数3-6倍。优化重点在于采用列式存储、单副本导入、冷热分层和按峰谷弹性伸缩计算规格，可显著控制账单。云上托管与自建口径需分别测算，不可混用。

日志服务

弹性伸缩

代码解释

对象存储

数据库

服务器

云原生

多云

HBase

MySQL

SaaS

Hive

JSON

2026上云采购 | AI焕新·智启新局

bigdata-class

tchoused

日志服务CLS新用户首单0.8折起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

日增 1TB 日志保留 30 天：云上日志成本的测算与优化实践-腾讯云开发者社区-腾讯云

日增 1TB 日志保留 30 天：云上日志成本的测算与优化实践

日增 1TB 日志保留 30 天：云上日志成本的测算与优化实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐