0

根据我所做的研究，我怀疑键值存储不是要走的路，但我想获得更多直接输入：

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

解释我的用例

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

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

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

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

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

由于索引的填充只需要在弹性搜索失败时发生，因此性能不是我的首要任务（但它肯定不会受到伤害）。对我来说，MongoDB 似乎是一个近乎完美的选择。我可以存储文档并轻松按类型查询。

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

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

4

2 回答 2

0

AFAIK，Redis 不允许使用字典作为键，除非通过外部键使用排序功能。对于您的用例，使用 Redis 意味着您要维护所有文档的列表，和/或按文档类型列出的列表。尽管这绝对是可能的，而且相当简单，但我并没有真正看到在那里使用 Redis 的任何兴趣。当您需要高性能时，Redis 会大放异彩。这不是您的要求，因此您最好使用文档数据库。

于 2015-02-12T13:35:01.610 回答
0

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

  • SCAN：获取所有密钥
  • TYPE：确定键的类型（字符串、哈希、列表等）
  • MGET/HGETALL/etc：获取实际值，具体取决于键所指的结构。

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

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

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

于 2015-02-12T21:30:49.643 回答