Mongodb 生产中具有动态数据模型的SaaS系统

我想设计一个产品，允许客户创建自己的网站。客户将能够动态维护其网站的数据模型，对其进行查询，并在html页面上显示输出。我怀疑传统的RDMBS是正确的选择，原因有二；对于每个客户，数据量都会增加，即使按比例扩展，RDBMS也可能达到极限。由于数据模型是高度动态的，因此执行许多DDL查询将降低整个系统的速度

我试图找出哪个数据库/数据存储系统可能是这样一个系统的最佳选择。最近，我读了很多NoSQL解决方案，如Cassandra和MongoDB，它在性能方面看起来很有希望，但有一个缺陷：它不是关系数据，所以数据必须非规范化

• 我不知道动态客户定义的数据模型的非规范化会产生什么影响，因为客户首先（以关系方式）建模和插入数据，然后再进行查询。非规范化必须自动进行，这会导致另一个问题：即使某些查询可能类似，我是否可以为每个查询创建一个表？一段时间后，可能存在高冗余数据
• 动态创建/更新表是否有任何影响
• 每次客户更改数据时，必须在包含同一实体副本的所有表中更改相同的数据（例如，必须在“团队成员”和“项目任务”中更改员工的姓名）。这些更新代价高昂吗
• 是否可以嵌套深度不受限制的数据，如

  {“team”：{“members”：[{“name”：“Ben”}}}

可能还有更好的/其他的方法，我很乐意得到任何提示

对要求进行澄清

实际上，我的问题是，如何使用像Cassandra这样的NoSQL数据库来维护关系数据，并且与RDBMS相比，该解决方案的性能还会更好吗？

无论使用什么DBMS，客户都认为是关系型的（因为事实上，我认为数据总是关系型的）。而且这项服务不是让客户选择底层数据存储。只能有一个

客户可以使用应用程序提供的管理前端定义自己的关系数据模型。客户可随时更改数据模型。在RDBMS中，生产系统上的DDL不是一个好主意。在数据模式的顶部，客户可以添加命名查询，并将其用作他创建的任何网页上的数据源

一个例子是对名为“News”的新闻的查询，在网页中使用它就像

[News.title]

，它将执行查询并遍历数据，并在每次迭代中重复

。这是最简单的例子

在更复杂的示例中，如果使用SQL，可能会大量使用执行错误的子查询。在NoSQL中，似乎可以选择首先使用查询所需的数据反规范化并准备一个表，然后只查询该表。对相关数据的任何更改都将导致该表的更新。这意味着对于客户创建的每个查询，系统将自动创建和维护一个表及其数据，因此会有大量的数据冗余。基准测试表明卡桑德拉的写作速度很快，所以这可能是一种选择。

让我把2美分放进去。 谈论拥有自己的数据模型的用户的能力不是SaaS
在纯SaaS范例中，每个用户都具有相同的功能和数据模型。他可以添加自己的对象，但不能添加对象类
因此，这种范式中的伸缩是一个相当明显的解决方案（尽管坦率地说，它可能不是那么简单）。您可以使用内置的多租户支持（例如Azure）获得云数据库，您可以使用亚马逊的RDS并随着用户数量的增长添加更多实例，如果数据库支持，您可以使用分片（例如，按用户划分的分区），等等。
但当我们谈论每个用户的自定义数据模型时，更像是IaaS（基础设施）。这是一些更低级的东西，你们只需说：“好吧，伙计们，你们可以建立任何你们想要的数据模型，随便什么”
我相信，如果您将创建数据模型的责任转移到用户身上，那么您也应该转移数据库选择的责任，正如IaaS所提供的那样。因此，用户会说：“好的，我需要这里的键值数据库”，然后你向他提供Cassandra的表，例如，如果他想要RDBMS，你也向他提供一个。 否则，你必须考虑的不是数据模型本身，而是你的客户需要的数据策略。所以一些客户可能需要键值存储（需要由一些NoSQL数据库支持），另一个可能需要RDBMS。你怎么知道？ 例如，从示例中考虑实体：<代码> {团队”：{“成员”：[ {“名称”：“Ben”}}} /代码>一个用户将使用该模型来进行单一类型的查询，例如“为团队获取成员”和“添加团队成员”。另一个用户可能需要频繁地查询一些统计信息。（团队成员的平均年龄、玩过的游戏）。
这两种情况可能需要不同的数据库类型：第一种是键值搜索，另一种是RDBMS。由于键值存储是围绕查询建模的，您如何猜测数据库类型和结构？
从技术上讲，您甚至可以根据用户的数据模型和查询来猜测数据库类型，但您需要为用户的创造力添加一些限制。否则，这将是一项非常不寻常的任务。
关于扩展，由于每个模型都是唯一的，随着用户的增长，您需要添加数据库实例。当然，您可以在不同模式的单个数据库实例中有多个用户，并且您需要确定每个实例的用户数量