Azure SQL 数据库与专用计算机上的 MS SQL 服务器
Azure SQL Database vs. MS SQL Server on Dedicated Machine
我目前是 运行 MS SQL Server 2014 (12.1.4100.1) 的一个实例，我以每月 270 美元的价格租用一台专用机器，规格如下：
- Intel Xeon E5-1660 处理器（六个 3.3ghz 物理内核 +
超线程 + turbo->3.9ghz)
- 64 GB 注册 DDR3 ECC 内存
- 240GB 英特尔固态硬盘
- 45000 GB 带宽 t运行sfer
我一直在玩弄 Azure SQL 数据库，并且一直在考虑切换到他们的平台。我在 V12 服务器上使用他们的 P2 Premium 定价层启动了一个 Azure SQL 数据库（只是为了测试），并加载了我现有数据库的副本（从专用机器）。
我 运行 并排查询几组，一组针对专用计算机上的数据库，另一组针对 P2 Azure SQL 数据库。结果有点令人震惊：我的专用机器每次都大大优于 Azure 数据库（在执行时间方面）。通常，专用数据库实例的完成时间不到 Azure 数据库执行时间的 1/2 到 1/3。
现在，我了解了 Azure 平台的诸多好处。与我在专用机器上的非托管设置相比，它是托管的，它们的时间点恢复比我拥有的更好，防火墙易于配置，有地理复制等等。但我有一个数据库数百个 table ，每个 table 中有数千万到数亿条记录，有时需要跨多个连接查询等，因此执行时间方面的性能非常重要。我只是觉得令人震惊的是，每月 930 美元的服务与每月 270 美元的专用机器租赁相比表现不佳。总的来说，我对 SQL 还是很陌生，对 servers/etc. 也很陌生，但是这对其他人来说不是吗？有没有人对我在这里遗漏的东西有一些了解，或者 Azure SQL 数据库的其他 "managed" 功能应该弥补价格差异？
底线是我什至开始超出我的专用机器的能力，我真的希望 Azure 的 SQL 数据库会是一个不错的下一个垫脚石，但除非我遗漏了什么， 不是。我的生意还太小，不能出去在其他平台上花几十万。
如果我遗漏了什么，或者我看到的性能是否符合您的预期，有人有什么建议吗？我是否有任何其他选项可以产生比我目前 运行 的专用机器更好的性能，但不要花费数十 thousand/month？我可以为我的 Azure SQL 数据库做些什么 (configuration/setting) 来缩短执行时间吗？再次感谢您的帮助。
编辑：让我修改我的问题，让它更清楚一点：我所看到的纯粹执行时间性能是可以预期的，其中专用服务器 @ 270 美元/月的性能远远超过微软的Azure SQL 数据库 P2 层 @ 930 美元/月？忽略其他 "perks"，如托管与非托管，忽略预期用途，如 Azure 用于生产等。我只需要知道我是否遗漏了 Azure SQL 数据库，或者我是否真的我应该从一台专用机器中获得更好的性能。
（免责声明：我在 Microsoft 工作，但不在 Azure 或 SQL 服务器上工作）。
"Azure SQL" 不等同于 "SQL Server" - 我个人希望我们确实提供了一种 "hosted SQL Server" 而不是 Azure SQL.
从表面上看，两者是相同的：它们都是关系数据库系统，具有 T-SQL 查询它们的能力（好吧，它们都在后台使用相同的 DBMS ).
Azure SQL 的不同之处在于 idea 是你有两个数据库：一个使用本地 SQL 服务器的开发数据库（最好是 2012 或稍后）和 Azure 上的生产数据库 SQL。您（不应该）永远不要直接修改 Azure SQL 数据库，实际上您会发现 SSMS 不为 Azure SQL 提供设计工具（Table Designer、View Designer 等）。相反，您设计和使用本地 SQL 服务器数据库并创建 "DACPAC" 文件（或特殊的 "change" XML 文件，可以由 SSDT 生成），然后修改您的Azure DB 以便它复制您的开发数据库，一种 "design replication" 系统。
否则，正如您所注意到的，Azure SQL 提供内置的弹性、备份、简化的管理等。
至于性能，您是否可能缺少索引或其他优化？与本地 SQL 服务器相比，您可能还会注意到 Azure SQL 的延迟略高，我发现 ping 时间（从 Azure VM 到 Azure SQL 主机）大约为 5-10 毫秒，这意味着您应该将应用程序设计得不那么繁琐或并行执行数据检索操作，以减少页面加载时间（假设这是您正在构建的网络应用程序）。
SQL 数据库内置了可用性（这会影响性能）、时间点恢复能力和灾难恢复功能。您可以选择根据您的使用情况扩大/缩小您的数据库以降低成本。您可以使用全局查询（分片数据）提高查询性能。 SQl 数据库管理自动升级和打补丁，大大提高了可管理性。您可能需要为此支付一点额外费用。应用程序级缓存/均匀分布负载、冷时降级等可能有助于提高数据库性能并优化成本。
Microsoft 有 Azure 的替代方案 SQL DB:
“在 Azure 中配置 SQL 服务器虚拟机”
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/
两种产品之间差异的详细解释：“了解 Azure SQL 数据库和 Azure VM 中的 SQL 服务器”
独立 SQL 服务器和 Azure SQL 数据库之间的一个显着区别是，使用 SQL 数据库，您需要为高可用性付费，这是通过 运行 不同机器上的多个实例。这就像租用 4 台专用机器并 运行 它们在一个 AlwaysOn 可用性组中，这会改变您的成本和性能。但是，正如您从未提到的可用性，我猜这在您的场景中不是问题。 SQL VM 中的服务器可能更符合您的需求。
除了性能和可用性之外，还有其他几个重要因素需要考虑：
- 总费用：270 美元的租金只是众多费用因素之一。 Space，电力和暖通空调是其他物理成本。然后是管理成本。想一想您必须在星期二以及 Windows 或 SQL 服务器发布服务包或累积更新时必须完成的每个补丁的工作。即使您在推出之前不对它们进行测试，它仍然需要时间和精力。如果您进行测试，则有第二台机器并复制产品实例和工作负载以进行测试。
- 安全性：有很多关于将您关心的任何数据存储在云中是多么糟糕、危险和冒险的文章。就个人而言，我看到本地服务器（甚至在银行和联邦机构）的安全实施和流程比我在任何主要云提供商（微软、亚马逊、Google）看到的都要糟糕。把事情做好需要做大量的工作，然后再做更多的工作来保持它们的正确。此外，您还可以查看和审核他们的安全 SLA（请参阅 http://azure.microsoft.com/en-us/support/trust-center/ 处的 Azure）。
- 可扩展性：不仅仅是原始的可扩展性，还有扩展的成本和工作量。 Azure SQL DB 最近发布了巨大的 P11 版本，它的计算能力是您测试过的 P2 的 7 倍。放大和缩小不是瞬间的，而是非常简单和相当快的。最好的部分是（无论如何对我来说），当我 运行 大型查询或重新索引操作然后再次退回以进行 "normal" 加载时，它可以升级到更高版本。这对于裸机上的常规 SQL 服务器来说很难做到——要么 rent/buy 一个 90% 的时间都处于空闲状态的大盒子，要么需要停机移动。如果在 VM 中稍微容易一些；可以在线增加内存，但仍然需要反弹实例来增加CPU；您的 Azure SQL 数据库在规模 up/down 操作期间保持在线。
我目前是 运行 MS SQL Server 2014 (12.1.4100.1) 的一个实例，我以每月 270 美元的价格租用一台专用机器，规格如下：
- Intel Xeon E5-1660 处理器（六个 3.3ghz 物理内核 + 超线程 + turbo->3.9ghz)
- 64 GB 注册 DDR3 ECC 内存
- 240GB 英特尔固态硬盘
- 45000 GB 带宽 t运行sfer
我一直在玩弄 Azure SQL 数据库，并且一直在考虑切换到他们的平台。我在 V12 服务器上使用他们的 P2 Premium 定价层启动了一个 Azure SQL 数据库（只是为了测试），并加载了我现有数据库的副本（从专用机器）。
我 运行 并排查询几组，一组针对专用计算机上的数据库，另一组针对 P2 Azure SQL 数据库。结果有点令人震惊：我的专用机器每次都大大优于 Azure 数据库（在执行时间方面）。通常，专用数据库实例的完成时间不到 Azure 数据库执行时间的 1/2 到 1/3。
现在，我了解了 Azure 平台的诸多好处。与我在专用机器上的非托管设置相比，它是托管的，它们的时间点恢复比我拥有的更好，防火墙易于配置，有地理复制等等。但我有一个数据库数百个 table ，每个 table 中有数千万到数亿条记录，有时需要跨多个连接查询等，因此执行时间方面的性能非常重要。我只是觉得令人震惊的是，每月 930 美元的服务与每月 270 美元的专用机器租赁相比表现不佳。总的来说，我对 SQL 还是很陌生，对 servers/etc. 也很陌生，但是这对其他人来说不是吗？有没有人对我在这里遗漏的东西有一些了解，或者 Azure SQL 数据库的其他 "managed" 功能应该弥补价格差异？
底线是我什至开始超出我的专用机器的能力，我真的希望 Azure 的 SQL 数据库会是一个不错的下一个垫脚石，但除非我遗漏了什么， 不是。我的生意还太小，不能出去在其他平台上花几十万。
如果我遗漏了什么，或者我看到的性能是否符合您的预期，有人有什么建议吗？我是否有任何其他选项可以产生比我目前 运行 的专用机器更好的性能，但不要花费数十 thousand/month？我可以为我的 Azure SQL 数据库做些什么 (configuration/setting) 来缩短执行时间吗？再次感谢您的帮助。
编辑：让我修改我的问题，让它更清楚一点：我所看到的纯粹执行时间性能是可以预期的，其中专用服务器 @ 270 美元/月的性能远远超过微软的Azure SQL 数据库 P2 层 @ 930 美元/月？忽略其他 "perks"，如托管与非托管，忽略预期用途，如 Azure 用于生产等。我只需要知道我是否遗漏了 Azure SQL 数据库，或者我是否真的我应该从一台专用机器中获得更好的性能。
（免责声明：我在 Microsoft 工作，但不在 Azure 或 SQL 服务器上工作）。
"Azure SQL" 不等同于 "SQL Server" - 我个人希望我们确实提供了一种 "hosted SQL Server" 而不是 Azure SQL.
从表面上看，两者是相同的：它们都是关系数据库系统，具有 T-SQL 查询它们的能力（好吧，它们都在后台使用相同的 DBMS ).
Azure SQL 的不同之处在于 idea 是你有两个数据库：一个使用本地 SQL 服务器的开发数据库（最好是 2012 或稍后）和 Azure 上的生产数据库 SQL。您（不应该）永远不要直接修改 Azure SQL 数据库，实际上您会发现 SSMS 不为 Azure SQL 提供设计工具（Table Designer、View Designer 等）。相反，您设计和使用本地 SQL 服务器数据库并创建 "DACPAC" 文件（或特殊的 "change" XML 文件，可以由 SSDT 生成），然后修改您的Azure DB 以便它复制您的开发数据库，一种 "design replication" 系统。
否则，正如您所注意到的，Azure SQL 提供内置的弹性、备份、简化的管理等。
至于性能，您是否可能缺少索引或其他优化？与本地 SQL 服务器相比，您可能还会注意到 Azure SQL 的延迟略高，我发现 ping 时间（从 Azure VM 到 Azure SQL 主机）大约为 5-10 毫秒，这意味着您应该将应用程序设计得不那么繁琐或并行执行数据检索操作，以减少页面加载时间（假设这是您正在构建的网络应用程序）。
SQL 数据库内置了可用性（这会影响性能）、时间点恢复能力和灾难恢复功能。您可以选择根据您的使用情况扩大/缩小您的数据库以降低成本。您可以使用全局查询（分片数据）提高查询性能。 SQl 数据库管理自动升级和打补丁，大大提高了可管理性。您可能需要为此支付一点额外费用。应用程序级缓存/均匀分布负载、冷时降级等可能有助于提高数据库性能并优化成本。
Microsoft 有 Azure 的替代方案 SQL DB:
“在 Azure 中配置 SQL 服务器虚拟机”
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/
两种产品之间差异的详细解释：“了解 Azure SQL 数据库和 Azure VM 中的 SQL 服务器”
独立 SQL 服务器和 Azure SQL 数据库之间的一个显着区别是，使用 SQL 数据库，您需要为高可用性付费，这是通过 运行 不同机器上的多个实例。这就像租用 4 台专用机器并 运行 它们在一个 AlwaysOn 可用性组中，这会改变您的成本和性能。但是，正如您从未提到的可用性，我猜这在您的场景中不是问题。 SQL VM 中的服务器可能更符合您的需求。
除了性能和可用性之外，还有其他几个重要因素需要考虑：
- 总费用：270 美元的租金只是众多费用因素之一。 Space，电力和暖通空调是其他物理成本。然后是管理成本。想一想您必须在星期二以及 Windows 或 SQL 服务器发布服务包或累积更新时必须完成的每个补丁的工作。即使您在推出之前不对它们进行测试，它仍然需要时间和精力。如果您进行测试，则有第二台机器并复制产品实例和工作负载以进行测试。
- 安全性：有很多关于将您关心的任何数据存储在云中是多么糟糕、危险和冒险的文章。就个人而言，我看到本地服务器（甚至在银行和联邦机构）的安全实施和流程比我在任何主要云提供商（微软、亚马逊、Google）看到的都要糟糕。把事情做好需要做大量的工作，然后再做更多的工作来保持它们的正确。此外，您还可以查看和审核他们的安全 SLA（请参阅 http://azure.microsoft.com/en-us/support/trust-center/ 处的 Azure）。
- 可扩展性：不仅仅是原始的可扩展性，还有扩展的成本和工作量。 Azure SQL DB 最近发布了巨大的 P11 版本，它的计算能力是您测试过的 P2 的 7 倍。放大和缩小不是瞬间的，而是非常简单和相当快的。最好的部分是（无论如何对我来说），当我 运行 大型查询或重新索引操作然后再次退回以进行 "normal" 加载时，它可以升级到更高版本。这对于裸机上的常规 SQL 服务器来说很难做到——要么 rent/buy 一个 90% 的时间都处于空闲状态的大盒子，要么需要停机移动。如果在 VM 中稍微容易一些；可以在线增加内存，但仍然需要反弹实例来增加CPU；您的 Azure SQL 数据库在规模 up/down 操作期间保持在线。