大型 Web 应用程序的数据库架构 [关闭]答案

【问题标题】：Database schema for large web apps [closed]大型 Web 应用程序的数据库架构 [关闭]
【发布时间】：2010-10-25 03:14:33
【问题描述】：

许多 SaaS Web 应用程序服务都有基于公司的概念。因此，每家使用该服务的公司都有自己的一组用户、文件和其他数据。 Web 应用程序通常如何在数据库端处理这个问题？他们是否为每个公司创建了一个新数据库（包含与该公司相关的数据表）？或者他们是否有某种 company_id 关系来从单个数据库中选择相关数据？

【问题讨论】：

标签： database-design web-applications saas

【解决方案1】：

肯定是 company_id。

为每个东西创建一个新表 - 更不用说一个新的数据库 - 将是荒谬的（而且确实是许多每日 WTF 帖子的素材）。

这就是使用关系数据库的全部意义 - 将事物链接在一起。

如果您需要使数据库更大，有很多方法可以做到（主/从、主/多从、双主、水平扩展、只需购买大量 RAM 等）。

FWIW：我的上一款应用拥有约 1200 万用户（每天约 30 万）；它有两个数据库（水平缩放；由以前的人完成。我不同意这个决定，并且会使用从属）。

编辑：警告 - 这是假设您仅通过您的应用程序（其 Web 界面或 API）公开访问权限。

如果您确实需要将数据库直接暴露给客户，a) 告诉他们三思而后行，因为这是一个坏主意，并且 b) 那么您可能需要在更易于维护的同时保留所需的防火墙之间做出艰难的选择。但是，srsly，如果你能帮上忙，你就不想去那里。

【讨论】：

不，我不打算直接公开数据库。我担心的只是长期的表现。是的，现在复制数据库看起来很愚蠢——模式的任何变化，备份都是可怕的。
这完全取决于我们谈论的每家公司有多少数据。在一般情况下，company_id 可能运行良好，但如果您是 Salesforce，则没有可以容纳您的主/从架构，无论如何您都需要水平扩展（尽管不是以每家公司 1 个 DB 的速度）。如果你是 Facebook，你可以为每所大学创建一个新的 MySQL 实例，这样你就可以从一开始就进行扩展，尽管它会带来跨数据库查询的麻烦。
其实我不确定 Salesforce。考虑到它的速度有多慢，它可能只是在一个巨大的 Oracle RAC 实例上运行，并在生成报告时试图烧毁每个人的数据:-)。
SquareCog - 当他谈到数十亿行时，是时候担心对设计做出重大牺牲以支持大规模。但他不是，而且很可能永远不会。 Facebook 很少。

【解决方案2】：

我最近发现在 SaaS 中，当应用程序和数据库在公司之间共享时，此类事物有一个名称：

Multitenancy

【讨论】：

【解决方案3】：

几个月前，我们在一个产品中遇到了这个问题，该产品经常被组织使用，而这些组织又为多个客户提供服务。他们来找我们，要求我们修改 SaaS 系统，以便他们可以为每个客户创建完整、独立的网站（我们构建了一个在线的、特定领域的网站构建工具）。

一个简短的总结：将每个人都放在一个数据库上似乎很明显，但是随着您的深入研究，您会发现它并不总是一成不变的。在进行过程中，您需要牢记一些挑战。几点：

首先，仅将“Company_id”添加到几个表是不够的。事实上，尽管 Sai 的 cmets 认为为每家公司拥有一个数据库/应用程序是荒谬的，但由于为多个离散客户托管 SaaS 系统的潜在复杂性，这绝对是有道理的。如果您只是服务几个不同的公司（例如为他们创建发票），那么 Sai 的评论是完全正确的。但是，如果您要向多个组织提供软件应用程序，那么复杂性会相当高，并且可能需要使用离散数据库。

其次，为多客户端数据库中更复杂的用户查询和报告工作做好准备。例如，在构建我们的用户查询功能时，我们必须绝对确定组织之间不会存在“渗透”，因为其中涉及受 HIPAA 保护的数据。这意味着查询和报告功能需要的工程水平远远超过以前的水平。在我们的案例中，我们的查询功能非常灵活，基本上允许用户动态构建查询（显然，受到一些非常严格的约束 - 我们不接受 SQL！）。因此，我们必须确保每个查询都被自动修改为使用“Company_ID”约束，无论数据的来源或提交查询的员工的权限如何。皱纹？我们的“超级用户”分析帐户必须能够在没有此类限制的情况下运行查询...

第三，您可能还没有预料到有多少东西需要分开。例如，我在站点中构建了一个非常复杂的“设置”对象，该对象在启动时从数据库中提取设置并将它们维护在“应用程序”对象（这是一个 .NET 应用程序）中。这一切都需要浮动以处理多个组织。

再举一个例子，过去对我们来说是唯一的字段（例如登录名）现在必须作为 Company_ID、LoginID 键的一部分来完成。如果您是从头开始构建，这不是一个大创意，但我们正在改造，所以它是。

无论如何，当我继续构建时，我惊讶地发现要完成这项工作需要做多少工作。

第四，我总是使用“元编程”方法构建软件。也就是说，我很少构建一个单一用途的页面，而是经常构建一个高度可定制的框架，以便于最终用户定制和内部代码重用。虽然我预计这将有助于过渡到多组织数据库，但它通常没有！因为这样的编码通常一开始就相当复杂，所以浮动组织通常比我只有一个普通网页更困难。

最后，如果没有迫切需要共享数据（例如分析整体使用模式），那么您可能只想坚持使用离散数据库以促进扩展。当您添加新的多组织数据库（第二个离散系统）时，我们的扩展通常涉及现有客户，这些客户突然经历了激增的增长。将它们从现有数据库中剥离并转移到新服务器上比仅仅移动到具有现有数据库的新服务器上要困难一些。

考虑到所有这些警告，您可能会认为我会建议您不要构建能够在单个数据库上处理多个组织的系统。然而，情况并非如此：采用多组织方法确实取得了一些成功！使用分析、跨组织报告、应用程序部署等都得到了显着增强。我只是想向您提供我们的经验，希望它能帮助您预测您可能预料到的一些困难。

【讨论】：

优秀的答案，希望我能投票几次。这是我开始挥舞我的水平扩展、无共享架构、AsterData、Greenplum、Vertica、Netezza 标志的部分。
大声笑 - 谢谢 SquareCog - 我很欣赏你的评论。
如果您提供的是一个应用程序，那么是的，这是另一回事——您所说的只是提供它们运行的代码，因此它们有自己的数据库.然而，让我们面对现实吧：他几乎不可能接近那个尺寸。当他到达那里时，他可以处理它。与此同时，尝试进行这种水平缩放只会让事情变得更加复杂。

【解决方案4】：

在将软件作为服务运行时，在选择数据库策略时始终需要考虑一些事项。每个客户端单独数据库的两个参数是备份和（感觉）安全性。如果您有一个带有谨慎 customer_id 字段的数据库，并且客户 666 搞砸了并希望恢复他昨天的数据，那么您需要做一些工作。

该客户有时也需要为每个客户提供一个数据库，因为数据可能很敏感。他可以理直气壮地争辩说，将数据放在不同的数据库中并设置良好的安全性会更节省。

-Edoode

【讨论】：