SQL Azure - 如何测量当前工作负载以估计何时发生限制
首先，我不是数据库专家..所以我不确定我的术语或任何内容是否正确，但如果您能忍受我，我希望您能明白。
我有一个为社交网络提供支持的 SQL Azure 数据库。每天都会发生数百万笔交易，从非常简单的交易到复杂的选择，根据距离等对数以万计的用户进行排序。
我的用户数量每天都在增长，我知道（相信）在某些时候我需要实施分片，或者由于 1 个 SQL Azure 资源有限，因此利用 SQL Azure 联合来保持我的应用程序的启动和运行...但我的问题是，我如何确定何时需要执行此操作？
我知道，当我开始使用太多资源时，我的查询将会受到限制……但据我所知，这可能会在明天开始发生，或者需要几年时间。
如果我知道我达到了允许的 80%，那么我知道我需要优先考虑一个解决方案来帮助我扩展规模，但如果我只使用 10%，那么我知道我可以把它放在上面暂时搁置，稍后再处理。
我找不到任何方法，甚至没有提及如何衡量这一点？
有什么建议吗？
谢谢，
史蒂文
First of all, I'm not a DB expert .. so I'm not sure if my terminology or anything is correct here, but if you can bear with me I hope you'll get the idea.
I have a SQL Azure database which powers a social network. Millions of transactions occur every day from very simple ones to complex SELECTS which sort through tens of thousands of users based on distance etc.
My user numbers grow daily and I know (believe) that at some point I'll need to implement sharding, or make use of SQL Azure Federation to keep my app up and running due to 1 SQL Azure having limited resources ... but my question is, how do I figure out when I'm going to need to do this?
I know that when I start to use too much resources, my queries will be throttled ... but for all I know this could start happening tomorrow, or be years away.
If I know I'm hitting 80% of what I'm allowed to, then I know I need to prioritise a solution to help me scale things out, but if I'm only using 10% then I know I can put this on the back-burner and deal with it later.
I can't find any way, or even mention, of how to measure this?
Any suggestions?
Thanks,
Steven
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不知道有任何内置的方法来衡量这一点。如果有人这样做，那么我将非常有兴趣听到它。
然而，Microsoft AppFabric CAT 最佳实践团队提供了一个很棒的库，它是一个瞬态故障处理框架。 参见此处
这会执行许多操作，包括处理重试打开连接和运行查询的逻辑。您可以使用它，但稍微扩展它以在您受到 SQL Azure 限制时记录日志。
这可能不会给您提供您想要的尽可能多的警告，但会帮助您知道何时接近极限。如果您将这种方法与某种应用程序/数据库压力测试结合起来，那么您现在就可以在真正使用之前找到您的限制。
根据您提供的数字，我现在肯定会开始考虑分片。
I don't know of any inbuilt way to measure this. If somebody does then I would be very interested to hear about it.
However there is a great library from the Microsoft AppFabric CAT Best Practices Team which is a transient fault handling framework. See here
This does a number of things including handling retry logic for opening connections and running queries. You could use that but extend it slightly to log when you were being throttled by SQL Azure.
This probably wont give you as much warning as you want, but will help you know when you are getting closer to the limit. If you combined this approach together with some kind of application / database stress testing then you can find your limits now before your real usage gets there.
Based on the numbers you have given I would definitely start looking at sharding now.
如果您还没有阅读下面的文章，我建议您阅读；它包含有关 SQL Azure 限制条件的根本原因的有趣信息。了解正在监控的限制可以帮助您找出数据库受到限制的原因。
Technet 文章：SQL Azure 连接管理
感谢您顺便提及 Enzo 库（免责声明：我写的）！
然而，了解限制的原因将是我的第一个建议，因为根据原因，分片可能会也可能不会帮助您。例如，如果限制的问题是过多的锁，那么分片确实可以减少对单个数据库的锁，但它可能会在稍后的时间回来并咬住你。
谢谢
埃尔维
I would recommend you read the article below if you haven't done so; it contains interesting information about the underlying reasons for SQL Azure throttling conditions. Understanding what is being monitored for throttling can help you figure out why your database is being throttled.
Technet Article: SQL Azure Connection Management
Thank you for mentioning the Enzo library by the way (disclaimer: I wrote it)!
However understanding the reason of the throttling would be my first recommendation because depending on the reason, sharding may or may not help you. For example, if the issue of the thottling is excessive locks, sharding may indeed reduce locks to a single database, but it could come back and bite you at a later time.
Thank you
Herve
对抗限制的最佳实践 1) 使查询尽可能短 2) 批量运行工作负载 3) 采用重试机制。
我还想向您指出一些资源。
1) sql azure 节流和解码原因代码： http://msdn.microsoft .com/en-us/library/ff394106.aspx#throtdling
2) http://geekswithblogs.net /hroggero/archive/2011/05/26/cloud-lesson-learned-exponential-backoff.aspx
best practices to fight throttling 1) keep queries as short as possible 2) run workloads in batches 3) employ retry mechanisms.
I would also like to point you to couple of resources.
1) sql azure throttling and decoding reason codes: http://msdn.microsoft.com/en-us/library/ff394106.aspx#throttling
2) http://geekswithblogs.net/hroggero/archive/2011/05/26/cloud-lesson-learned-exponential-backoff.aspx