新的Azure SQL数据库服务看起来不错。然而，我正在努力弄清楚它们的可扩展性到底有多大。
因此，例如，假设一个200并发用户系统。
对于标准
Workgroup and cloud applications with "multiple" concurrent transactions
对于高级
Mission-critical, high transactional volume with "many" concurrent users
"多"one_answers"多"是什么意思？
此外，标准/S1提供15个DTU，而标准/S2提供50个DTU。这是什么意思？
回到我的200用户示例，我应该选择什么选项？
Azure SQL数据库链接
感谢
编辑
定义的有用页面
然而，什么是"最大会话"？这是并发连接的数量吗？
在Azure SQL数据库上有一些很棒的MSDN文章，特别是这篇文章为DTU提供了一个很好的起点。http://msdn.microsoft.com/en-us/library/azure/dn741336.aspx和http://channel9.msdn.com/Series/Windows-Azure-Storage-SQL-Database-Tutorials/Scott-Klein-Video-02
简而言之，这是一种了解为每个性能级别提供动力的资源的方法。在与Azure SQL数据库客户交谈时，我们知道的一件事是，他们是一个不同的群体。有些人对最绝对的细节、核心、内存、IOPS最满意，而另一些人则追求更概括的信息水平。不存在一刀切的问题。DTU是为后面的这一组设计的。
无论如何，云的好处之一是，从一个服务层和性能级别开始并迭代很容易。特别是在Azure SQL数据库中，您可以在应用程序启动时更改性能级别。在更改期间，数据库连接断开的时间通常不到一秒钟。我们服务中用于从服务层/性能级别移动数据库的内部工作流遵循与数据中心中用于故障转移节点的工作流相同的模式。而且，节点故障转移始终独立于服务层的更改而发生。换句话说，你不应该注意到这方面与你过去的经历有任何不同。
如果您不喜欢DTU，我们还有一个更详细的基准工作负载，可能会很有吸引力。http://msdn.microsoft.com/en-us/library/azure/dn741327.aspx
感谢Guy
不做测试真的很难判断。我假设你说的200个用户是指200个人同时坐在电脑前做事，而不是200个每天登录两次的用户。S2每秒允许49个事务，这听起来不错，但您需要进行测试。此外，进行大量缓存也不会有什么坏处。
查看今天Build发布的新Elastic DB产品（预览版）。定价页面已更新为弹性数据库价格信息。
DTU基于CPU、内存、读取和写入的混合度量。随着DTU的增加，性能级别提供的功率也会增加。Azure对并发连接、内存、IO和CPU使用率有不同的限制。选择哪一层真正取决于
- #并发用户
- 日志速率
- IO速率
- CPU使用率
- 数据库大小
例如，如果您正在设计一个系统，其中多个用户正在读取，而只有几个写入程序，并且如果您的应用程序中间层可以尽可能多地缓存数据，并且只有选择性查询/应用程序重新启动才能命中数据库，则您可能不太担心IO和CPU的使用情况。
如果许多用户同时访问数据库，则可能会达到并发连接限制，请求将被抑制。如果您可以在应用程序中控制进入数据库的用户请求，那么这应该不会成为问题。
日志速率：取决于数据更改的数量（包括系统中的额外数据泵送）。我看到应用程序稳定地泵送数据，而不是一次泵送数据。再次选择正确的DTU取决于如何在应用程序端进行节流并获得稳定的速率。
数据库大小：基本、标准和高级有不同的允许最大大小，这是另一个决定因素。使用表压缩类功能有助于减少总大小，从而减少总IO
内存：调整经验查询（联接、排序等），启用锁升级/nolock扫描有助于控制内存使用。
在数据库系统中，人们通常会犯的一个非常常见的错误是扩大数据库规模，而不是调整查询和应用程序逻辑。因此，测试、监视具有不同DTU限制的资源/查询是处理此问题的最佳方式。
如果选择了错误的DTU，不要担心，您总是可以在SQL DB中放大/缩小，并且它是完全在线的操作
此外，除非有充分的理由迁移到V12以获得更好的性能和功能。