关注「索引目录」公众号，获取更多干货。
副标题：我为什么尝试将结构化数据存储在 Blob 中以及实际发生了什么
1. 钩子
大家都劝我不要把 Azure Blob 存储当作数据库来用。但我还是决定试一试。
我遇到一个用例，它并不需要搭建 SQL 或 Cosmos DB，只需要以低成本持久化一些结构化的、半静态的 JSON 数据，并允许全局访问。Blob 存储看起来太简单了，不容忽视。
所以我问自己：我能否让 Blob 存储像数据库一样运行？剧透一下：它在某种程度上奏效了。
2. 概念
基本思路如下：
-
每个记录都是一个数据块（例如，一个 JSON 文件）。 -
每个容器都是一个逻辑表。 -
blob 名称充当主键（例如 users/user-123.json）。 -
Blob 版本控制让你可以免费进行时间旅行或查看历史记录。
一个简单的 .NET 示例：
var blob = containerClient.GetBlobClient($"users/{userId}.json");
await blob.UploadAsync(BinaryData.FromObjectAsJson(user));你之后可以再读一遍：
var blob = containerClient.GetBlobClient($"users/{userId}.json");
var data = await blob.DownloadContentAsync();
var user = data.Value.Content.ToObjectFromJson<User>();没有模式，没有迁移，没有 SQL。只有数据块。
3. 好处（为什么它并非完全愚蠢）
- 价格低得离谱
：每 GB 仅需几分之一美分。 - 全球复制
：可与 CDN 集成。 - 模式灵活
：可存储任何 JSON 结构。 - 内置版本控制
：blob 版本控制类似于记录历史记录。 - 非常适合静态或很少变化的数据
：配置、静态数据集、日志或预先计算的 AI 输出。
实际应用案例：我将预渲染的仪表盘快照存储在 Blob 存储中，并通过 CDN 直接提供服务。加载速度极快，无需计算，也无需数据库调用。
4. 痛点（为什么这有点蠢）
- 没有查询引擎
：必须加载所有内容才能进行筛选或搜索。 - 不进行事务处理
或并发处理。 - 高延迟
：每次读写操作都是一次网络调用。 - 有限的原子操作
。 - 元数据扩展
：列出数据块数万个之后，速度会变慢，成本也会增加。
当数据量达到 5 万左右时，列表性能明显下降。最终，我添加了一个轻量级的 Redis 索引来跟踪数据块的键。
5. 混合技巧
接下来事情变得有趣起来了。
如果 Blob 存储不是数据库，而是一个单独的层呢？
例如：
App -> Redis index -> Blob for data payload -> CDN edge cache这种混合方法效果非常好：
-
Redis 存储键和元数据，以实现快速查找。 -
Blob 存储用于保存大型、不可变的有效负载。 -
CDN负责全球缓存。
现在，您拥有了快速、廉价且可靠的解决方案，而无需假装 Blob 存储是 SQL Server。
6. 判决
Blob 存储不会取代你的关系型数据库。它并非为动态查询、事务或实时更新而构建。
但作为冷存储层、仅追加日志或版本化配置存储库，它的表现却出奇地优雅。而且，当与内存索引或 CDN 缓存结合使用时，它的性能远超其自身规模。
Blob 存储并不笨，只是被误解了。
如果使用得当，它可以使您的架构更简单、更便宜、更具可扩展性。
7. 可选附加项目
如果你想进一步了解：
-
测试上传/下载速度，包括 .OpenReadAsync()并行上传。 -
使用 Azure Functions 自动索引 Blob 元数据。 -
探索 Blob 存储版本控制，实现不可变事件溯源。
最后想说的话
我不建议初创公司使用 Blob 构建核心数据库。但如果你拥有结构化、不经常更改且不需要查询的数据，那么这可能是Azure 中最被低估的技巧之一。
关注「索引目录」公众号，获取更多干货。