技术问询：Amazon S3是object store还是key-value store？

我在Google检索相关问题时得到了相互矛盾的结论，特此发起技术问询：Amazon S3究竟是object store还是key-value store？
一方面，据我了解，上传至S3的对象为二进制对象数据（而非数据块），执行更新操作时会被完全覆盖写入；另一方面，用户可通过包含前缀与对象名的key、以及对应该对象本身的value来引用S3内存储的对象。

综上，S3具体属于哪类存储服务？是object store还是key-value store？

直接给结论：Amazon S3的官方产品定位是对象存储（Object Store），你看到的“键值存储”相关描述只是它最底层的接口抽象特征，二者不是非此即彼的互斥关系，但在云服务的通用分类语境下，从来不会把S3划到通用键值存储（Key-Value Store）的分类里。

核心逻辑拆成三点就很清楚：

• 别把抽象模型和产品分类搞混。键值存储本质是个非常宽泛的逻辑模型，只要满足「唯一Key映射对应Value」的访问逻辑，都能套进这个模型——按这个最宽松的标准，拿主键查单条记录的MySQL、靠文件名定位文件的本地文件系统，都能算KV，这种泛化的分类没有任何实际参考价值。S3确实是用桶名+对象键的唯一组合定位到对应的完整对象（包含二进制内容、系统元数据、用户自定义元数据），从接口抽象层符合广义KV的特征，这也是部分文档会提到它具备KV属性的原因。
• 行业日常讨论里说的键值存储，默认指的是Redis、DynamoDB这类为低延迟在线业务设计的服务，和S3的设计目标、能力边界有明确差异：这类通用KV服务单条Value大小普遍不高（大多是KB级，上限一般也就几百MB），支持小粒度随机读写、局部修改、原子操作，主打高QPS、毫秒甚至亚毫秒级访问延迟。而S3从设计之初就是面向海量非结构化数据的大容量持久存储，核心优先级是11个9的极高数据持久度、大容量、低成本：
  • 单对象最大支持5TB，不支持原地修改对象内的部分内容，哪怕只改1个字节，也得重新上传整个对象（靠分段上传拼接的方式本质还是生成全新的对象版本）
  • 所有核心功能都围绕对象存储场景设计：冷热数据分层自动转储、生命周期规则、跨区域/同区域复制、对象版本锁、大对象断点续传、预签名URL分享、前缀级权限控制、对象操作事件触发通知等，这些功能通用KV服务根本不会提供
  • 性能设计优先保障吞吐，多可用区冗余校验的架构决定了它的访问延迟远高于通用KV服务，不适合承载高频小数据的低延迟访问场景
• 不要用底层抽象否定上层产品分类。就像你不能因为本地文件系统也符合「文件名映射文件内容」的KV抽象，就把Ext4、NTFS叫做KV数据库一样，S3的接口形态虽然沾了广义KV的边，但从产品定位、能力边界、适用场景上判断，它就是标准的对象存储。

内容的提问来源于stack exchange，提问作者luminare