.net 无模式数据缓存：NoSQL还是其他替代方案？

我正在评估一些NoSQL实现（目前是RavenDB和MongoDB），作为解决一组特定需求的方法，这些需求涉及到无模式数据的存储/检索。我想得到一些关于NoSQL是否是我应该关注的方向的反馈，或者是否有其他（可能更简单的）选项

本质上，我们有一个软件产品，它（除其他外）定义了一个基本的领域模型，该模型由几个相关实体组成，每个实体都有许多属性（键/值）。当我们向客户发布时，我们与他们一起设置属性和值，这基本上是系统的配置。这相当简单，因为设计是预先知道的，我们不需要任何动态来实现这一点并使其执行（我们将使用RDBMS）。属性是预先不知道的，但这也不是问题，因为系统的这一部分几乎围绕属性模型展开

问题是，对于不同的客户，在我们发布并投入生产后，我们发现需要查询特定的属性数据集，而在编译和发布代码时（以及为客户配置属性之前），我们对这些数据集一无所知。我们基本上需要从属性映射中生成数据，我们可以存储这些数据（我们不知道前面的结构），然后在以后以我们无法预料的方式查询存储的数据。现在的想法是，我们可以创建在处理过程中遇到的挂钩，并允许我们插入库（可能通过MEF）创建数据以便存储，然后在需要时查询（不用于报告——通常用于创建附加数据/属性）

（请注意，创建挂钩和插件库是一个单独的问题，并不打算成为此问题的一部分。）

一个常见的场景可能是：“我想知道xxx在过去10天内发生了多少次”。因此，我会创建一个插件来识别xxx已经发生，并将其写入带有日期/时间的数据存储区。然后我会创建另一个插件（可能在同一个DLL中）来执行查询，并向模型添加一个名为“CountOfxxxInLast10Days”的属性。   另一种情况可能是创建可配置的查找。因此，我可能有一个在启动时运行的插件来创建/更新查找数据表，该表可以将一个属性值转换为另一个属性值，或者（更可能）将一系列值转换为查找值。因此，转换插件可能会添加一个包含以下列的表：bottom_value，top_值、乘数和查询插件将使用属性值查询表，如“从表中选择乘数，其中[attribute_值]介于bottom_值和top_值之间”。结果可能会将结果添加到名为“乘数”的属性中

在某些情况下，可以在指定的时间段后清除旧数据。在上面描述的第一个场景中，可能需要从存储/缓存中删除超过十天的数据

在其他情况下，数据需要永久保存，如上面的第二个场景。这些数据可能只是在启动时重新创建，而不是保存在永久存储中

其他要求：

• 可以备份数据存储/缓存 并在联机时恢复
• 可以从中替换/恢复 发生崩溃时的最后一次备份
• 数据在像机器这样的事件中幸存下来 重新启动
• 经验证/生产测试的技术

---

在这一点上，我们非常支持.Net平台，因此任何选项都必须有一个可靠的.Net客户端/API。

有三种可能的选项，每种都有利弊

重用RDBMS 您已经将实体存储在关系数据库中。您可以将未定义的属性存储在一个额外的表中，该表有一个

键

和

值

列，以及一个引用属性所属实体的

EntityId

列。基本上，您将使用数据库的一部分作为键值存储

优点：

• 所有数据都存储在一个数据库中，这意味着：
  • 您可以在单个查询中检索实体及其所有属性
  • 您的应用程序不那么复杂，因为它只需要与单个数据库交互
• 您可以获得关系数据库的所有ACID优势

缺点：

• 关系数据库不是为了成为键值存储而构建的，因此可能存在性能问题。但是，我希望性能影响最小，除非您计划存储非常非常大量的属性

使用键值存储 键值存储（如and或更高级的）针对存储键值对进行了优化（毫不奇怪…）。您可以在RDBMS旁边使用键值存储，专用于存储属性，同时将实体保留在RDBMS中

优点：

• 比从RDBMS获得的性能更好，尤其是在数据量较大的情况下
• 更容易扩展，因为它们不受酸性质的限制

缺点：

• 没有保证的ACID属性，而是所谓的ACID属性，这意味着存储的数据在服务器之间可能并不总是一致的。然而，如果你正在扩展，你只需要处理这个问题。此外，大多数键值存储允许您调整其关于一致性的严格性，以帮助克服此问题
• 您的应用程序将在两个独立的数据库上运行，从而增加了应用程序的复杂性

使用文档数据库 您可以使用文档数据库仅存储属性。但您也可以冒险将所有内容存储在文档数据库中，包括您的实体

优点：

• 所有数据都存储在si中