我阅读了很多关于比较SQL Azure和Table Service的帖子和文章，他们中的大多数人都说Table Service比SQL Azure更具可扩展性。
对不起http，我是新用户＆gt; _＆lt; 但http://azurescope.cloudapp.net/BenchmarkTestCases/基准显示不同的图片。
我的情况。使用SQL Azure：一个包含许多插入的表，每天约172,000,000（每秒2000个）。当我在一张表中有200万条记录或9999条至9亿条记录时，我可以期待插入和选择的良好性能吗？
使用表服务：一个包含一定数量分区的表。分区数量可能很大，非常大。
问题＃1：是Table服务在一个表中创建多个，多个分区有一些限制或最佳做法吗？
单个分区中的问题＃2：我有大量小实体，例如上面的SQL Azure示例。当我在一个分区中有200万条记录或9999亿个实体时，我可以期待插入和选择的良好性能吗？
我知道分片或分区解决方案，但它是一个云服务，云不强大，并且在没有我的代码技能的情况下完成所有工作吗？
问题3：有人可以向我展示基于SQL Azure和Table Service的大量数据查询的基准吗？
问题＃4：可能您可以为我的案例提出更好的解决方案。
答案 0 :(得分：6)
简答
长答案
在您的情况下，我怀疑SQL Azure不适合您，仅仅是因为SQL Azure数据库的大小限制。如果您插入的每一行都是带索引的1K，那么您将在大约300天内达到50GB的限制。确实，微软正在谈论大于50GB的数据库，但他们没有给出时间框架。 SQL Azure还有一个吞吐量限制，我现在无法找到（我很确定它比你需要的少）。您可以通过在多个SQL Azure数据库中划分数据来解决这个问题。
SQL Azure的优势在于能够运行聚合查询。在AZT中，您甚至无法在不加载每个客户的情况下编写select count(*) from customer。
AZT每个分区的每秒限制为500次，限制为"several thousand" per second per account。
我发现选择用于分区键（PK）和行键的内容取决于（RK）您将如何查询数据。如果要单独访问每个项目，只需为每行提供自己的分区键和常量行键。这意味着你有很多分区。
例如，如果您插入的这些行是订单而订单属于客户。如果您按客户列出订单更常见，那么您将拥有PK = CustomerId，RK = OrderId。这意味着要查找客户的订单，只需查询分区键即可。要获得特定订单，您需要了解CustomerId和OrderId。客户订单越多，发现任何特定订单的速度就越慢。
如果您只需要通过OrderId访问订单，那么您将使用PK = OrderId，RK = string.Empty并将CustomerId放在另一个属性中。虽然你仍然可以写带回所有订单客户，因为AZT不支持，即使它取决于你如何写比PartitionKey和RowKey等，如果您的查询不使用PartitionKey（有时索引的查询它们会导致表扫描。你所谈论的记录数量非常糟糕。
在所有我遇到的场景，有很多个分区的似乎并不担心AZT太多了。
您可以在AZT中对数据进行分区的另一种方法是将数据放在不同的表中。例如，您可能希望每天创建一个表。如果要运行上周的查询，请对7个不同的表运行相同的查询。如果你准备做一点在客户端的工作你甚至可以并行运行它们。
答案 1 :(得分：0)
Azure SQL可以轻松吸收更多数据。这是我几个月前录制的视频，其中显示了一个示例（可在GitHub上找到），该示例显示了您可以执行此操作的一种方法。
https://www.youtube.com/watch?v=vVrqa0H_rQA
这是完整的仓库
https://github.com/Azure-Samples/streaming-at-scale/tree/master/eventhubs-streamanalytics-azuresql