我正在考虑将 .NET Web 应用程序迁移到 Azure 的可行性。处理 Web 服务器方面的多角色设置似乎非常有能力。
我对 Azure 数据库性能以及针对我们的需求采用正确的横向扩展策略持保留态度。我们使用由 120 个表组成的单个数据库，80% 的事务在 10 个表上运行。其余部分用于各种帐户级别设置和全局引用。最大的表由 500 万行组成，并使用其余 9 个大表上的一组触发器进行操作，每个大表又保存 50 万到 25 万行之间的任意位置。
我最初的想法如下:
将最大的表移动到它自己的数据库实例中，并使用 SYNONYM 引用它。我现在意识到 Azure DB 似乎不支持跨数据库实例的同义词。
使用联合来分散更多 Azure 数据库实例的工作负载。我们的数据库只有 5GB，所以也许这是一个不成熟的选择？
使用更高规范的虚拟机和 SQL 来为数据库提供服务。
我知道这里有很多未知因素，我不期望得到明确的答案，我只是想看看 Stackoverflow 社区可以提供什么体验。
其他信息
- 当前设置:单个 SQL Server 2008 R2 实例，具有包含 120 个表的单个数据库，运行在配备 12 GB RAM 的高规范多核服务器上。
- 当前的性能非常好，我们可以牺牲一些性能来换取可扩展性。
- 数据库每月以 10% 的速度增长，并且严重依赖关系数据、触发器和复杂的存储过程，因此很难使用 Azure 表作为替代方案。
最佳答案
您试图同时解决两个问题，这可能不是最好的方法。首先，您要迁移现有应用程序。其次，您正在尝试开发一个横向扩展架构。如果您尝试同时执行这两项操作，您将遇到架构问题。我建议您先迁移应用程序，不要太担心横向扩展。一旦应用程序运行，您就可以开发更具可扩展性的架构。您会发现很少有解决方案同时具有可扩展性、SQL 和低成本，因此您提出的任何高度依赖于 SQL 的“可扩展”解决方案都将面临一些痛苦的妥协。
为了构建更具可扩展性的东西，您必须仔细查看现有架构，并计划进行广泛的返工。将应用程序分解为单独的工作负载，放弃对 T-SQL、触发器和复杂存储过程...以及其他一些东西的高度依赖。这是否值得的需求/业务案例取决于您的应用程序路线图。
假设您有长期的充分理由迁移到 Windows Azure(现有应用程序便宜不是其中之一)，那么您当前正在着手迁移策略的第一步。我建议您在第一步中尽可能少地进行更改，只需“让它发挥作用”即可。在这种情况下，将 SQL 放在虚拟机上可能是最有意义的——如果没有别的办法，除了给予更多的控制和回旋余地之外。一切运行完毕后(迁移的第 1 步)，您可以查看迁移的其他阶段。步骤 2 到 n 意味着您的应用程序架构将发生巨大变化，更多地使用表存储，而更少地使用 SQL。因此，通过步骤n - m，SQL 的性能和/或可扩展性将不再是问题。
云应用程序的数据模型更加复杂，需要仔细考虑。这是我在CALM的数据模型中详细写过的内容。 .
不要 panic 。
如果您的应用程序有一个平凡的 future ，那么托管解决方案可能是最好的 - 您可以在其中专门配置满足您需求的数据库服务器。如果您对应用程序抱有很高的期望，那么随着时间的推移，您可以将其迁移到可扩展性更高且云友好且在 Azure 上运行良好的架构。
关于performance - Azure 数据库设计、数据表分区与联合？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15274020/