实际上这样改不是最优解，因为服务端的传输数据会突然变的小很多，实际上应该对不同数据量匹配不同的参数，mpc4j中只举例了三组数据，在APSI的Parameters文件中有大数据量更为精准的匹配，比如16M/256M的，然后多项式大循环中有多层for嵌套，异常复杂，涉及逻辑没敢动，就把几个循环parallel了一下，速度蹭就上来了，然后布谷hash中的insertItems进行了一个分块尝试。对于2

还是继续上一篇的分析，这篇主要是讲怎么构建多项式的

这段代码涉及了复杂的加密计算和多项式运算，以及根据不同情况选择不同的计算方法，确保了在关键词 PIR 系统中正确地处理查询并生成响应。经过和其他项目包的对比，发现KwPirMain的查询竟然是单条交互的，也就是说如果查询数量是1000就要进行1000次交互。这里创建的Hash表是随机填充的，HashKey是根据hash类型（这里选3，也就是要有三个随机生成的HashKey）：使用计算的PRF、指定

由于原算法库是APSI的C++算法库，为了Java调用方便寻找其他类库的相似算法，以mpc4j为例子。mpc4j的mpc4j-s2pc-opf。mpc4j的mpc4j-s2pc-pso。在查看源码的时候意外的发现了mpc4j的。根据上一篇对APSI简单例子的流程分析。模块有引用到APSI。

根据需要选择【DML/DDL/DQL】中的一种进行工单申请。（前提管理员开启了查询审核按钮）检测，如检测失败可以进行。登录地址:18000。（不要勾选LDAP）选择需要查询的数据源。

由于所有项目都使用只有发送者知道的散列函数进行散列，因此接收者不会从了解发送者的散列项目的部分中获得任何好处。设置预期的压缩模式：如果需要使用不同的压缩模式且系统支持 zlib 和 zstd 压缩模式，则检查接收到的查询的压缩模式是否为 zstd。如果是，将压缩模式切换为 zlib，并更新预期的压缩模式为 zlib；如果不是，则将压缩模式切换为 zstd，并更新预期的压缩模式为 zstd。这段代码