Azure Cosmos DB、Blob存储等临时存储选型：性能与成本对比分析
让我结合你的场景拆解下这几个方案的优劣，核心围绕你关心的性能和成本效益来分析：
1. 替换Blob为Cosmos DB：能提升性能吗？
答案是看你怎么用——如果能利用Cosmos DB的局部更新能力，性能会有明显提升，否则意义不大。
当前你用Blob的痛点是每次编辑都要全量拉取、反序列化、修改、再全量序列化存回，开销全在序列化/反序列化和全量IO上。而Cosmos DB原生支持JSON，你可以直接用它的API（比如SQL API的UPDATE语句）修改JSON里的特定字段，不用把整个payload拉下来。比如要改某个对象的属性，只需要发一个局部更新请求，省去了全量序列化的开销，尤其是当JSON payload很大时，这个性能提升会非常显著。
但成本上要注意：Cosmos DB按RU（请求单位）计费，局部更新的RU消耗很低，但如果还是像用Blob那样全量读写，RU成本会比Blob的存储+IO成本高不少。所以如果你的用户编辑以局部修改为主，Cosmos是性价比很高的选择；如果每次都是全量替换，那Blob可能还是更划算。
2. Azure SQL的JSON支持：是不是更可行？
Azure SQL对JSON的支持其实被很多人低估了，它完全可以作为你的草稿存储方案，甚至可能更贴合你的最终需求（因为你最终要把数据存入Azure SQL）。
你可以把JSON草稿存为NVARCHAR(MAX)类型，然后用SQL自带的JSON_MODIFY函数直接修改JSON里的特定字段，用JSON_VALUE验证字段值，甚至用OPENJSON把JSON展开成关系表做更复杂的校验。这样的好处是：
- 省去了中间存储（Blob/Cosmos）到SQL的迁移步骤，编辑完直接导入（其实就是把草稿表的数据同步到正式表）。
- 成本方面，如果你的草稿数据量不大，用SQL弹性池的话，成本会比Cosmos低很多；就算用单数据库，DTU/vCore的计费模式对于低频率的草稿编辑也很友好。
但它的局限性也很明显：如果你的JSON payload非常大（比如几十MB级别），SQL操作JSON的性能会下降，而且修改大JSON的开销也不小，这时候就不如Cosmos灵活了。
3. Redis缓存：适合你的场景吗？
Redis是内存级存储，速度极快，但它并不适合作为长期草稿存储——因为内存的成本比磁盘/对象存储高太多，而且如果草稿要存几天，Redis的持久化虽然能实现，但性价比很低。
不过Redis可以作为性能加速层来用：比如把用户正在编辑的草稿（比如最近1小时内活跃的）缓存到Redis里，减少对Blob/Cosmos/SQL的读写次数。用户编辑时直接操作Redis里的副本，编辑暂停超过一定时间再同步到持久化存储。这样既解决了实时编辑的性能问题，又控制了长期存储的成本。
核心决策总结（按成本效益排序）
- 如果编辑以全量替换为主：继续用Blob，同时优化代码层面的序列化（比如用
System.Text.Json替代Newtonsoft.Json，或者采用增量序列化），成本最低。 - 如果编辑以局部修改为主，且不需要关系型校验：选Cosmos DB，用局部更新API，性能提升明显，成本可控。
- 如果最终要存入Azure SQL，且需要关系型验证：直接用Azure SQL的JSON功能，省掉中间存储，成本和效率都不错。
- Redis只作为辅助加速：不要单独用它存长期草稿，配合上面的持久化方案使用。
内容的提问来源于stack exchange，提问作者gee'K'iran
