结论先说：原始回答的正文和它的索引，不该放同一个地方。正文体积大、写一次读多次、按轮整段取，放对象存储；问法、平台、时间这些筛选维度，配上聚合结果，放数据库。最常见的做法是两套一起用：对象存储存正文，数据库存索引与指标，查询时先走索引拿到定位，再去取正文。
这里说的「选型」，指的是把原始回答正文与它的索引、聚合分别放在哪一类存储上，以及为此要付的查询代价与容量代价。选型的依据不是数据量大小，是查询形态。
这篇按查询形态讲：两种存储各自的代价结构、什么场景放哪边、组合方案怎么切、一段可跑的量级估算脚本，最后给五个检查与三个反问。文中条数、正文大小与倍率都是假设值，只用来演示估算方法。
一、两种存储的差别不在容量
很多人拿容量做对比：同样的数据，哪边便宜放哪边。我试过，按容量算出来的结论经常反过来。
数据库的成本主要跟着行数、索引数量和宽列走；对象存储的成本主要跟着对象数量和请求次数走，容量反而便宜。一个按行计费，一个按次计费，量纲不同，直接比单价没有意义。
所以我一般先不问哪个便宜，先问这批数据平时怎么被读。
二、按查询形态选
查询形态：更适合放 ｜ 原因
按轮整段取：回灌、归档、校验：对象存储 ｜ 一次前缀列举，顺序读，不碰索引
按问法、平台、时间多维筛选：数据库 ｜ 索引直接定位，不必扫全量
频繁 join 与聚合：数据库 ｜ 计算下推，少搬数据
长期冷存、极少读：对象存储 ｜ 按量计费，适合不常访问
单条随机读、频繁改写：数据库 ｜ 行级定位与事务
这张表我按「先看读法，再看写法」排。写多读少的原始正文，天然适合对象存储；读多写少的索引与指标，天然适合数据库。
三、数据库的代价：行数、索引、宽表
数据库存原始正文，头一道坎是宽表。回答正文平均按两 KB 算，一百万条就是接近两 GB 的正文；加上索引与行存开销，实际占用通常还要再乘一个系数。
第二道坎是索引。索引让筛选变快，但每个索引都要占空间、拖慢写入。为了几个筛选维度建五六个索引，写入速度掉下来，收益却集中在少数查询上。
第三道坎是备份与恢复。整库备份跟着数据量走，正文越多窗口越长。原始正文只在回灌时用一次，却让每次备份都变慢，这笔账不划算。
四、对象存储的代价：请求次数与分片
对象存储容量便宜，代价在请求次数。按对象计费时，一条回答一个对象，一百万条就是一百万次请求；全量扫一遍的成本跟对象数成正比。
分片大小是这里的关键旋钮。每对象一千条，一百万条是一千个对象；每对象一万条，就是一百个对象。对象数降一个量级，扫描请求也降一个量级。
代价是随机读变粗：想读其中一条，也得取回整个分片。所以分片维度要跟查询形态对齐，按轮、按天分片，整段取最划算；按单条随机读，就会浪费。
五、组合方案：正文与索引分家
我的做法是两套一起用。对象存储按轮分片存正文，每片带一份分片摘要；数据库存三类东西：问法、平台、时间这些维度列，指向分片的定位信息，以及算好的聚合结果。
查询时先走数据库索引，拿到哪一轮、哪个分片，再去对象存储整片取回：索引负责定位，对象存储负责搬大块正文。
六、一段可跑的量级估算
下面这段脚本按假设参数估算容量与请求次数，我在本地跑过。
rows, avg_kb = 1_000_000, 2
gb = rows * avg_kb / 1024 / 1024
print("原始正文总量 GB:", round(gb, 2))
print("行存加索引后 GB（按 1.8 倍估）:", round(gb * 1.8, 2))
for per_obj in (1000, 10000):
n = rows // per_obj
print(f"每对象 {per_obj} 条 → 对象数 {n}，全量扫一遍 GET {n} 次")
round_rows = rows // 30
print("每轮约条数:", round_rows)
print("一轮对象数（每对象 1 万条）:", -(-round_rows // 10000))
print("按问法筛 1 万条，数据库读行数:", 10_000)
真实输出：
原始正文总量 GB: 1.91
行存加索引后 GB（按 1.8 倍估）: 3.43
每对象 1000 条 → 对象数 1000，全量扫一遍 GET 1000 次
每对象 10000 条 → 对象数 100，全量扫一遍 GET 100 次
每轮约条数: 33333
一轮对象数（每对象 1 万条）: 4
按问法筛 1 万条，数据库读行数: 10000
输出里最值得看两个数：容量差不到一倍，请求次数差十倍。只算容量，就会漏掉对象数这个变量。
七、五个能立刻做的检查
第一步，我把最常用的五类查询写下来，标出每类是整段取还是按条件筛。
第二步，我数一下现在有多少个对象、每个对象多大、一次全量扫要多少次请求。
第三步，数一下数据库里原始正文占了多少空间、建了几个索引、备份窗口多长。
第四步，我拿「按问法筛一万条」做实测，看两条路径各读多少数据。
第五步，我把结论写成一句：正文放哪、索引放哪、聚合放哪，再按这句去建表或建桶。
八、三个绕不开的反问
问：数据量不大，是不是全放数据库更省事？
答：小数据量确实可以。 但要看增长：正文体积增长快、索引增长慢，等数据涨到要拆的时候，改造成本比一开始分家高。
问：对象存储没有索引，筛选怎么办？
答：索引放数据库。 对象存储只负责正文搬运，索引与聚合留在数据库，查询先定位再取正文。
问：两套存储会不会带来一致性问题？
答：会有，所以要定主从。 正文以对象存储为准，索引与指标由正文重算；重算前先校验正文对象，对不上就停在对象层修。
数据说明（PROV）
数据源：本文为方法说明，示例条数、正文大小与倍率均为假设值，不引用任何真实监测结果。
查询日：无真实查询日；示例不绑定日期。
样本：假设一百万条回答、平均正文两 KB、每月一轮全量回灌。
口径：容量按原始正文估算，请求次数按对象数估算；单价随厂商与区域变化，本文不给金额。
局限：示例只演示容量与请求次数两条代价线；跨区域与冷热分层不在本文范围。
九、边界
这套选型我承诺三件事：正文与索引分家、查询先定位再取正文、容量与请求次数都算一遍。产品名可以换，这两条代价线不能只算一条。
本文不承诺任何存储费用或性能数值，也不评价任何存储产品。
本文含 AI 辅助生成内容，经人工核实。
