azure - 如何使用 Azure 表存储进行大量查找

Question

我有一个包含 2 GB 哈希值的存储，我想使用公共(public) Api 来检查它。

用例

假设我想创建一个 API 来检查我的产品是否认识某个人。为了尊重个人隐私，我不想上传他的姓名、成员(member) ID 等。因此，我决定仅上传组合信息的哈希值，以识别他的身份。现在我有 2 GB (6*10^7) 的 SHA256 哈希值，并且想要以疯狂快速的方式检查它们。

此 API 应托管在 Azure 中。

在阅读了 azure 存储帐户的文档后，我认为 Azure 表存储是正确的存储解决方案。我会将base64 哈希设置为分区键，并将行键留空。

问题

1. 首先，Azure 表是适合该作业的存储吗？
2. 以下各项之间的性能是否有所不同:
   1. 分区键:base64 哈希，行键:空
   2. 分区键:“上传 ID”，行键:empbase64 哈希
3. 访问槽键的时间是否取决于表的大小？

4. 检查分区键是否存在的最快方法是什么？我认为我天真的第一次尝试并不是最好的方法。

   if(members.Where(x=>x.PartitionKey == Convert.ToBase64String(data.Hash)).AsEnumerable().Any()){ return req.CreateResponse(HttpStatusCode.OK, "找到哈希值");}别的{ return req.CreateResponse(HttpStatusCode.NotFound, "未找到哈希");}

5. 如何上传 2 GB 哈希值？我考虑上传一个大文件，并使用 azure 函数在每个 256 位后进行分割，并将该值添加到 azure 存储中。或者有更好的想法吗？

Answer 1

我对此的看法:

1. 如果您需要的唯一查询是“检查现有哈希是否存在”(并在需要时检索其详细信息)，那么表存储是完美的匹配。 key 查找既快又便宜，2 GB 根本不算什么。

2. 哈希提供了最大的多样性，因此我将使用它作为分区键。行键可以是任何东西。如果上传 ID 从未用于(范围)查找，请勿将其用作键。

3. 使用正确的分区键，查找时间应该是恒定的。

4. 如果您的意思是需要检查用户哈希是否存在，只需通过分区键 + 行键检索一行即可。这是最快的操作。请参阅“检索单个实体”here .

5. 表存储支持批量插入。再说一次，2GB 并不多，您问这个问题所花费的时间可能比您上传所需的时间还要多:)