dfb*_*dfb 5 language-agnostic mongodb key-value-store
我最近一直在阅读基于文档的数据库与键值存储(这里有一个很好的概述基于文档的数据库和基于键/值的数据库之间的差异？ ),我在以下方面找不到好的信息.
如果我们使用键(或附加索引)查询其中任何一个,那么机制中没有真正的区别 - 获取值.在查询非索引文档/字段时,我不清楚文档存储与键值存储的区别.如果我要在键值存储的顶部实现文档存储,我会在查询中执行"表扫描"(检查所有键/值对)以获取相应的值 - 文档存储执行的操作不止于此封面？以这种方式考虑文档数据存储是否合适？
这不是一个实际问题(如果我需要做一些有用的事情,我会使用Mongo而不是BDB),而不是一个旨在理解底层技术的问题.只有当它们适用于底层实现时,我才对特定系统的扩展方面感兴趣.
Edu*_*lar -3
对可扩展性的关注意味着您必须在设计时仔细考虑使用场景。对于可扩展的 NonSQL 部署，需要考虑多个变量，这些变量涵盖底层实现是基于键的还是面向文档的。这是一个简短的列表：
需要考虑的方面：
-写入与读取操作的频率
- 需要数据分析
- 数据冗余以实现高可用性
-数据复制/同步
-需要许多瞬态数据
-数据大小
-云就绪
一些 NonSQL 实现比其他实现更好地单独鼓励这些方面。
应用场景：
-经常写入、很少读取的数据，例如网络点击计数器或来自日志设备的数据：Redis | MongoDB
- 经常读取，很少写入/更新：用于瞬态数据缓存的Memcached 、 Cassandra | HBase用于搜索，Hadoop和Hive用于数据分析
- 需要最少停机时间的高可用性应用程序在集群、冗余数据存储方面表现出色：Riak | 卡桑德拉
- 多地数据同步：CouchDB
- 瞬态数据（网络会话和缓存）在瞬态键值数据存储中表现良好：Memcached
-由业务或网络分析产生的大数据可能不遵循任何明显的模式：Hadoop
结论：
恕我直言，您应该关注从使用场景开始选择可扩展数据存储的问题，而不是底层方面和它们之间的差异。
我还建议您检查Couchbase，它是两个世界的完美结合：基于密钥和面向文档。