Google App Engine JDO 查询使用“NOT IN”的备用逻辑

发布于 2024-12-07 03:57:56 字数 194 浏览 1 评论 0原文

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

I'm developing a Google App Engine Java app where users can search business objects from database based on search criteria.
The search results (a list of records) should not include any of the records (certain number of records, say 100) from their past searches. I'm storing the past results in the User Profile for this reason.
Any suggestions on efficiently implementing this logic (without using multiple collection iterations). I'm using JDO and there are restrictions in using 'NOT IN' condition in the queries.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

清风无影 2024-12-14 03:57:56

这是一个解决方案,假设您的目标是获取 200 个不在历史记录中的密钥。
我将尝试估计用作“效率”代理的操作数量,因为这是我们在 新定价模型

  1. 获取用户对象和“历史键”(1 个读取操作)
  2. 仅执行键查询并获取 300 条记录。 (300 个小操作)
  3. 在您的代码中,从 300 条记录中减去任何历史记录键。 (0 次操作)
  4. 如果在步骤 3 后最终得到的记录少于 200 条,请再获取 100 条记录。(如有必要,请重复)(100 次小操作)。
  5. 一旦您拥有 200 个以前未见过的键,您就可以在需要时获取完整的业务对象实体,或者向用户显示键。 (如果获取整个对象,则为 200 个读取操作)

如果数据存储支持本机“NOT IN”运算符,那么我们可以从步骤 2 中削减 100 个小操作,并跳过步骤 4。此处最大的成本将是获取实际的 200 个操作实体,无论有或没有 NOT IN 运算符,这都必须发生。最终,与本机 NOT IN 运算符的做法相比,此方法的效率并不是那么低。

进一步优化:

  • 如果不需要一次全部显示200个键,那么可以使用光标一次只得到N个结果。

  • 当我建议你首先获得 300 个钥匙时,我只是猜测。您可能需要获得更多或更少。您在第二次尝试时也可能获得不到 100 个钥匙。

Here's a solution, assuming your goal is to get 200 keys that are not in the history already.
I will attempt to estimate the number of operations used as a proxy for "efficiency", since this is how we will be charged in the new pricing model

  1. Fetch the User object and "history keys" (1 read operation)
  2. Do a keys only query and fetch 300 records. (300 small operations)
  3. In your code, subtract any of the history keys from the 300 records. (0 operations)
  4. If you end up with less than 200 records after step 3, fetch another 100.(repeat if necessary) (100 small operations).
  5. Once you have 200 keys not seen before, you can fetch the full business object entities if you need them, or display the keys to the user. (200 read operations if you fetch the entire objects)

If the datastore supported a native "NOT IN" operator, then we could shave off 100 small operations from step 2, and skip step 4. The largest cost here will be fetching the actual 200 entities, which would have to happen with or without the NOT IN operator. Ultimately, this method is not that inefficient compared to what a native NOT IN operator would do.

Further optimizations:

  • If you don't need to display 200 keys all at once, then you can use cursors to only get N results at a time.

  • I am simply guessing when I suggest that you get 300 keys at first. You may need to get more or less. You can also probably get less than 100 on the second attempt.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文