Google App Engine JDO Query 使用“NOT IN”的替代逻辑答案

【问题标题】：Google App Engine JDO Query using Alternate logic for 'NOT IN'Google App Engine JDO Query 使用“NOT IN”的替代逻辑
【发布时间】：2011-09-28 14:24:24
【问题描述】：

我正在开发一个 Google App Engine Java 应用程序，用户可以在其中根据搜索条件从数据库中搜索业务对象。搜索结果（记录列表）不应包含过去搜索中的任何记录（一定数量的记录，例如 100 条）。出于这个原因，我将过去的结果存储在用户配置文件中。关于有效实现此逻辑的任何建议（不使用多个集合迭代）。我正在使用 JDO，在查询中使用“NOT IN”条件时存在限制。

【问题讨论】：

业务对象的总数有多大，您希望“已搜索”列表有多大？如果您不断使用已查看的搜索结果更新它们，您的 User 对象听起来会变得很大。
搜索结果只是对象键（不是实际的业务对象）。搜索历史记录将有 500 条搜索结果记录（仅 Keys），添加新 Keys 时旧历史记录将滚落 - 仅保留 500 个记录键。
每次搜索的搜索结果将限制为 200 条记录。这 200 条结果不应包括检索历史中的 500 条记录中的任何一条。感谢您的宝贵时间。

标签： java google-app-engine google-cloud-datastore jdo

【解决方案1】：

这是一个解决方案，假设您的目标是获得 200 个不在历史记录中的密钥。我将尝试估计用作“效率”代理的操作数量，因为这是我们将在new pricing model 中收取费用的方式

获取用户对象和“历史键”（1 次读取操作）
只执行键查询并获取 300 条记录。（300 次小型手术）
在您的代码中，从 300 条记录中减去任何历史记录键。 (0 次操作)
如果在第 3 步之后得到的记录少于 200 条，请再获取 100 条。（必要时重复）（100 条小操作）。
一旦您拥有 200 个以前未见过的键，您可以在需要时获取完整的业务对象实体，或者向用户显示这些键。（如果您获取整个对象，则需要 200 次读取操作）

如果数据存储支持原生“NOT IN”运算符，那么我们可以从第 2 步中减少 100 个小操作，并跳过第 4 步。这里最大的成本将是获取实际的 200 个实体，这必须发生在或没有 NOT IN 运算符。归根结底，与原生 NOT IN 运算符相比，这种方法效率并不低。

进一步优化：

如果您不需要同时显示 200 个键，那么您可以使用光标一次只获得 N 个结果。
我只是在猜测，我最初建议您获得 300 个密钥。您可能需要获得更多或更少。第二次尝试也可能得到不到 100 个。

【讨论】：

非常感谢您的时间和解决方案。如果我在前 300 次提取中没有获得 200 条好记录（比如我只获得了 100 条好记录），那么在我第二次提取时，我必须将结果与 500 条历史记录和最初的 100 条好记录进行比较。（它会继续进行连续提取）您认为执行此收集操作会影响性能吗？是否有任何数据存储解决方案可以解决此问题。即使使用 Google 原生数据存储 API？
@user969227 从代码中的（大）组可能结果中过滤掉（小）组排除结果将比任何数据存储选项快得多。如果您从头开始构建数据库，这仍然是最快的方法。
除非您有重复的业务对象，否则您不必与最初的 100 个进行比较。
感谢你们的时间和建议。感谢您的帮助。