Azure SQL数据库与专用计算机上的MS SQL Server

Dan*_*rke 28 sql azure sql-server-2014 azure-sql-database

我目前正在一台专用机器上运行MS SQL Server 2014(12.1.4100.1)的实例,我租的价格为270美元/月,具体如下:

  • Intel Xeon E5-1660处理器(六个物理3.3ghz内核+超线程+ turbo-> 3.9ghz)
  • 64 GB注册DDR3 ECC内存
  • 240GB英特尔SSD
  • 45000 GB的带宽传输

我现在已经开始使用Azure SQL数据库了,并且一直在尝试切换到他们的平台.我在V12服务器上使用他们的P2 Premium定价层启动了一个Azure SQL数据库(只是为了测试),并加载了我现有数据库的副本(来自专用机器).

我并排运行了几组查询,一组针对专用计算机上的数据库,另一组针对P2 Azure SQL数据库.结果令人震惊:我的专用机器每次都以极大的优势超越(在执行时间方面)Azure数据库.通常,专用数据库实例将在Azure数据库执行的时间的1/2到1/3之内完成.

现在,我了解Azure平台的许多好处.它是在专用机器上管理我的非托管设置,它们具有比我更好的时间点恢复,防火墙易于配置,有地理复制等等.但我有一个数据库数百个表在每个表中有数十到数亿个记录,有时需要跨多个连接查询等,因此在执行时间方面的性能确实很重要.我发现令人震惊的是,每月930美元的服务在每月270美元的专用机器租赁旁边表现不佳.我对SQL整体上还是一个新手,对于服务器/等等都是新手,但这不会对其他人产生影响吗?有没有人对我在这里缺少的东西有所了解,或者是那些其他的"管理"

最重要的是,我已经开始超越我的专用机器的能力了,我真的希望Azure的SQL数据库是一个不错的,下一个踩踏石头,但除非我遗漏了什么,否则它不是.我是一个太小的企业仍然出去在其他平台上花费数十万.

任何人都有任何建议,如果我错过了什么,或者我看到的表现符合你的期望?我还有其他任何可以产生比我目前运行的专用机器更好的性能的选项,但不要花费数万/月?我可以为Azure SQL数据库做些什么(配置/设置),这会增加执行时间吗?再次,任何帮助表示赞赏.

编辑:让我修改一下我的问题,或许让它更清晰一点:就我所看到的纯粹执行时间性能而言,我所看到的是,专用服务器@ 270美元/月的表现远远优于微软的Azure SQL DB P2层@ $ 930 /月?忽略托管与非托管之类的其他"特权",忽略Azure等用于生产等的预期用途.我只需要知道我是否遗漏了Azure SQL DB的内容,或者我是否真的应该更好单个专用机器的性能.

Dai*_*Dai 15

(免责声明:我为Microsoft工作,但不在Azure或SQL Server上工作).

"Azure SQL"并不等同于"SQL Server" - 我个人希望我们提供一种"托管SQL Server"而不是Azure SQL.

从表面上看,两者是相同的:它们都是具有T-SQL功能的关系数据库系统来查询它们(嗯,它们都是在引擎盖下使用相同的DBMS).

SQL Azure的是,不同的想法是,你有两个数据库:使用本地SQL Server(最好2012或更高版本)和在Azure上的SQL生产数据库开发数据库.您(应该)永远不会直接修改Azure SQL数据库,实际上您会发现SSMS不为Azure SQL提供设计工具(表设计器,视图设计器等).相反,您设计并使用本地SQL Server数据库并创建"DACPAC"文件(或可以由SSDT生成的特殊"更改"XML文件),然后修改您的Azure数据库,以便复制您的开发数据库,​​一种"设计复制"系统.

否则,正如您所注意到的,Azure SQL提供了内置的弹性,备份,简化的管理等.

至于性能,您是否可能缺少索引或其他优化?与本地SQL Server相比,您可能会注意到Azure SQL的延迟略高,我看到ping时间(从Azure VM到Azure SQL主机)大约5-10ms,这意味着您应该将应用程序设计为更少 - 繁琐或并行化数据检索操作,以减少页面加载时间(假设这是您正在构建的Web应用程序).

  • @DavidAtkinson UI事情对我来说是主要问题 - 在对象资源管理器中右键单击表后,每次出现上下文菜单需要2-3秒,而在本地或LAN服务器上它几乎是即时的.SMSS中有许多区域,其中UI线程阻止网络活动.在处理不同大洲的数据中心中的Azure实例时,将疼痛级别乘以. (2认同)

小智 15

除了Perf和可用性之外,还有其他几个重要因素需要考虑:

  • 总费用:270美元的租金只是众多成本因素中的一个.空间,电力和hvac是其他物理成本.然后是管理成本.想想你必须在星期二和Windows或SQL Server发布服务包或累积更新时执行每个补丁的工作.即使您在推出之前没有测试它们,仍然需要时间和精力.如果您进行测试,则会有第二台计算机并复制产品实例和工作负载以进行测试.
  • 安全性:有很多关于在云中存储您关心的数据有多么糟糕,危险和危险的文章.就我个人而言,我已经看到了与本地服务器(甚至在银行和联邦机构)的安全性更差的实施和流程,而不是我见过的任何主要云提供商(微软,亚马逊,谷歌).这是很多工作,把事情做对,然后更多的工作让他们保持正确.此外,您还可以查看和审核其安全SLA(请参阅http://azure.microsoft.com/en-us/support/trust-center/上的 Azure ).
  • 可扩展性:不仅仅是原始可扩展性,还包括扩展的成本和工作量.Azure SQL DB最近发布了庞大的P11版本,其测试容量是您测试的P2的7倍.向上和向下缩放不是即时的,但非常简单且相当快.最好的部分是(对我来说无论如何),当我运行大型查询或重新索引操作然后再次返回"正常"加载时,它可以碰到更高版本.对于裸机上的常规SQL Server来说,这很难做到 - 租用/购买一个非常大的盒子,它可以在90%的时间内闲置,或者需要停机才能移动.如果在VM中稍微容易一些; 你可以在线增加内存,但仍然需要反弹实例以增加CPU; 您的Azure SQL DB在扩展/缩小操作期间保持在线状态.


Jac*_*ins 11

从Microsoft到Azure SQL DB还有另一种选择:

"在Azure中配置SQL Server虚拟机"

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/

详细解释两种产品之间的差异:"了解Azure VM中的Azure SQL数据库和SQL Server"

https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/

您的独立SQL Server和Azure SQL DB之间的一个显着区别是,使用SQL DB,您需要为高级别的可用性付费,这可以通过在不同计算机上运行多个实例来实现.这就像租用4台专用机器并在AlwaysOn可用性组中运行它们,这将改变您的成本和性能.但是,由于您从未提及过可用性,我猜这不是您方案中的问题.VM中的SQL Server可以更好地满足您的需求.