2. 存储需求分析：Tick数据的写入吞吐量、查询延迟、存储容量与成本要求
做Tick数据存储，第一步不是选数据库，而是搞清楚你的数据到底有多「野」。我见过太多团队，一上来就拍脑袋选ClickHouse或者InfluxDB，结果跑起来才发现写入扛不住，或者查询慢得像蜗牛。说白了，需求分析没做透，后面全是坑。
2.1 写入吞吐量：每秒几百万笔？别开玩笑
Tick数据最要命的就是写入量。你想想看，A股全市场5000多只股票，每只股票每秒可能产生几十笔Tick。期货更夸张，螺纹钢主力合约一天能出上百万笔。
核心指标：
- 峰值写入速率：每秒需要处理多少笔Tick？我建议按开盘前3分钟和收盘前3分钟的峰值来算，这两个时段往往是平时的5-10倍。
- 平均写入速率：全天平均每秒多少笔？这个决定了你的存储引擎日常负载。
- 写入并发数：多少个数据源同时写入？比如同时接入沪深交易所、期货交易所、期权市场。
实战经验：我在某券商做高频回测系统时，客户说「每天几千万笔Tick」。结果一测，开盘瞬间峰值达到每秒120万笔。当时用的MongoDB直接被打挂了。后来我们改用ClickHouse，配合批量写入和异步刷盘，才勉强扛住。
写入吞吐量估算公式：
峰值写入量 = 股票数量 × 每只股票每秒Tick数 × 安全系数(1.5~2.0)
举例：
A股全市场：5000只股票 × 20笔/秒 × 2 = 200,000笔/秒
期货全市场：200个合约 × 50笔/秒 × 2 = 20,000笔/秒我的建议：别只看平均值。峰值写入能力才是选型的关键。我习惯把峰值写入量再乘以1.5，留出余量。因为行情爆发时，数据量可能翻倍。
2.2 查询延迟：毫秒级还是秒级？
查询延迟这事，得看场景。做实时风控的，和做盘后分析的，要求完全不一样。
典型查询场景：
- 单只股票历史回放：查询某只股票过去1小时的Tick数据。延迟要求：秒级以内。
- 全市场快照查询：查询当前所有股票的最后一笔Tick。延迟要求：毫秒级。
- 复杂聚合查询：比如计算某只股票过去5分钟的成交量加权均价。延迟要求：秒级。
- 跨品种关联查询：同时查询股指期货和ETF的Tick数据。延迟要求：秒级。
注意：我曾经踩过一个坑——客户说「查询要快」，结果没说具体多快。我们按毫秒级优化了半年，最后发现他们只是做盘后统计，秒级就够了。白白浪费了时间和成本。
延迟分级建议：
| 场景 | 延迟要求 | 推荐存储方案 |
|---|---|---|
| 实时风控/交易 | < 10ms | 内存数据库 + 时序数据库 |
| 盘中监控/回放 | < 1s | ClickHouse / InfluxDB |
| 盘后分析/回测 | < 10s | Parquet + 列式存储 |
| 历史数据归档 | 分钟级 | 对象存储 + 压缩 |
2.3 存储容量：一天几个TB？
Tick数据有多占空间？我给你算笔账。
单笔Tick数据大小：
典型字段：
- 时间戳：8字节
- 股票代码：4字节
- 最新价：8字节
- 成交量：8字节
- 买卖盘口：100字节（5档买卖）
- 其他：20字节
合计：约150字节/笔每日存储量估算：
A股全市场：
200,000笔/秒 × 150字节 × 4小时 × 3600秒 = 约432GB/天
期货全市场：
20,000笔/秒 × 150字节 × 6小时 × 3600秒 = 约64.8GB/天实际案例：我参与过的一个项目，存储全市场Tick数据，每天新增约800GB。用了ClickHouse的列式压缩后，降到每天150GB。压缩比大概5:1。但注意，压缩比取决于数据特征，别盲目乐观。
存储成本控制策略：
- 分层存储：热数据用SSD，温数据用HDD，冷数据用对象存储。
- 数据压缩：列式存储 + 专用压缩算法（如ZSTD、LZ4）。
- 数据降采样：老数据可以按分钟、小时聚合，丢弃原始Tick。
- 数据过期：设定保留周期，比如只保留最近3个月的原始Tick。
我的习惯：先按不压缩估算容量，再乘以0.3（压缩后的比例），最后乘以1.5的安全系数。这样出来的数字，基本不会出大问题。
2.4 成本要求：别让存储吃掉利润
做量化交易，存储成本是隐形成本。很多人只盯着计算资源，忽略了存储。我见过一个团队，一年存储费用花了200万，比服务器还贵。
成本构成：
| 成本项 | 说明 | 占比 |
|---|---|---|
| 存储介质 | SSD vs HDD vs 对象存储 | 40% |
| 计算资源 | 查询和写入消耗的CPU/内存 | 30% |
| 网络带宽 | 数据迁移和备份 | 15% |
| 运维人力 | 数据库维护、调优、故障处理 | 15% |
避坑指南：我曾经为了省存储成本，选了纯HDD方案。结果查询延迟从100ms飙到5秒，直接被业务方投诉。后来才明白，存储成本不能只看单价，要看「每TB每秒查询次数」的性价比。
成本优化建议：
- 按需扩容：别一次性买满，用多少扩多少。
- 冷热分离：最近7天的数据放SSD，7天到3个月的放HDD，3个月以上的放对象存储。
- 数据压缩：选对压缩算法，能省50%以上空间。
- 查询优化：减少全表扫描，用索引和分区裁剪。
2.5 需求分析总结：一张图看懂
说了这么多，我画了一张图帮你理清思路。这张图是我做Tick存储选型时必用的框架。
这张图的核心逻辑是：四个维度不是孤立的。写入吞吐量高了，存储容量自然大；查询延迟要求严，成本就上去了。你得找到那个平衡点。
我的经验：做需求分析时，我习惯先列一个「最坏情况清单」——峰值写入、最低延迟、最大容量、最高成本。然后问自己：如果所有条件同时达到最坏，系统还能不能扛？如果扛不住，哪个维度可以妥协？
嗯，到这里，存储需求分析的核心内容就讲完了。记住一句话：没有最好的存储引擎，只有最适合你需求的存储引擎。下一节，我们会基于这些需求，开始对比具体的存储方案。
公众号:蓝海资料掘金营，微信deep3321