分面搜索对 GAE 数据存储读取的影响答案

【问题标题】：Faceted search impact on GAE datastore reads分面搜索对 GAE 数据存储读取的影响
【发布时间】：2012-09-24 04:04:50
【问题描述】：

假设我有 1000 个实体。我希望用户以这种方式通过分面搜索找到实体：

换句话说，每个应用的过滤器（只是一个复选框）可能会导致多达 1000 次读取（后续过滤器的成本会更低，因为返回的实体更少）。这意味着每天大约 10 次“搜索”（= 应用多个过滤器）可能会耗尽我所有的 50k 免费阅读配额。

Memcaching 结果并不是一个真正的选择：如果我有 30 个可以应用的过滤器，那么要存储所有组合，就会有 2^30="超过十亿" 个 memcache 条目（当一个通过先读取十亿个数据存储区来更改实体）。

显然我没有得到任何东西。如何有效地缓存或计算结果？

【问题讨论】：

您是否只需要过滤实体或实际实体的计数？以我的经验，在任何情况下都不应该即时计算计数。写入数据时，分片/内存缓存计数器应保持最新。
@Yasser，首先我只需要计数，以便立即向用户提供反馈。但是，正如我在问题中解释的那样，我不能存储所有与“过滤器组合”相对应的“计数器”，因为这些计数器的数量非常非常非常多，所有这些都需要当某些事情发生变化时更新（使整个观点毫无用处）。
我添加了一个我认为非常适合您情况的答案。

【解决方案1】：

如果您只有 1000 个左右的实体，那么根据您所描述的情况，最好的选择是将所有 1000 个实体保存在内存缓存中，并在内存而不是数据存储中运行查询。 1000 个实体的内存查询应该非常快。

您可以在存储到内存缓存之前将实体转换为 protobuf。看到这个link。

【讨论】：

似乎合法。其实我会尝试在客户端查询。以 32 位掩码压缩 1000 个实体“过滤器关联”，当 JSON 编码时，整个包不需要超过 12kB。（如果浏览器支持类型化数组，则为 4kB）

【解决方案2】：

不要尝试自己实现 - 使用 Search API，它专为在这种情况下有效返回结果而设计。

【讨论】：