原始數據存資料庫還是物件儲存：成本與查詢代價

2026-11-03 5

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文探讨存储选型核心原则：**正文与索引应分离存放**。大体积、整段读的原始回答存对象存储（按轮分片），轻量、多维查询的索引与聚合存数据库。选型关键在**查询形态**（非数据量），需同步评估容量与请求次数代价。附估算脚本与实操检查清单。（239字）

结论先说：原始回答的正文和它的索引，不该放同一个地方。正文体积大、写一次读多次、按轮整段取，放对象存储；问法、平台、时间这些筛选维度，配上聚合结果，放数据库。最常见的做法是两套一起用：对象存储存正文，数据库存索引与指标，查询时先走索引拿到定位，再去取正文。

这里说的「选型」，指的是把原始回答正文与它的索引、聚合分别放在哪一类存储上，以及为此要付的查询代价与容量代价。选型的依据不是数据量大小，是查询形态。

这篇按查询形态讲：两种存储各自的代价结构、什么场景放哪边、组合方案怎么切、一段可跑的量级估算脚本，最后给五个检查与三个反问。文中条数、正文大小与倍率都是假设值，只用来演示估算方法。

一、两种存储的差别不在容量

很多人拿容量做对比：同样的数据，哪边便宜放哪边。我试过，按容量算出来的结论经常反过来。

数据库的成本主要跟着行数、索引数量和宽列走；对象存储的成本主要跟着对象数量和请求次数走，容量反而便宜。一个按行计费，一个按次计费，量纲不同，直接比单价没有意义。

所以我一般先不问哪个便宜，先问这批数据平时怎么被读。

二、按查询形态选

查询形态：更适合放 ｜ 原因
按轮整段取：回灌、归档、校验：对象存储 ｜ 一次前缀列举，顺序读，不碰索引
按问法、平台、时间多维筛选：数据库 ｜ 索引直接定位，不必扫全量
频繁 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 辅助生成内容，经人工核实。