2014-08-28 104 views
3

新的Azure SQL数据库服务看起来不错。不过,我正在努力研究它们的可扩展性。新的Azure SQL数据库服务,如何扩展和DTU是什么

因此,例如,假设200个并发用户系统。

对于标准

Workgroup and cloud applications with "multiple" concurrent transactions 

对于高级

Mission-critical, high transactional volume with "many" concurrent users 

什么是 “多” 与 “多” 的意思吗?

另外Standard/S1提供15个DTU,而Standard/S2提供50个DTU。这是什么意思?

回到我的200用户示例,我应该选择什么选项?

Azure SQL Database Link

感谢

编辑

Useful page on definitions

然而什么是 “最大会话数”?这是并发连接的数量吗?

回答

2

如果不做测试就很难说。对于200位用户,我假设你的意思是200人同时坐在电脑前做事,而不是200人每天登录两次。 S2允许每秒发生49次交易,这听起来正确,但您需要测试。也做了很多缓存不能伤害。

+0

谢谢你。是的,我的意思是,我同意测试。我使用JMeter。 “Max Sessions”是什么意思?它看起来像连接的数量,无论如何,越多你付出越多。只是想知道这是否与并发有关。 – SamJolly 2014-08-29 00:59:46

+0

我认为最大会话对应于最大连接数。考虑到你通常使用连接池,所以它不符合用户。 – Craig 2014-08-29 01:03:44

+0

我想知道当前使用的Web SQL数据库产品的“Max Sessions”是什么。是的,连接池将被使用,默认情况下,我猜是在EF/MSSQL设置中。所以如果“最大会话”数字很低,那么查询会排队很多。他们可以超时和失败吗? – SamJolly 2014-08-29 12:53:27

4

在Azure SQL数据库中有一些很棒的MSDN文章,特别是这对于DTU有一个很好的起点。 http://msdn.microsoft.com/en-us/library/azure/dn741336.aspxhttp://channel9.msdn.com/Series/Windows-Azure-Storage-SQL-Database-Tutorials/Scott-Klein-Video-02

简而言之,它是了解支持每个性能级别的资源的一种方式。我们在与Azure SQL数据库客户交谈时知道的一件事是,他们是一个多元化的组织。有些人对最绝对的细节,内核,内存和IOPS感到满意 - 而其他人则更多地总结了信息的概要。没有一种适合所有人的方式。 DTU适用于此后组。

无论如何,云的好处之一就是从一个服务层和性能级别开始,并且可以轻松地迭代。在Azure SQL数据库中,您可以在应用程序启动时更改性能级别。在更改过程中,当DB连接断开时,通常会少于一秒的时间。我们服务中用于从服务层/性能级别移动数据库的内部工作流遵循与数据中心内节点故障转移工作流相同的模式。节点故障转移始终独立于服务层更改发生。换句话说,相对于过去的经验,你不应该注意到这方面的任何不同。

如果DTU不是您的事情,我们也有更详细的基准工作负载,可能会有吸引力。 http://msdn.microsoft.com/en-us/library/azure/dn741327.aspx

感谢盖伊

+0

Guy,真的很感谢你的反馈。我们目前收到的问题之一是查询性能非常不稳定。我们目前使用SQL数据库Web,而且我们的用户群并不大,而且数据库是新的,MB大小。我已经看到会员服务GetUser SP从1秒到4秒不等(由NewRelic在SQL层上测量)。我有点怀疑我可能在数据库中遭受某种形式的争用,因此这种变化是可变的。因此,我希望新标准S1的性能更高。 – SamJolly 2014-09-03 01:26:34

+1

只看了你最后一个链接。有用的,但我不确定为什么使用不同的吞吐量单位,即交易/小时,交易/分钟和交易/秒。为什么不用相同的单位即事务/秒来表达它呢?指定当前的SQL数据库Web和业务实例也是最有趣的。人们希望看到SQL数据库Web的大幅增长。再次感谢 – SamJolly 2014-09-03 01:34:07

0

DTU基于CPU,内存,读取和写入的混合度量。随着DTU的增加,性能水平提供的功率也会增加。 Azure对并发连接,内存,IO和CPU使用率有不同的限制。哪一级有所回暖实际上取决于

  1. #concurrent用户
  2. 登录速度
  3. IO速度
  4. CPU使用率
  5. 数据库大小

例如,如果你是设计一个系统,其中多个用户正在阅读,并且只有少数作家,并且如果您的应用程序中间层可以尽可能缓存数据,并且只有sele ctive查询/应用程序重新启动命中数据库,然后您可能不必太担心IO和CPU使用情况。

如果许多用户在同一时间点击数据库,您可能会遇到并发连接限制,并且请求将受到限制。如果您可以控制用户请求到达您的应用程序中的数据库,那么这应该不成问题。

登录率:取决于数据更改的数量(包括系统中的其他数据泵送)。我已经看到应用程序稳定地抽取数据和数据一次抽完。再次选择正确的DTU取决于如何在应用程序端进行限制并获得稳定的速率。

数据库大小:Basic,standard和premium具有不同的允许的最大大小,这是另一个决定性因素。使用表格压缩功能有助于减小总大小,从而减少总IO。内存:调整exsnive查询(连接,排序等),启用锁定升级/ nolock扫描有助于控制内存使用情况。

人们通常在数据库系统中犯的常见错误是扩大其数据库,而不是调整查询和应用程序逻辑。因此,测试,监控具有不同DTU限制的资源/查询是处理此问题的最佳方法。

如果选择了错误的DTU,不用担心,你总能扩展在SQL DB /下和它是完全在线操作

而且,除非一个强有力的理由迁移到V12以获得更好的性能和特征。