具有参照完整性（删除级联）的 NoSQL / RDBMS 混合？

Question

是否有一个数据库可以为您提供参照完整性的好处并能够使用 SQL 类型语言进行查询，同时还允许根据其数据属性以及它们之间的关系来松散地定义实体？

例如采用具有权限、用户、用户组和角色的 RBAC 类型模型。复杂/灵活的模型可能具有以下规则：

• 角色可以拥有一个或多个权限，并且一个权限可以属于一个或多个角色
• 用户可以拥有一个或多个权限，并且一个权限可以属于一个或多个用户
• 用户组可以拥有一个或多个权限，并且一个权限可以属于一个或多个用户组
• 用户可以拥有一个或多个角色，并且一个角色可以属于一个或多个用户
• 用户组可以有一个或多个角色，一个角色可以属于一个或多个用户组
• 角色可以有一个或多个角色，一个角色可以属于一个或多个角色

在 RDBMS 中对上述内容进行建模将涉及创建大量交叉表。理想情况下，我想在数据库中定义的只是实体本身（用户、角色等）以及一些强制性属性。其他一切都将是动态的（即不需要 DDL），例如我可以创建一个具有未预定义的新属性的用户。我还可以在尚未预定义的实体之间创建关系，尽管数据库会像普通 RDBMS 一样处理参照完整性。

通过创建一个表来存储实体和另一个表来存储关系等，在 RDBMS 中可以在一定程度上实现上述目标，但这会使执行简单查询所需的 SQL 过于复杂，并且还可能影响性能。

Answer 1

一些 NoSQL 解决方案支持安全性和 SQL。其中之一是 OrientDB。安全系统（相当）解释得很好here。

还支持 SQL。

Answer 2

鉴于您在问题中指定的要求，图形数据库可能是您正在寻找的东西，但还有其他选择。正如@Niels van der Rest 所说，“无先验模式”和“参照完整性”这两个约束很难调和。您也许可以找到一个基于 Topic-Map 的数据库，但我不熟悉具体的实现，因此无法确定。

如果您决定真的不能没有参照完整性，我担心您可能会被 RDBMS 卡住。您可以使用一些技巧来避免您预期的一些问题，我在https://stackoverflow.com/questions/3395606... 中介绍了一些技巧，这可能会给您一些想法。尽管如此，对于这种需要动态、后先验模式和元模式元素的数据模型，RDBMS 总是很尴尬。

如果您愿意放弃参照完整性，那么您仍然需要考虑三种方法。

1. Map/Reduce - 有两种风格：面向分布式记录（想想，MongoDB）和面向列（想想，Cassandra）。规模真的很好，但你不会有类似 SQL 的语法；加入吸吮；并将您的架构与您的特定查询类型相匹配是至关重要的。在您的情况下，您关注实体及其属性，而不是实体本身之间的关系，所以我可能会考虑一个分布式的面向记录的存储；但前提是我预计需要扩展到单个节点之外——它们确实可以很好地扩展。

2. 文档存储 - 从技术上讲有两种风格，但其中一种是上面讨论的分布式面向记录的 map/reduce 数据存储。另一个是倒排索引（想想，Lucene/Solr）。不要忽视倒排索引的力量；他们可以以惊人的速度解决极其复杂的记录谓词。他们不能很好地处理包含相关或大型关系连接的查询。尽管如此，您仍会惊讶于记录谓词所提供的难以置信的灵活性和足够复杂的记录谓词。

3. 图形存储 - 有几种形式，第一个是大规模的临时键值存储（想想 DBM/TokyoTyrant）；第二个是元组空间（想想，Neo4j）；第三个是 RDF 数据库（想想 Sesame/Mulgara）。我对 RDF 情有独钟，帮助开发了 mulgara，所以我不是最客观的评论者。尽管如此，如果您的可伸缩性限制允许您使用 RDF 存储，我发现 RDF 的指称语义（在 noSQL 数据存储选项中很少见）所允许的推理非常宝贵。

Answer 3

您可能想查看MongoDB，它是一个基于文档的数据库，因此具有灵活的架构。太棒了，值得花时间看看它是否能满足您的需求。

Answer 4

Gremlin 语言支持 Neo4j 图形数据库。关于您的示例，请查看 Access control lists the graph database way 和 here。还有一个基于 Web 的工具，包括 Neo4j 的 REST API 和 Gremlin 控制台，请参阅 neo4j/webadmin。

Answer 5

大多数 NoSQL 数据库都可以很好地扩展。这是以一致性为代价的，其中引用完整性是其中的一部分。所以大多数 NoSQL 不支持任何类型的关系约束。

有一种类型的 NoSQL 数据库确实支持关系。事实上，它是专门为关系设计的：graph database。图数据库存储节点和这些节点之间的显式关系（边）。节点和边都可以包含键/值对形式的数据，而无需绑定到预定义的模式。

图数据库针对关系查询和漂亮的图操作进行了优化，例如查找两个节点之间的最短路径，或查找距当前节点给定距离内的所有节点。在角色/权限场景中您不需要此功能，但如果您需要，使用 RDBMS 将更难实现。

另一个选择是通过使用 RDBMS 来存储关系并使用文档数据库来存储实际数据，从而使您的整个数据层成为一个混合层。这会使您的应用程序稍微复杂化，但我认为这不是一个糟糕的解决方案。您将使用两种不同的技术，它们都处理它们旨在处理的问题。