从 Azure 表存储的千万条记录中查询一条记录

Question

我有一个典型的场景，其中消费者调用 Azure 函数 (EP1)（同步），然后根据 Azure 函数 API 的输入参数查询 Azure 表存储（有 500 万条记录）。 Azure 表存储具有以下列：

1. 订单号（递增号）
2. IsConfirmed（值可以是 Y 或 N）
3. 订单类型（最多可以有 6 种类型）
4. 订购日期
5. 订单详情
6. UUID

现在，当消费者查询时，它通常使用订单号进行搜索，并期望订单日期和订单详细信息以及订单号作为响应。

为此，我们选择了：

1. 分区键：IsConfirmed + 订单类型
2. 行键：UUID

现在对于 500 万条记录搜索，由于分区键类型的原因，搜索分区经常会遇到超过 300 万条记录（最大订单有 IsConfirmed 为 Y，订单类型为六种类型中的特定一种）和表查询时间超过 5 分钟。 结果，消费者通常会超时，因为消费者端配置的等待时间为 60 秒。

所以寻找有关如何有效地做到这一点的建议。

1. 我们可以选择分区键作为订单号（但这会创建 500 万个分区）还是订单号+IsConfirmed+TypeofOrder 的组合？
2. 我们的 Java 应用程序是一个写入量大的 Java 应用程序，而读取的次数要少得多。

+++++++++++++更新+++++++++++++++

正如 Gaurav 在回答中所建议的那样，将 orderid 作为分区键后，查询按预期工作。

现在这带来了下一个问题 - 我们确实有其他 API 查询，其中订单数据和类型仅用作输入搜索条件。

由于这与分区键不匹配，所以在第二类查询中，它基本上是进行全扫描，消费者再次超时。

那么应该如何设计来处理这些类型的查询.. Azure 文档说创建一个单独的表，其中订单类型 + 订单日期成为分区键。然而，这意味着每当我们写入表时，我们都必须在两个表上写入（一个以 orderid 作为部分键，另一个作为订单日期 + 类型作为部分键）。

Answer 1

我们可以选择分区键作为订单号吗（但这会创建 5 百万分区）或Order的组合 NUMber+IsConfirmed+TypeofOrder？

您当然可以选择分区键作为订单号，因为拥有大量分区并没有错。但是，请记住分区键值是字符串类型的。您可能想要做的是用一些字符（例如 0）填充您的订单号，以便您的所有订单的长度相同。

在这种情况下，我实际上建议您将行键保留为空。

您可能还需要考虑根据查询要求使用不同的分区键/行键组合存储相同数据的多个副本。例如，如果您要按订单日期查询，您可能希望以订单日期作为分区键来制作数据的另一个副本。

一般来说建议你做点查询（查询包括分区键和行键）。下一个最佳选择是按分区键查询（您希望将分区键中的数据保持较小，以免进行分区扫描）。所有其他选项都会导致完全不推荐的全表扫描。

您可能会发现此链接很有用：https://docs.microsoft.com/en-us/azure/storage/tables/table-storage-design-guidelines。