Object storage is all you need
22 days ago
- Ampbase 使用 Tigris 对象存储（基于 FoundationDB 构建）作为其主要存储层，而不是传统的关系型数据库。
- 他们在对象存储原语之上实现了所需的数据库行为：强写后读一致性和条件写入（If-None-Match/If-Match）。
- 唯一性通过 If-None-Match:* 的条件写入来强制实现；冲突时需要重新读取存储的对象以确定结果。
- 无事务的变更使用乐观并发：读取 ETag，计算新状态，如果 ETag 匹配则写入，并以退避方式重试。变更函数必须是纯函数，以避免每次尝试产生副作用。
- 索引被设计进键名中，例如 members/{sha256(email)}.json，实现 O(1) 点查询——但仅限于预先预料到的查询。
- 历史记录和审计跟踪使用仅追加的 ULID 键，利用字典序进行按时间排序的范围扫描。由于没有 UPDATE 路径，记录不会丢失。
- 痛点包括重复读取和扇出导致的读放大、必须使用通读缓存、不支持连接/即席查询，以及状态更新与事件日志追加之间缺乏原子性。
- 跨区域的最终一致性可能会破坏条件写入：同一比较并交换操作在两个区域可能都成功，但其中一个更新会丢失。他们的解决方法是将对依赖的 RPC 重放到单个主区域，并让其他写入产生明显错误。
- 分析工作负载从 ClickHouse 采样演进为主机端归约：使用 DuckDB 读取小型、聚合、仅追加的文件，这也改善了租户隔离。
- 这种设计之所以有效，是因为写入量低且无争用，读取是点查询，数据按组织清晰分区，历史记录仅追加。如果多键事务或即席查询成为必需，这种设计就会被放弃。