从 Azure 表结构中读取 N 个实体的最有效方法是什么答案

【问题标题】：What is the most efficient way to read N entities from an Azure Table structure从 Azure 表结构中读取 N 个实体的最有效方法是什么
【发布时间】：2012-12-06 11:18:04
【问题描述】：

背景 - 将使用 .NET 4.0、Azure SDK 1.7、Azure 表存储

问题如何最有效地（= 最快的处理时间）读取 N 个条目，其中 N 是一个大的 #（1000 到数百万）个实体，并且每个实体在一组 Azure 表中非常小（

“批处理”此类请求的最有效方法是什么。自然，在底层将需要异步/并行化获取，而不会通过 IO 锁或同步锁导致线程锁，理想情况下，我应该看到 CPU 达到 >80% 的吞吐量，以便服务器调用 Azure 表存储，因为这样处理应该是 CPU 限制与 IO 或内存限制。

【问题讨论】：

标签： asynchronous azure parallel-processing task-parallel-library

【解决方案1】：

由于您要求从 Azure 存储读取“最快”的处理时间，以下是一些提高性能的一般提示（最重要的是最重要的）：

确保自 2012 年 7 月以来已创建 Azure 存储。这是 Azure 存储的第 2 代，它包括 SSD 驱动器上的存储。
在您的情况下，表存储增加了 Azure 存储第 2 代分区的可扩展性目标：http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx
- 10 Gbps 网络与 1 Gbps 网络
- 单个分区可以处理 20,000 个实体/秒
.NET 默认连接更改了这个数字（我认为这可能会在新的 SDK 中解决，但不确定）：http://social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/d84ba34b-b0e0-4961-a167-bbe7618beb83
您可以“加热”Azure 存储，它看到的事务越多，它将使用的控制器/驱动器缓存就越多。以这种方式不断访问您的存储可能会很昂贵
您可以使用多个 Azure 存储帐户。这可以非常有效地分配您的负载（分片）：http://tk.azurewebsites.net/2012/08/26/hacking-azure-for-more-disk-performance/
您可以通过多种方式在表存储中进行架构/设计。您有分区键和行键。但是，您还拥有表本身。请记住，这是 NoSQL，因此您可以拥有 100 个具有相同结构的表来服务不同的数据。这本身可以提高性能，您还可以将这些表存储在不同的 Azure 存储帐户中。 RowKey-> PartitionKey -> Table -> Multiple Storage Accounts都可以认为是“索引”，可以更快访问
我不知道您的数据，但由于您将在 PartitionKey 上进行搜索（我假设），也许不是为每个 PartitionKey 存储 1,000,0000 条非常小的记录，而是将其存储在 zip 文件中并快速获取它/解压缩并然后在本地服务器中使用 linq 对其进行并行查询。玩缓存总是有帮助的，因为你确实有很多小对象。您可能可以将整个分区放在内存中。另一种选择可能是存储分区键，其中包含二进制/逗号分隔的列数据等。
您说您使用的是 Azure 1.7 SDK...我在使用 StorageClient 2.0 库时遇到了问题。我将 1.8 SDK 与 StorageClient 2.0 库一起使用。值得注意的是（不一定是性能），因为它们可能在过去 2 年多的时间里提高了库的效率

【讨论】：

感谢巴特的回复。我们的设计使用了大量的小信息，因为我们代表了一个复杂的信息网格，我们只确定运行时要获取哪些信息。根据我们使用的是并行代码还是异步代码，我们得到的结果好坏参半，我们看到很多 IO 或同步锁定，挑战使 CPU 利用率突破 10%
您是否考虑过将您的小片段/片段以某种分隔格式保存在每个分区或行键的单个列中？检索更大的文件将更有效率。您的操作将受 I/O 限制，“异步操作”之间存在差异，它将工作传递到辅助线程并保持主系统功能（即 ASP.NET Web 应用程序或 Windows 窗体）和执行“并行并发” : 高度计算的工作，比如做一个巨大的数学问题。后者可以扩展到使用高达 100% 的 CPU，而前者不能，因为线程是 I/O 绑定的。
如上所述，您可以使用一些模式来提高并行并发处理数据的效率。尤其是流水线模式，它们像汽车装配一样工作并执行小任务，但一旦完成，它们就会将它们传递到下一步（或线程），然后继续这样做。然后你不必等待所有数据返回......
感谢您的反馈。我们将看一下持久化（以非标准化方式）集群或及时的信息，现在我们正在努力获得尽可能好的原始处理性能。我们基本上是在进行计算，但我们面临的挑战是找到一种方法来消除同步开销（如果我们执行异步）或 IO 开销（如果我们执行并行代码）。我听说有人在 1.4 秒内获得了 30,000 个项目（30 个分区，30 个线程）的性能......我们的性能远低于此，我们无法找出原因。
是的，使用新的 Gen2 Azure 存储可以扩展到跨不同 Azure 存储帐户的多个分区或表。 Azure 存储不是最快的类似 NOSQL 的解决方案。我在 Linux VM 上使用 Redis 获得了相当不错的结果，但这更像是一种内存缓存/数据库混合。如果您正在寻找原始性能，分布式缓存可能是您回退到 Azure 表存储的最佳选择。