Azure表查询中的最大$ filter比较

问题描述 投票:3回答:2

这个页面(https://docs.microsoft.com/en-us/rest/api/storageservices/querying-tables-and-entities)说:

请注意,$ filter字符串中不允许超过15次离散比较。

然而,在我的实验中,我达到了这个极限,没有任何副作用。例如,这来自Azure Storage Explorer:

storageacct / table的统计信息(“PartitionKey eq'1'或PartitionKey eq'2'或PartitionKey eq'3'或PartitionKey eq'4'或PartitionKey eq'5'或PartitionKey eq'6'或PartitionKey eq'7'或PartitionKey eq'8'或PartitionKey eq'9'或PartitionKey eq'10'或PartitionKey eq'11'或PartitionKey eq'12'或PartitionKey eq'13'或PartitionKey eq'14'或PartitionKey eq'15'或PartitionKey eq' 16'或PartitionKey eq'17'或PartitionKey eq'18'或PartitionKey eq'19'或PartitionKey eq'20'或PartitionKey eq'21'或PartitionKey eq'22'或PartitionKey eq'23'或PartitionKey eq'24'或PartitionKey eq'25'或PartitionKey eq'26'或PartitionKey eq'27'或PartitionKey eq'28'或PartitionKey eq'29'或PartitionKey eq'30'或PartitionKey eq'31'或PartitionKey eq'32'或PartitionKey eq'33'或PartitionKey eq'34'或PartitionKey eq'35'或PartitionKey eq'36'或PartitionKey eq'37'或PartitionKey eq'38'或PartitionKey eq'39'或PartitionKey eq'40'或PartitionKey e q'41'“):0个实体

鉴于15比较限制,我希望这个$ filter会导致请求失败。

在我需要以某种方式解释“15个离散比较”的情况下,我尝试了各种和/或组合的查询。它总是成功的。

上一代Azure Table API的限制是否已不再存在?

$ filter还有其他限制吗?如最大字符串长度?

谢谢

**编辑**

我一直在试验这个问题。假设开发存储模拟器与实际服务相同,则可以在查询中使用的比较运算符的数量不是固定数量。以下是一些实验结果,这些结果给出了成功的结果,当递增1时会导致错误:

(PK == V)和((RK == V)或(RK == V)... 97x)// 98比较,97次非PK比较 (PK == V和RK == V)或(PK == V和RK == V)...... 97x // 194比较,97次非PK比较 (RK == V)或(RK == V)... 98x // 98比较,98次非PK比较 (PK == V)或(PK == V)... 98x // 98比较,0非PK比较 (PK == V和RK == V和Prop = V)或(PK == V和RK == V和Prop = V)... 93x // 279比较,186个非PK比较

我不确定从中得出什么结论。我可以安全地做(PK == V和RK == V)或97次,但我可以做(RK == V)或98次。我用相同的值和不同的值测试了它,以及其他比较运算符而不仅仅是等号。

有了这些结果,人们怎么可以预知知道服务器会根据查询字符串返回错误?

15号在哪里发挥作用?

**编辑**

我刚刚在一个实时存储帐户上尝试了所有测试,发现没有最大值。事实上,我能够继续成功添加运算符,直到它开始返回:

远程服务器返回错误:(414)Request-URI太长。

因此,我从存储模拟器获得的所有随机结果显然不适用于实时服务。而且15比较限制根本不存在了吗? (推测)

从试验和错误看,当完整URI长度约为32768(32KB)时,我开始得到414错误。这是一个完全编码的URL,包括所有其他参数,方案,主机名等。我不认为有一种可靠的方法来预先计算由ExecuteQuery产生的确切URI长度,所以我想可以分开请求开始在大约一个32500个字符的$ filter字符串之后?然后不要指望它与存储模拟器一起工作......

azure-table-storage azure-tablequery
2个回答
4
投票

我还使用REST API和Client Library对其进行了测试。我还发现15个离散比较限制不存在。我可以添加许多比较,直到达到URL长度限制。这是我测试的。

  1. 表REST API,1000+ PK比较。
  2. 表REST API,1000+与不同列的比较。
  3. 表客户端库,1000+ PK比较。
  4. 表客户端库,1000+与不同列的比较。

在Azure Table Client Library文档中,我没有找到15个离散比较限制。限制可能已过期。 Table​Query.​Filter​String Property

您可以对以下文档发表评论,以获得文档所有者的官方回复。

Querying Tables and Entities


1
投票

我只想回应别人观察到的事情。

似乎没有比较限制。

在表存储上构建高性能应用程序需要尽可能少地往返服务,这意味着尽可能多地为服务器执行一项工作。

令人遗憾的是,真正的局限性并未在任何地方发布,而且我发现的一个限制(15次比较)并不是真正的限制。

在我的测试中,我观察到:

  • 32,684 url​​长度产生200好
  • 32,685 url长度产生414 URL太长
  • 为已知密钥发送的每个行密钥比较都得到了尊重,并在HTTP响应中产生了结果。没有观察到任何限制。
© www.soinside.com 2019 - 2024. All rights reserved.