2

我正在研究将 .NET Web 应用程序迁移到 Azure 的可行性。处理 Web 服务器方面的多角色设置似乎功能强大。

我对 Azure 数据库性能和针对我们的需求采用正确的横向扩展策略持保留意见。我们使用由 120 个表组成的单个数据库，80% 的事务在 10 个表上运行。其余的用于各种帐户级别设置和全局参考。最大的表由 500 万行组成，并在其余 9 个大表上使用一组触发器进行操作，每个表又包含 500k 到 250k 行之间的任何位置。

我最初的想法如下：

  1. 将最大的表移动到它自己的数据库实例中并使用同义词引用它。我现在意识到 Azure DB 似乎不支持跨数据库实例的 SYNONYMS。

  2. 使用联合将工作负载分散到更多 Azure 数据库实例中。我们的数据库只有 5GB，所以也许这是一个不成熟的选择？

  3. 使用具有 SQL 的更高规格的虚拟机来为数据库提供服务。

我很感激这里有很多未知数，我不期待一个明确的答案，我只是想看看 Stackoverflow 社区可以提供什么体验。

附加信息

  • 当前设置：具有 120 个表的单个数据库的单个 SQL Server 2008 R2 实例在具有 12 GB RAM 的体面规格多核服务器上运行。
  • 当前的性能非常好，以至于我们可以用一些来换取可扩展性。
  • 数据库以每月 10% 的速度增长，并且严重依赖关系数据、触发器和复杂的存储过程，因此很难使用 Azure 表作为替代方案。
4

3 回答 3

2

您试图同时解决两个问题，这可能不是最好的方法。首先，您正在迁移现有应用程序。其次，您正在尝试开发横向扩展架构。如果您尝试同时执行这两项操作，您将遇到架构问题。我建议您先迁移应用程序，而不必过多担心横向扩展。一旦你的应用程序运行起来，你就可以开发一个更具可扩展性的架构。您会发现很少有同时具有可扩展性、SQL 和低成本的解决方案——因此，您提出的任何“可扩展”解决方案，对 SQL 的依赖程度如此之高，都会有一些痛苦的妥协。

为了构建更具可扩展性的东西，您将不得不仔细查看并计划对现有架构进行大量返工。将应用程序分解为单独的工作负载，放弃对 T-SQL、触发器和复杂存储过程的高度依赖……以及其他一些东西。这是否值得的需求/业务案例取决于您的应用程序路线图。

假设您有长期充分的理由迁移到 Windows Azure（现有应用程序不是其中之一），那么您目前正在着手迁移策略的第一步。我建议在第一步中你尽可能少地改变，只是“让它工作”。在这种情况下，将 SQL 放在 VM 上可能是最有意义的——如果没有别的办法，那就是给予更多的控制和回旋余地。一切运行后（迁移的第 1 步），您可以查看迁移的其他阶段。第 2 步到第 n步意味着您的应用程序架构将发生巨大变化，更多地使用表存储，而更少使用 SQL。因此，通过第n - m步，SQL 的性能和/或可扩展性将不会成为问题。

云应用的数据模型比较复杂，需要仔细考虑。这是我在CALM的数据模型中详细写过的内容。

不要恐慌。

如果您的应用程序有一个平凡的未来，那么 co-lo 托管解决方案可能是最好的——您可以在其中专门配置满足您需求的数据库服务器。如果您对自己的应用程序抱有很高的抱负，那么随着时间的推移，您可以将其迁移到在 Azure 上运行良好的可扩展性和云友好性更高的架构。

于 2013-03-07T20:12:38.713 回答
0

我会选择选项＃3。SQL Azure 的性能可能有点……不可预测，尤其是在处理对大量数据的性能敏感查询时

于 2013-03-07T15:07:45.033 回答
0

VM 选项将是您最简单的途径，特别是如果您不打算对您的应用程序进行一些更改。

SQL Federations 将需要更改您的应用程序（USE FEDERATION 事物）。

最重要的是，对于 SQL Azure，您必须考虑瞬时故障处理/限制。此外，您必须验证您在 SQL Server 中使用的所有现有功能是否完全受支持（例如，部分支持的 TSQL、CLR 支持等...）

于 2013-03-07T15:16:32.357 回答