是否有一种方法可以使用ATS（Azure表存储）大约500个实体/秒/分区？好的脏读。如果插入中没有立即可用于读取，则确定。
希望将一些大型表从SQL移动到ATS。
扩展：由于这些表的大小超过了SQL Azure的150 GB限制
插入速度：查询速度的倒置索引。插入顺序不是 按表聚集索引排序，这会导致快速SQL表 碎片。 ATS很可能比SQL具有插入优势。
成本：ATS的月费较低。但是ATS的负载成本高达数百万行，并且不能批量处理，因为负载的顺序不是分区。
查询速度：搜索几乎从不在一个partitionKey上。搜索将具有SQL组件和零个或多个ATS组件。此ATS查询始终由partitionKey和返回rowKeys。对partitionKey的原始搜索很快，问题是返回实体（行）的时间。给定的partitionKey平均有1,000个rowKeys，在500个实体/秒/分区时为2秒。但是会有一些partitionKey拥有超过100,000个rowKeys，相当于超过3分钟。一次返回10,000行，并且在SQL中没有查询超过10秒，因为连接的功能不必降低100,000行以在那里考虑这些行。
ATS的选择实体速度是否存在？对于比例和插入速度，想转到ATS。
Windows Azure Storage Abstractions and their Scalability Targets
How to get most out of Windows Azure Tables
Designing a Scalable Partitioning Strategy for Windows Azure Table Storage
关闭不会被修改的查询结果的实体跟踪： context.MergeOption = MergeOption.NoTracking;
答案 0 :(得分：2)
一种可能的解决方法是跨多个分区和/或表划分数据，并行执行所有（子）分区的查询并合并结果。
例如，对于跨分区的条带化，使用单个数字前置分区键可以使分区的可伸缩性倍增10倍。
所以分区键，比如ABCDEFGH，可以将0ABCDEFGH子分区为9ABCDEFGH。
写入分区，前缀数字随机生成或以循环方式生成。
读取将并行查询所有10个分区并合并结果。
对于跨表的条带化，N个表中的一个可以随机或循环方式写入，并且可以并行查询。
答案 1 :(得分：1)
编辑：我原先说过限制是500个事务/分区/秒。那是不对的。该限制实际上是500个实体/分区/秒，如原始问题中所述。
这也适用于您计算的查询速度。如果您查询ATS PartitionKey并返回1000个实体，那么返回单个实体可能只需要更长的时间，也许几百毫秒。另一方面，如果查询返回超过1000个实体，则它将多更慢，因为每组1000行需要基本上独立的事务，并且必须以串行方式完成。
我不完全清楚你在做什么，但听起来好像很多。请记住，在非键列上查询ATS往往非常慢。如果您正在做很多事情，那么使用SQL Azure Federations和扇出查询可能会更好。