寻找提供与GAE数据存储查询匹配的项目的页面/项目计数/导航的想法/替代方案

Question

我喜欢数据存储区的简单性,可扩展性和易用性; 并且在新的ndb库中找到的增强功能非常棒.

据我了解数据存储区最佳实践,当匹配查询的项目数量很大时,不应编写代码来提供匹配查询结果的项目和/或页面计数; 因为唯一的方法是检索所有资源密集的结果.

然而,在包括我们的许多应用程序中,通常希望看到匹配项目的计数并向用户提供导航到那些结果的特定页面的能力.数据存储分页问题由于需要解决fetch(limit,offset = X)的限制而变得更加复杂,如文章Paging Through Large Datasets中所述.为了支持推荐的方法,数据必须包含一个唯一值列,可以按结果显示的方式进行排序.此列将为每个结果页面定义一个起始值; 保存它,我们可以有效地获取相应的页面,允许按要求导航到特定页面或下一页面.因此,如果要显示以多种方式排序的结果,可能需要维护多个此类列.

应该注意的是,从SDK v1.3.1开始,Query Cursors是推荐的数据存储分页方式.它们有一些限制,包括缺乏对IN和!=过滤器运算符的支持.目前我们的一些重要查询使用IN,但我们将尝试使用OR编写它们以用于查询游标.

遵循建议的指南,可以为用户提供(下一个)和(上一个)导航按钮,以及导航过程中的特定页面按钮.例如,如果用户按下(下一步) 3次,应用程序可以显示以下按钮,记住每个按钮的唯一起始记录或光标以保持导航效率:( 上一页)(第1页)(第2页)(页面) -3)(第4页)(下一步).

有些人建议分别跟踪计数,但是当允许用户查询将改变返回结果的丰富字段时,这种方法是不实际的.

我正在寻找有关这些问题的见解以及以下问题:

1. 您在数据存储区应用中提供了哪些查询结果的导航选项来解决这些限制？

2. 如果为用户提供有效的结果计数和整个查询结果集的页面导航是一个优先事项,那么应该放弃使用数据存储区,以支持现在提供的GAE MySql解决方案.

3. 大表架构或数据存储区实现中是否有任何即将发生的更改,这些更改将提供有效计算查询结果的附加功能？

非常感谢您的帮助.

Answer 1

这完全取决于您通常会得到多少结果。例如，通过向 .count() 传递一个合适的限制，如果 #items <= 100，则可以提供精确的计数；如果有更多，则可以提供“很多”。听起来您无法预先计算所有可能的计数，但至少您可以缓存它们，从而节省许多数据存储操作。

使用 NDB，最有效的方法可能是使用 fetch_page() 请求实体的第一页，然后使用生成的游标作为 count() 调用的起点；或者，您最好使用其异步设施同时运行第一页的 fetch() 和 count() 。如果您的查询不支持游标，第二个选项可能是您唯一的选择。大多数 IN / OR 查询当前不支持游标，但如果您按以下顺序排序，它们就支持游标__key__。

在UI选项方面，我认为提供下一页和上一页选项就足够了；可以向前跳几页的“Gooooooogle”用户界面很可爱，但我自己几乎从不使用它。（要实现“上一页”，请颠倒查询的顺序并使用与当前页面相同的游标。我很确定这肯定有效。）