我正在研究将.NET Web应用程序迁移到Azure的可行性。处理Web服务器方面的多角色设置似乎更有能力。
我对Azure数据库性能有所保留，并根据我们的需求采用了正确的横向扩展策略。我们使用包含120个表的单个数据库，80个交易在10个表上运行。其余部分用于各种帐户级别设置和全局引用。最大的表由500万行组成，并在其余9个大表中使用一组触发器进行操作，每个表依次保存在500k到250k行之间。
我最初的想法如下：
将最大的表移动到自己的数据库实例中，并使用SYNONYM引用它。我现在意识到Azure DB似乎不支持跨数据库实例的SYNONYMS。
使用联合来消耗更多Azure数据库实例的工作负载。我们的数据库只有5GB，所以这可能是一个不成熟的选择？
使用更高规格的虚拟机和SQL来为数据库提供服务。
我很欣赏这里有许多未知数，我不希望得到明确的答案，我只是想看看Stackoverflow社区可以提供什么样的体验。
其他信息
答案 0 :(得分：2)
您正试图一次解决两个问题，这可能不是最好的方法。首先，您迁移现有应用程序。其次，您正在尝试开发向外扩展架构。如果您尝试同时执行这两项操作，则会遇到架构问题。我建议您首先迁移应用程序，而不要过多关注扩展。运行应用程序后，您就可以开发更具可扩展性的架构。您会发现很少有具有可扩展性，SQL和低成本的解决方案 - 因此，您提出的任何“可扩展”解决方案都具有如此高的SQL依赖性，将会有一些痛苦的妥协。
为了构建更具可扩展性的东西，您将不得不仔细研究现有架构并进行大量的返工。将应用程序分解为单独的工作负载，放弃对T-SQL，触发器和复杂存储过程的高度依赖......以及其他一些事情。是否值得的需要/商业案例取决于您的应用程序路线图。
假设您有更长远的合理理由转移到Windows Azure（现有应用程序的便宜不是其中之一），那么您目前正着手实施迁移策略的第一步。我建议，为了这第一步，你尽可能少地改变，只是“让它工作”。在这种情况下，将SQL放在VM上可能是最有意义的 - 如果没有别的，只是为了给予更多的控制和余地。一切运行后（迁移的第1步），您可以查看迁移的更多阶段。步骤2到 n 意味着您的应用程序体系结构将发生显着变化，更多地使用表存储，而不是SQL。因此，通过步骤 n - m ，SQL的性能和/或可伸缩性不会成为问题。
云应用程序的数据模型更复杂，需要仔细考虑。这是我在CALM的数据模型中详细描述的内容。
不要恐慌。
如果您的应用程序有一个平凡的未来，那么co-lo托管解决方案可能是最好的 - 您可以专门配置满足您需求的数据库服务器。如果您对应用程序抱有很高的抱负，那么随着时间的推移，您可以将其迁移到在Azure上运行良好的可扩展性和云友好的体系结构。
答案 1 :(得分：0)
我选择＃3选项。 SQL Azure在性能方面可能有点......不可预测，尤其是在处理大量数据的性能敏感查询时
答案 2 :(得分：0)
VM选项将是您最简单的选择，尤其是如果您不想在应用中进行一些更改。
SQL联盟需要更改您的应用程序（USE FEDERATION）。
最重要的是，对于SQL Azure，您必须考虑瞬态故障处理/限制。此外，您必须验证您在SQL Server中使用的所有现有功能是否完全受支持（例如，部分支持TSQL，CLR支持等...）