对象存储自从 2006 年 aws 发布后，经过近 20 年的发展已经相当成熟，其具有优秀的可用性、可扩展性以及数据的可靠性，被视为云原生的存储基石。最近几年新兴数据库服务几乎都是围绕着对象存储服务进行设计，比如知名的 snowflake、Milvus、Turbo Puffer等，除此之外，大数据生态、机器学习生态也在逐渐往对象存储生态适配。
另一方面，Amazon Aurora的存算分离数据库发布后，市面上也出现了诸多追随者，比如Neon，阿里的PolarDB、字节的 veDB。其实数据库系统核心主要是三大组件：WAL(Write-Ahead Log)、索引和事务管理，这三者相辅相成保证了数据库ACID 语义。其中 WAL和索引都和存储相关，为了保证性能通常数据库都是写完 wal 即返回业务成功，索引则是更新内存或者后台异步更新，最终下刷到持久化存储，所以索引的存储很适合使用对象存储，不需要追加写的诉求。Aurora/PolarDB/VeDB都是自己构建了分布式的Page存储服务，wal也如此利用内部的append-only存储系统，neon则是利用对象存储服务存储Page数据，同时在对象存储前面构建了一层缓存，做到加速访问的效果，wal则是自己基于Paxos+Quorum协议构建了一套日志服务，叫 Safekeeper，这也是neon系统里最重要的一部分，如此原来neon其实是需要自己维护一套存储系统的，虽然可以做的足够简单，这其实对于云原生数据库服务而言也是一种负担。
笔者最近几年既参与了某大厂内部的存算分离数据库系统的构建，也参与了其底层分布式存储系统的构建，也有一些体验和观察。某大厂内部整个 infra 都采用分层架构构建，所有的存储服务（块、对象、文件以及各类数据库）都基于一套统一的分布式存储系统构建，该存储系统提供简单的文件（内部称为blob）语义，只支持Append-Only的语义，上层的存储服务通常也会采用WAL+LSM-Tree的方式构建。但是wal 使用单纯的 Append-Only语义也有一些困难，比如该系统提供的blob 并不适合无限大，也没有 trim 的语义，只支持单写，wal通常希望blob是无限长的数据流，并且能够支持选主保证单写。最近也常常思考，如果我们要从零快速构建一套存算分离的云原生数据库系统，在云上我们有哪些服务可以直接使用呢？
毫无疑问，存储数据的索引使用对象存储是不二选择，但是对于wal的存储我们需要一个什么样的服务呢？虽然也可以使用对象存储，比如写wal时先内存聚合，然后批量写入到对象存储，但是对于实时性以及可靠性要求高的数据库服务对象存储远远不够，要么就是像 neon一样自己开发一套log服务，数据先写多副本本地磁盘，然后后台上传到对象存储，即保证了性能和数据的可靠性，又降低了存储成本。换句话说，现在云上存储服务，对象存储并不是适合所有的场景，对象存储的协议并不能完全满足云原生存储的需求，目前能想到该协议对于下面的场景不适用：
- Append写。对象协议只支持put更新，整个文件整体覆盖，对于数据流存储场景不友好
- 低延迟。对象存储通常为了降低成本，后端采用 hdd 介质，虽然云厂商也开始提供基于 ssd的高性能对象存储服务，但是其整个链路的复杂性导致其延迟依然很高，并且短期成本不会降下来
- 不支持 Rename。部分场景系统依赖 rename的原子保证（不过没想清楚这个语义的必要性）
20 年之后我们重新看对象存储协议，尤其是云原生时代，是否还有更好的协议去替代或者填补对象存储不适合的场景呢？对于WAL场景，我们确实很需要一个append-only并且支持无限流的数据流语义的接口，如果能够提供选主语义则更加完美。实际上，各个内部大公司都有很多的尝试，比如 Facebook的 Delos，AWS内部也有很多系统都是基于一个支持分布式事务的Log服务，只是这些服务都没有作为云服务对外售卖，至于为什么没有对外售卖不得而知。最近，看到一个 startup推出了一个 stream store的serverless服务S2(Stream Store)，让我颇为兴奋，终于有公司愿意做这个方向了，不过在国内还没看到类似的开源产品或者商业化产品。如果这个产品市场验证成功，无疑对云原生数据库或者其他想要做云原生的infra系统而言又多了一把利器，基于流存储服务以及对象存储服务构建一套云原生数据库则会简单很多。
期待今年或者明年能看到infra存储领域有更多创新性的产品出现～