特定表的 Azure 表存储性能

Question

有没有办法使用 ATS(Azure 表存储)处理每秒 500 个实体/分区？脏读没问题。如果插入内容不能立即可供读取，那么就可以了。

希望将一些大型表从 SQL 迁移到 ATS。

• 规模:由于这些表，大小超出了 SQL Azure 150 GB 的限制

• 插入速度:倒排索引可提高查询速度。插入顺序不是按表聚集索引排序导致SQL表快速碎片化。 ATS 很可能比 SQL 具有插入优势。

• 成本:ATS 的每月成本较低。但 ATS 的加载成本较高，可达数百万行，且无法批处理，因为加载顺序不是按分区进行的。

• 查询速度:搜索几乎不会只针对一个分区键。搜索将具有 SQL 组件和零个或多个 ATS 组件。此 ATS 查询始终通过partitionKey 并返回rowKeys。对partitionKey 的原始搜索速度很快，问题是返回实体(行)的时间。给定的partitionKey平均有1,000个rowKey，在500个实体/秒/分区的情况下，这需要2秒。但会有一些partitionKeys超过100,000个rowKeys，相当于超过3分钟。在 SQL 中一次返回 10,000 行，并且没有查询时间超过 10 秒，因为使用联接的功能不必减少 100,000 行才能在 where 中考虑这些行。

• 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;

Answer 1

一种可能的解决方法是跨多个分区和/或表对数据进行 strip 化，跨所有(子)分区并行执行查询并合并结果。

例如，对于跨分区的 strip 化，在分区键前面添加一位数字可以将分区的可扩展性提高 10 倍。

因此，分区键(例如 ABCDEFGH)可以从 0ABCDEFGH 到 9ABCDEFGH 进行子分区。
对分区进行写入，并随机或以循环方式生成前缀数字。读取将并行查询所有 10 个分区并合并结果。

对于跨表的 strip 化，可以随机或以循环方式写入 N 个表之一，并以类似的方式并行查询。