tar*_*ius 12 azure azure-storage azure-sql-database
我读过很多关于比较SQL Azure和Table Service的帖子和文章,他们中的大多数人都说Table Service比SQL Azure更具可扩展性.
抱歉http,我是新用户> _ <但http://azurescope.cloudapp.net/BenchmarkTestCases/ benchmark显示不同的图片.
我的情况.使用SQL Azure:一个包含许多插入的表,每天约172,000,000(每秒2000个).当我在一张表中有200万条记录或9999条至9亿条记录时,我可以期待插入和选择的良好性能吗？
使用表服务:一个包含一定数量分区的表.分区数量可能很大,非常大.
问题1: Table服务在一个表中创建多个,多个分区有一些限制或最佳实践吗？
问题2:在一个分区中我有大量的小实体,就像上面的SQL Azure示例一样.当我在一个分区中有200万条记录或9999亿个实体时,我可以期待插入和选择的良好性能吗？
我知道分片或分区解决方案,但它是一个云服务,云不强大,没有我的代码技能所有工作？
问题3:有人可以向我展示基于SQL Azure和Table Service的大量数据查询的基准吗？
问题4:可能你可以为我的案子建议一个更好的解决方案.
简答
答案很长
在您的情况下,我怀疑SQL Azure不适合您,仅仅是因为SQL Azure数据库的大小限制.如果您插入的每一行都是带索引的1K,那么您将在大约300天内达到50GB的限制.确实,微软正在谈论大于50GB的数据库,但他们没有给出时间框架.SQL Azure还有一个吞吐量限制,我现在无法找到(我很确定它比你需要的少).您可以通过跨多个SQL Azure数据库划分数据来解决此问题.
SQL Azure确实具有的优势是能够运行聚合查询.在AZT中,如果select count(*) from customer不加载每个客户,您甚至无法编写.
AZT还有每个分区每秒500个事务的限制,每个帐户每秒限制"几千".
我发现选择用于分区键(PK)和行键的内容取决于(RK)您将如何查询数据.如果要单独访问每个项目,只需为每行提供自己的分区键和常量行键.这意味着你有很多分区.
例如,如果您插入的这些行是订单而订单属于客户.如果您按客户列出订单更常见,那么您将拥有PK = CustomerId,RK = OrderId.这意味着要查找客户的订单,只需查询分区键即可.要获得特定订单,您需要了解CustomerId和OrderId.客户订单越多,发现任何特定订单的速度就越慢.
如果您只需要通过OrderId访问订单,那么您将使用PK = OrderId,RK = string.Empty并将CustomerId放在另一个属性中.虽然您仍然可以编写一个查询来回收客户的所有订单,但是如果您的查询不使用PartitionKey,AZT不支持除PartitionKey和RowKey之外的索引(有时即使它取决于您的编写方式)它们会导致表扫描.随着您所谈论的记录数量将非常糟糕.
在我遇到的所有场景中,拥有大量分区似乎并不太担心AZT.
您可以在AZT中对数据进行分区的另一种方法是将数据放在不同的表中.例如,您可能希望每天创建一个表.如果要运行上周的查询,请对7个不同的表运行相同的查询.如果您准备在客户端进行一些工作,您甚至可以并行运行它们.
| 归档时间： |
|
| 查看次数： |
3456 次 |
| 最近记录： |