【问题标题】:Getting multiple entities using Azure TableStorage over multiple partitions使用 Azure 表存储在多个分区上获取多个实体
【发布时间】:2022-11-09 22:48:34
【问题描述】:

我正在使用 Azure.Data.Tables (12.6.1),我需要从单个表的多个分区中查询单个记录(因此结果将是多个记录,每个分区有 1 个)。每个实体都需要通过其分区键和行键来查找 - 对于单个 TableClient.GetEntity() 调用,这将是一个点查询。

阅读文档后,我很困惑使用多个分区键/行键对调用TableClient.QueryAsync() 是否有效,并且我发现的搜索结果提供了相互矛盾的建议。

这样做是否有效(对于多个分区键/行键组合,最多约 50 个)还是为每个实体一个接一个地调用 GetEntity() 更好?

var filter = "(PartitionKey eq 'p1' And RowKey eq 'r1') Or " +
    "(PartitionKey eq 'p2' And RowKey eq 'r2') Or ...";
var results = await tableClient.QueryAsync(filter, 500, null, cancelToken);

【问题讨论】:

  • 使用 concat 而不是 OR。
  • @jdweng 你是什么意思?

标签: c# azure azure-table-storage azure-tableclient azure-data-tables


【解决方案1】:

我不知道这里是否有明确的答案,因为它可能取决于您的具体要求。我建议测试不同的选项并进行相应的调整。

仅供参考,这里是关于表https://learn.microsoft.com/azure/storage/tables/table-storage-design-for-query的查询性能的一般参考

【讨论】:

  • 谢谢 - 我知道那个页面。不幸的是,它没有描述多个查询参数(分区键+行键对)是否将被视为独立点查询。测试网络服务也不是很可行——我可以小规模测试它,但我无法真正复制现实世界的用例。
  • 我不相信它们被视为独立的点查询,但我希望索引也一样好。但是假设每个查询的成本总体上是相同的,它仍然可能是您的应用程序可以容忍多少并行点查询与等待处理和返回单个更大请求的效率之间的权衡。
  • 该应用程序可以容忍一个很多独立点查询——毕竟它们都发生在微软方面 :) 但你有点证实了我在其他博客/帖子中看到的暗示——尽管将这些视为高度可优化的子查询应该是微不足道的,他们可能不是那么点查询更好。
【解决方案2】:

我决定为这个场景并行化点查询,并给出了很好的结果。我有大量突发读取场景,我可能有 10/100 的 1000 的查找来针对 100 的数百万条记录)。我更喜欢使用一系列 OR 的查询,因为它们往往会降低吞吐量(我现在手头没有任何统计数据......)

对我来说,并行化通过两种方式发生:

  1. lower level:等待一批Tasks,每个Tasks做一个单独的点查询
  2. 更高级别:构建一个特别繁重的工作负载以扩展多个实例,每个实例通过 1) 进行并行查询

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-18
    • 1970-01-01
    • 2011-03-29
    相关资源
    最近更新 更多