mongodb - 键值存储是否适合需要 "get all"的用途？

Question

根据我所做的研究，我怀疑键值存储不是可行的方法，但我想获得更多定向输入:

1. 确定键值存储是否是适合我使用的可行解决方案。
2. 能够阐明我更喜欢文档存储的原因。

解释我的用例

我有一个包含许多“文档”的应用程序。这些目前存储在某种 CMIS 存储库中。然而，应用程序只会在这些文档被索引到 elasticsearch 之后才与这些文档进行交互。这意味着所有读取操作都会命中 elasticsearch，所有写入操作都会同时更新 elasticsearch 和存储库。

请求的功能表明当前存储库过于严格，并且在该级别强制执行模型模式的理由为零。当然，这导致了对 NoSQL 选项的调查。

为了将这些“文档”填充到 elasticsearch 索引中，它们需要存在于某个地方，我必须能够获取所有并在它们加载到索引中时对它们进行分页(还有一些在此步骤中发生的聚合，以填充基于现有字段构建的字段)。

现在，get all 实际上是根据文档类型分阶段完成的，但是这个要求可能是可以协商的，而不是简单的get all all types 可能就足够了，但并不理想。

在我对键值存储的理解中，存储对它存储的值一无所知，它们只能通过一个键来引用。这让我想知道当我不打算在任何地方维护完整的 key 列表时，我是否可以执行 get all。我已经看到一些键值存储支持使用字典作为键(redis)。我不确定这是否意味着我可以按类型查询(如果它是字典中的一个条目)或者我是否需要知道完整的字典才能获取值？

因为只有在 elasticsearch 失败时才需要填充索引，所以性能不是我的首要任务(但它肯定不会受到伤害)。对我来说，MongoDB 似乎是一个近乎完美的选择。我可以存储文档并按类型轻松查询。

• 根据我的用例，文档存储似乎是个不错的决定吗？
• 这是否也可以通过键值存储合理解决？
• 使用一个比另一个有什么其他优势吗？

以防万一，对于文档存储，我一直在比较 CouchDB、Couchbase 和 MongoDB。对于键值存储，我一直在关注 Redis 和 BerkeleyDB。

Answer 1

在 Redis 中，您可以通过一些工作和以下命令获取所有键和值:

• 扫描:获取所有 key
• TYPE:确定键的类型(字符串、散列、列表等)
• MGET/HGETALL/etc:获取实际值，具体取决于键所指的结构。

SCAN 命令也可以方便地实现以转储“redis-cli --scan”以及许多客户端库(例如 Python)中的所有内容。

您可能需要编写一些内容才能使其适用于您的特定场景，希望不会太困难。

注意:有一个 KEYS 命令(与 SCAN 的作用类似)不推荐用于现场制作。虽然没有什么能阻止您构建一个单独的独立从实例，从主实例复制，与主实例断开连接，然后按您的意愿使用从实例，而不会对任何服务于实时流量的任何东西产生任何影响。