我最近一直在阅读有关基于文档的数据库与键值存储的内容（这是一个很好的概述基于文档和基于键/值的数据库之间的区别？ ），但我在以下方面找不到好的信息.
如果我们使用键（或附加索引）查询其中任何一个，则机制没有真正的区别 - 获取值。在查询非索引文档/字段时，我不清楚文档存储与键值存储有何不同。如果我要在键值存储之上实现文档存储，我会为查询中的适当值执行“表扫描”（检查所有键/值对） - 文档存储是否比这更多封面？以这种方式考虑文档数据存储是否合适？
这不是一个实际问题（如果我需要做一些有用的事情，我是否会在 BDB 上使用 Mongo），而不是一个旨在理解底层技术的问题。只有当它们适用于底层实现时，我才对特定系统的扩展方面感兴趣。
它们都使用 BTree 和哈希索引来加速某些查询。键值存储基本上只是简单地访问取决于引擎的键，它可能被视为单个值（允许选择和范围查询）或复合值。
基于文档的引擎增加了对文档中元素路径的支持（或者他们在概念上称之为的任何东西）。基本上，您可以通过从键值创建文档 {key, value} 来模拟键值存储。如果您仅使用键结构查询文档，则在查找方面基本上具有相同的结果和类似的优化。
要查找有关 mongoDB 内部的信息，您可以使用他们的站点并搜索内部（https://www.mongodb.com/search?search=internals）。可以查到很多资料。
对可扩展性的兴趣意味着您必须仔细考虑设计中的使用场景。对于可扩展的 NonSQL 部署，需要考虑多个变量，该部署跨越底层实现是基于键的还是面向文档的。这是一个简短的列表：
需要考虑的方面：
- 写入与读取操作的频率
- 需要数据分析
- 高可用性的数据冗余
-数据复制/同步
- 需要许多瞬态数据
-数据大小
-云就绪
一些 NonSQL 实现比其他实现更好地鼓励这些方面。
场景：
- 频繁写入、很少读取的数据，如网络点击计数器或来自日志设备的数据：Redis | MongoDB
- 经常阅读，很少写入/更新：用于临时数据缓存的Memcached ， Cassandra | HBase用于搜索，Hadoop和Hive用于数据分析
- 需要最少停机时间的高可用性应用程序在集群冗余数据存储方面表现出色：Riak | 卡桑德拉
- 跨多个位置的数据同步：CouchDB
- 瞬态数据（Web 会话和缓存）在瞬态键值数据存储中表现良好：Memcached
- 来自可能不遵循任何明显模式的业务或 Web 分析的大数据：Hadoop
结论：
恕我直言，您应该关注从使用场景而不是底层方面和它们之间的差异开始选择可扩展数据存储的问题。
我还建议您检查Couchbase，它是两个世界的完美结合：基于键的和面向文档的。