【问题标题】:How to convert a web app with indvidual DBs to a cloud with a single DB?如何将具有单个 DB 的 Web 应用程序转换为具有单个 DB 的云?
【发布时间】:2010-09-28 16:55:17
【问题描述】:

我制作了一个在 C# 上运行的电子商务应用程序。这个应用程序的每个实例现在都有自己的:

  1. IIS 7 应用程序池
  2. IIS 7 网站
  3. SQL Server 2008 数据库

我的合作伙伴告诉我,我们需要放弃这种方法并迁移到云端。 SQL Azure 似乎对每个数据库收费。因此,我们采用这种方法将非常昂贵。 有没有一种方法可以使用单个巨型数据库而无需重新编写整个数据访问层? *或者有没有便宜的方法来拥有数百个小型 SQL Azure 数据库?*

注意:每个数据库只有大约 20 MB

【问题讨论】:

  • 需要放弃这种方法并迁移到云端?为什么?
  • 哥们,你看过 ning.com 吗??? - 2年后,这是每个人都会期待的。在 30 秒内创建一个完整的 _________(用你做过的事情填空)......。
  • 老兄,这并没有清楚地解释您对基于云的系统的需求
  • FrustratedWithFormsDesigner - 先生,我想使用我的电子商务应用托管 10,000 个网站。

标签: azure cloud azure-sql-database


【解决方案1】:

是的,SQL Azure 会按数据库向您收费,但您真正支付的是数据库的大小。例如,一个 1GB 的数据库每月花费您 9.99 美元,一个 10GB 的数据库每月花费您 99.99 美元。 SQL Azure 中的数据库目前的最大大小也为 50GB。

基于此以及您对您的应用程序(可能有数百个 DB)所说的内容,并假设每个数据库将包含足够的数据以使支付 1GB 的 DB 是值得的,我会继续使用一个每个实例的数据库。

如果每个实例的数据实际上非常小,即使您有数百个实例也不会达到 50GB 的限制,那么您可以通过对数据进行分区并将其存储在一个数据库中来节省资金(但不是时间) .

如果成本是您最关心的问题,并且您正在考虑重写,我会考虑使用 Azure 表存储 (AZT),其中相同的 1GB 数据将花费您每月 0.15 美元来存储(但您必须付出处理一些小事情,比如外键和超过 1 个表的查询)

【讨论】:

  • 从成本角度来看 [Azure 表存储 (AZT)] 将是最好的。但是,它会导致重大的应用程序重写。
  • 还有一个来自 MS 的示例,它是关于多租户系统的。 fabrikamshipping.com
【解决方案2】:

如果每个数据库有 20MB,您将在一个 1GB 的 Azure 数据库中涵盖大约 50 个此类数据库。

使用新的数据库大小后,您的下一个大小为 5GB,并且您的帐单将根据给定一天使用的最大存储空间每天摊销。因此,对于低于 1GB 的时间,您将按 1GB 费率(每月 9.99 美元/每月天数)计费。一旦超过 1GB,您将转到 5GB 层(每月 49.95 美元/天)。这将比拥有 50 个 1GB 数据库的成本要低得多,后者将运行大约 1GB。每月 500 美元。

要合并您的数据库,您需要某种类型的客户 ID 或实例 ID,您必须将它们添加到您的表中,以提供跨租户的分区。

我看到 knightpfhor 提出的另一个关于迁移到表存储以节省成本的建议。虽然表存储比 SQL Azure 存储便宜,但这可能是一个重大的应用程序更改,因为表存储是非关系型的,没有存储过程或您通常从 SQL Server 获得的任何其他支持。添加分区/客户密钥比批量存储层重写侵入性要小得多。

【讨论】:

  • 这个(优秀的)答案中缺少的术语是多租户;这使得 OP 更容易通过 bingoogle 获取背景信息。多租户数据库在这种情况下是有意义的,但一般来说,多租户应用程序在云场景方面更有意义。
  • 我的应用程序允许用户上传 C# 代码。因此,每个站点都有自己的隔离数据库很重要。这样如果上传一些恶意的 SQL 代码只会影响他们自己的数据库。一个 azure db 会允许我这样做吗?我可以做一个子数据库吗?还是最终用户站点的连接字符串访问受限的架构?
  • 用户上传的代码是否在您的数据库上运行?用户是否能够对数据库进行更改?
  • 如果您让最终用户将代码上传到您的云托管应用程序,您可能会遇到比数据访问更大的问题。如果您决定让他们上传代码,则需要删除直接数据库访问(不要公开数据库连接字符串或凭据);相反,通过数据层路由所有数据访问,使用 WCF 之类的东西(无论如何,这通常是一个很好的做法)。有了这些,您就不必担心从错误的表/行中读取恶意代码。您仍然需要为每个用户提供某种类型的凭据,让您的数据层知道他们的客户 ID。
  • 请记住:最终用户代码可以简单地与 Azure 支持 DLL 链接。考虑恶意“运行时”代码而不是恶意“SQL”代码。考虑一下对 RoleEnvironment.RequestRecycle() 的随机调用,这会让您摸不着头脑,想知道为什么您的角色实例不断重启。或者可能是注册到 RoleEnvironment.Changing 的小事件处理程序,它提供恶意代码来执行与您的应用程序配置更改内联的操作?也许这太高级了:一个紧密的循环如何简单地以 100% 的 CPU 运行您的工作角色。
猜你喜欢
  • 2010-11-26
  • 1970-01-01
  • 1970-01-01
  • 2012-05-28
  • 1970-01-01
  • 1970-01-01
  • 2015-11-21
  • 2020-05-14
  • 2016-09-08
相关资源
最近更新 更多