Key-Value oriented数据库与Document oriented数据库差异及存储机制疑问

键值（Key-Value）数据库与文档（Document）数据库的存储、读取逻辑并不完全一致，二者从设计目标、能力边界到底层存储实现都有明显差异，因此被划分为两类不同的NoSQL数据库，具体差异如下：

1 读写逻辑的核心差异 #

键值数据库 #

• 采用纯key: value映射结构，value对数据库本身是不可感知的黑盒，无论value是字符串、二进制流还是序列化的对象，数据库都不会解析其内部内容。
• 读写仅支持基于完整key的精确匹配：你只能通过指定完整key查询对应的value，无法基于value内部的字段做过滤、索引、聚合操作。比如典型KV数据库Redis中，你存入key为user:1001的value是序列化后的JSON字符串，无法直接通过数据库查询该JSON中age > 18的属性，只能取回完整value后自行解析处理。

文档数据库 #

• 虽然基础结构也是key: 文档的映射，但文档（通常为JSON/BSON等半结构化格式）的内容对数据库是可感知的结构化数据，数据库会主动解析文档的字段、类型等信息。
• 除了通过key（通常为文档的_id字段）做精确查询外，还支持对文档内任意字段创建二级索引，实现条件过滤、嵌套查询、聚合运算甚至多文档关联查询。比如典型文档数据库MongoDB中，你可以直接编写查询语句筛选所有age > 18的用户文档，不需要将全量数据拉取到本地处理。

2 划分为不同类型的原因 #

二者的设计目标和适用场景完全不重叠：

• 键值数据库的设计优先保证极致读写性能，结构极简，单实例QPS可轻松达到十万甚至百万级别，适合缓存、会话存储、热点数据存取等仅需通过key快速读写的场景。
• 文档数据库的设计优先兼顾半结构化数据的查询灵活性和Schema自由度，比关系型数据库约束更少、扩展更灵活，比键值数据库查询能力更强，适合作为业务主库、内容管理系统、用户画像系统等需要灵活查询半结构化数据的场景。
  如果将二者归为同一类，会完全混淆选型边界，无法匹配不同的业务需求。

3 文件系统层面的存储实现差异 #

键值数据库（以RocksDB、Redis持久化文件为例） #

• 大多采用日志结构合并树（LSM Tree） 或哈希表+追加写日志的存储结构：数据按照key排序后分块存储，仅保留key与对应二进制value的映射关系，不会对value内部做额外的结构化解析和存储。比如Redis的RDB持久化文件就是全量键值对的二进制序列化转储，结构非常紧凑，几乎无多余元数据开销。
• 仅针对key构建全局索引，不存在针对value内部字段的索引结构，存储开销极低。

文档数据库（以MongoDB的WiredTiger存储引擎为例） #

• 底层虽然也可采用LSM Tree或B树存储文档数据，但除了_id与文档的映射外，还会额外存储文档的字段元数据，支持对文档内字段创建独立的二级索引，这些二级索引会单独占用存储空间。
• 存储文档时会保留完整的结构化信息，比如BSON格式会存储每个字段的类型、长度，方便数据库直接解析查询，无需用户自行反序列化处理。
• 部分实现会对高频查询的字段做预存储或缓存优化，会产生额外的存储开销，同等数据量下存储空间占用通常高于键值数据库。

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