具有弹性池的实体框架。如何管理我的 SaaS 客户端数据库？

Question

我目前正在寻找在 Azure Cloud 上托管的 ASP.Net 中构建 SaaS。 我正在寻找有关如何最好地构建我的数据库和与之配套的实体框架的建议。客户在 Web 应用上注册后，该应用需要在我的 Azure SQL 服务器上为每个客户创建一个单独的数据库。

我已经开始研究elastic pooling 的选项，但它让我很困惑。告诉你一些关于我的数据库的信息，它有一个用于所有常规设置的“元”数据库。然后每个客户都有一个包含他的投资组合的数据库。

例子

带有表格（货币、股票、债券）的数据库 [设置] [

[Customer1] SomeFinanceProduct [Currency as foreign, stock as foreign], SomeOtherFinanceProduct [Currency as foreign, bond 作为外币]

[Customer2] SomeFinanceProduct [Currency as foreign, stock as foreign], SomeOtherFinanceProduct [外币为外币，外币为债券]

[客户3]等

我会感谢更有经验的开发人员的帮助。非常感谢，这对我来说是一个重要的问题。我还发现了 2015 年的 this 帖子，他们说解决方案很快就会发布，但我在网上没有找到任何东西。

Answer 1

您需要一个弹性池，每个租户都有一个分片。

This link 描述了可用于在多租户场景中管理和查询分片数据库的工具。按照第一段中的链接了解每个链接的详细信息。

Answer 2

我不能过多地谈论您问题的实体框架部分，但是，我可以谈论弹性池方面的事情。

请务必注意，Azure 弹性池只是一种计费和资源分配结构。就您的应用程序或其代码而言，如果您使用弹性池，则没有区别。您仍然有一个数据库，它位于服务器上，并且该服务器（间接地，但更具体地在Azure 的情况下，该数据库）具有资源限制。

在 Azure 中，您通常会创建一个数据库并选择一个服务或定价层。您支付 X 美元以换取该数据库的 Y 资源（CPU、内存、存储大小、连接数等）。您对您创建的每个数据库重复此操作。随着时间的推移，数据库的大小或使用量会不断增长，它们的要求也会越来越高，因此您必须在发生这种情况时单独更改每个数据库的服务层。随着您拥有越来越多的数据库，这将变得乏味且成本​​低。

使用弹性池，您可以使用任意数量的单独数据库并放弃单独的服务/定价计划，而是购买大量资源 [即弹性池] 并将这些资源提供给所有数据库。理论是，使用这种方法总体而言您需要更少的资源，这可以让您节省资金。它还可以更好地利用您购买的资源。

您需要较少资源的原因是，通常数据库在不同时间经历高峰需求。当您单独购买资源时，您必须在每个数据库上过度购买以处理峰值（这意味着您有很多浪费的资源只是坐在那里未使用）。在弹性池上，由于所有数据库都在池中，因此您只需购买足够的额外资源，这些资源将涵盖您通常同时同时发生的许多峰值；现在您闲置浪费金钱的资源更少了。

正如我所提到的，使用弹性池的另一个好处是您可以更好地利用您拥有的资源。考虑一个对它的要求非常低的数据库；您自然会为此购买一个小型（因此便宜）的计划。然后考虑一个对它有很高要求的数据库；您可能会购买资源更多的计划。现在，偶尔使用率低的数据库会大受欢迎。使用小计划，资源不足，性能下降严重。同时，另一个数据库拥有大量资源，其中大部分资源都未被使用。如果正在经历异常高峰的小型数据库可以借用其中的一些资源几分钟，那不是很好吗？这正是弹性池的作用！弹性池为您的应用程序带来了许多内置的可扩展性优势！

最后要注意的是，弹性池的单位资源成本高于常规数据库。这意味着存在一个收支平衡点，并且使用弹性池的成本更高，直到您有足够的数据库使其值得。对于我的需要，我发现 10-15 个数据库是一个相当不错的收支平衡点。一旦你有足够的，创建池。然后，随着您稍后将更多数据库添加到池中，“每个数据库”的成本开始进一步下降。

--

所以回到您的问题，弹性池不会特别影响您在项目中使用实体框架的能力。无论您是否选择合并数据库，您都必须让您的代码根据登录者与适当的客户特定数据库进行对话。