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

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

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

问题在于,对于不同的客户,在我们发布并投入生产之后,我们发现我们需要查询特定的属性数据集,这些属性数据在编译和发布代码时(在我们配置属性之前)一无所知顾客).我们基本上需要从我们可以存储的属性映射中生成数据(我们不会预先知道结构),然后以我们无法预料的方式查询存储的数据.现在的想法是我们可以创建在处理期间受到影响的钩子,并允许我们插入库(可能通过MEF)创建数据以便存储,然后在需要时查询它(不用于报告 - 通常用于创建其他数据/属性).

(请注意,创建钩子和插件库是一个单独的问题,并不打算成为此问题的一部分.)

常见的情况可能是:"我想知道过去10天内xxx发生了多少次".所以我会创建一个能够识别xxx已经发生的插件,并将其写入带有日期/时间的数据存储.然后我将创建另一个执行查询的插件(可能在同一个DLL中),并向名为"CountOfxxxInLast10Days"的模型添加一个属性.另一种情况可能是创建可配置的查找.所以我可能有一个在启动时运行的插件来创建/更新可以将一个属性值转换为另一个属性值的查找数据表,或者(更可能)将转换为查找值的一系列值.因此转换插件可能会添加一个包含列的表:bottom_value,top_value,multiplier,查询插件将使用属性值查询表,如"

在某些情况下,旧数据可能会在指定的时间段后被清除.在上述第一种情况中,可能需要从超过十天的商店/缓存中删除数据.

在其他情况下,数据需要永久保留,如上面的第二种情况.这种数据可能只是在启动时重新创建,而不是在永久存储中保存.

其他要求:

可以在线备份和还原数据存储/缓存

在崩溃的情况下,可以从上次备份中替换/恢复

数据在机器重启等事件中幸存

经过验证/生产测试的技术

我们现在非常致力于.Net平台,因此任何选项都必须拥有可靠的.Net客户端/ API.

有三种可能的选择,每种都有利有弊.

重用RDBMS

您已经将实体存储在关系数据库中.您可以将未定义的属性存储在额外的表中,该表具有Key和Value列,以及EntityId引用属性所属的实体的列.基本上,您将使用数据库的一部分作为键值存储.

好处:

您的所有数据都存储在一个数据库中,这意味着:

您可以在单个查询中检索实体及其所有属性,

您的应用程序不那么复杂,因为它只需要与单个数据库进行交互.

您将获得关系数据库的所有ACID优势.

缺点:

关系数据库不是构建为键值存储,因此您可能会遇到性能问题.但是,除非您计划存储非常大量的属性,否则我希望性能最低.

使用键值存储

密钥值存储(例如Redis和Riak)或更高级的Apache Cassandra针对存储键值对进行了优化(这并不奇怪......).您可以使用RDBMS旁边的键值存储,专门用于存储属性,同时将实体保留在RDBMS中.

好处:

比从RDBMS获得的性能更好,特别是对于大量数据.

更容易扩展,因为它们不受ACID属性的约束.

缺点:

没有保证的ACID属性,而是所谓的最终一致性,这意味着存储的数据可能并不总是在服务器之间保持一致.但是,如果你要扩展,你只需处理这个问题.此外,大多数键值存储允许您调整其对一致性的严格性,以帮助克服此问题.

您的应用程序将在两个单独的数据库上运行,从而增加了应用程序的复

使用文档数据库

您可以使用文档数据库来存储属性.但您也可以采取措施,将所有内容存储在文档数据库中,包括您的实体.

好处:

您的所有数据都存储在一个数据库中,这意味着:

您可以在单个操作中检索实体及其所有属性,就像将整个实体(包括其属性)存储在单个文档中一样.

您的应用程序不那么复杂,因为它只需要与单个数据库进行交互.

更容易扩展,因为它们不受ACID属性的约束.

文档数据库不仅限于键值,因此如果您需要存储更复杂的属性,那么您已经很好了.

缺点:

没有ACID保证,就像键值存储一样.但是,可以调整大多数文档数据库以克服一致性问题.

不像RDBMS那样理解实体之间的关系.关系模型被规范化,而文档被非规范化,以克服具有许多关系.这可能是也可能不是一个很大的缺点,具体取决于您的确切域模型.

成熟的文档数据库技术

Apache CouchDB有很多使用它的应用程序,并从Stack Overflow社区获得积极的反馈.它有几个.NET驱动程序,但我不能告诉你这些驱动程序有多成熟.

MongoDB拥有相当令人印象深刻的生产就业清单..NET提供了三种主要驱动程序,它们似乎都具有良好的质量.

RavenDB对.NET的支持非常出色,因为它是为.NET平台设计的.但是,我无法找到在RavenDB上运行的大型生产环境的示例.不过,我认为这绝对值得探索.

我在生产环境中没有太多实际操作经验,所以我不知道他们在备份/恢复方面有多么容易.但鉴于这些NoSQL系统不像RDBMS系统那么严格,我想它们应该比RDBMS更容易备份/恢复而不需要停机.