.net - 无架构数据缓存:NoSQL或其他替代方案？

Question

我正在评估一些nosql实现（目前是ravendb和mongodb），作为解决涉及存储/检索无模式数据的特定需求集的一种方法。我想得到一些关于nosql是否是我应该关注的方向的反馈，或者是否还有其他（可能更简单的）选项。
本质上，我们有一个软件产品，它（除其他外）定义了一个基本的领域模型，这个模型由几个相关的实体组成，每个实体都有许多属性（键/值）。当我们发布给客户时，我们与他们一起设置属性和值，这本质上是系统的配置。这是相当简单的，因为设计是预先知道的，所以我们不需要任何动态的东西来实现这一点并使其执行（我们将使用RDBMS）。属性不是预先知道的，但是这不是一个问题，因为系统的这一部分基本上是围绕一个属性模型。
问题是，对于不同的客户，在我们发布并投入生产之后，我们发现我们需要查询在编译和发布代码时（以及在为客户配置属性之前）一无所知的特定属性数据集。d从属性映射生成数据，我们可以存储（我们不知道前面的结构），然后以我们无法预料的方式查询存储的数据。现在的想法是，我们可以创建钩子，在处理过程中被击中，并允许我们插入库（可能通过m它创建数据以便存储，然后在需要时查询（不用于报告——通常用于创建其他数据/属性）。
（请注意，创建钩子和插件库是一个单独的问题，不打算成为这个问题的一部分。）
一个常见的场景可能是：“我想知道xxx在过去的10天内发生了多少次”；“所以我会创建一个可以识别xxx已经发生的插件，并用日期/时间将其写入一个数据存储中。；“然后我会创建另一个插件（可能在同一个dll中），它将执行查询，并向模型添加一个名为“countofxxxinlast10days”的属性。
γ
另一种情况可能是创建可配置的查找。因此，我可能有一个在启动时运行的插件来创建/更新可以将一个属性值转换为另一个属性值的查找数据表，或者（更可能）将转换为查找值的值范围。因此转换插件可能会添加一个包含以下列的表：bottom_value、top_value、multiplier，查询插件会使用一个属性值来查询该表，比如“从表中选择multiplier，其中[attribute_value]位于bottom_value和top_value之间”。乘法器”。
在某些情况下，旧数据可以在指定的时间段后清除。在上面描述的第一个场景中，可能需要从存储/缓存中删除超过10天的数据。
在其他情况下，数据需要永久保存，就像上面的第二个场景一样。有可能这些数据只是在启动时重新创建，而不是保存在永久存储中。
附加要求：
可以备份数据存储/缓存
并在联机时恢复
可以从
发生故障时的最后一次备份
数据可以在诸如machine之类的事件中生存
重新启动
经验证/生产测试的技术
我们现在非常致力于.NET平台，因此任何选项都必须有一个可靠的.NET客户机/API。

Answer 1

有三种可能的选择，各有利弊。
重用rdbms
您已经将实体存储在关系数据库中。您可以将未定义的属性存储在一个额外的表中，该表有一个Key和Value列，以及一个EntityId列，该列引用属性所属的实体。基本上，您将使用数据库的一部分作为键值存储。
优势：
所有数据都存储在一个数据库中，这意味着：
您可以在单个查询中检索实体及其所有属性，
您的应用程序不那么复杂，因为它只需要与单个数据库交互。
您可以获得关系数据库的所有acid优势。
缺点：
关系数据库不是为关键值存储而构建的，因此您可能会遇到性能问题。但是，我希望性能影响最小，除非您计划存储非常大量的属性。
使用键值存储
键值存储（如Redis和Riak或更高级的Apache Cassandra）是为存储键值对而优化的（这并不奇怪…）。您可以在rdbms旁边使用一个键值存储，专用于存储属性，同时将实体保存在rdbms中。
优势：
比rdbms的性能更好，特别是对于大量数据。
更易于扩展，因为它们不受酸性物质的限制。
缺点：
没有保证的acid属性，而是所谓的eventual consistency，这意味着存储的数据在服务器之间可能并不总是一致的。不过，如果你要扩大规模，你只需要处理这个问题。此外，大多数关键值存储允许您调整其对一致性的严格性，以帮助解决此问题。
应用程序将在两个独立的数据库上运行，这会增加应用程序的复杂性。
使用文档数据库
您可以使用文档数据库仅存储属性。但您也可以冒险将所有内容存储在文档数据库中，包括实体。
优势：
所有数据都存储在一个数据库中，这意味着：
您可以在单个操作中检索实体及其所有属性，就像将整个实体（包括其属性）存储在单个文档中一样。
您的应用程序不那么复杂，因为它只需要与单个数据库交互。
更易于扩展，因为它们不受酸性物质的限制。
文档数据库不仅限于键值，所以如果您需要存储更复杂的属性，您已经可以使用了。
缺点：
没有acid保证，就像键值存储一样。不过，大多数文档数据库都可以调整以克服一致性问题。
不理解实体之间的关系，如在关系数据库管理系统中。关系模型是规范化的，而文档是非规范化的，以克服有许多关系。这可能是也可能不是一个很大的缺点，这取决于您的确切域模型。
成熟的文档数据库技术
Apache CouchDB使用它并从堆栈溢出社区接收quite a list of applications。它有一些positive feedback，但我不能告诉你这些司机有多成熟。
MongoDB有一个相当令人印象深刻的drivers for .NET。有三个主要的list of production employments可用，它们似乎都是drivers for .NET的。
RavenDB对.NET的支持非常好，因为它是为.NET平台设计的。但是，我还没有找到运行在ravendb上的大型生产环境的示例。不过，我认为这绝对值得一探究竟。
我对它们在生产环境中的任何一个都没有多少实际操作经验，所以我不知道它们到底有多容易备份/恢复。但是，考虑到这些nosql系统没有rdbms系统那么死板，我想它们应该比rdbms更容易在不停机的情况下进行备份/恢复。