客户端搜索引擎优化

Question

由于this question中列出的原因，我正在构建自己的客户端搜索引擎，而不是使用基于fullproof的ydn-full-text库。它归结为fullproof产生了“太多的记录”，大约300.000条记录，而（在词干之后）只有大约7700个独特的单词。因此，我的“理论”是完全基于传统的假设，这些假设仅适用于服务器端：

• 巨大的指数很好
• 处理器功率昂贵
• （以及处理较长记录的假设，这些记录仅适用于我的案例，因为我的记录平均只有24个字 ¹ ）

而在客户端：

• 巨大的指数需要很长时间才能填充
• 处理能力仍然有限，但比服务器端便宜

基于这些假设，我开始使用基本倒排索引（仅提供7700条记录，IndexedDB是文档/ nosql数据库）。这个倒排索引已经使用Lancaster词干分析器（两个或三个流行词汇中最具攻击性的一个）来阻止，并且在搜索期间我将检索每个词的索引，根据不同索引的重叠和相似性分配分数。打字与原版（Jaro-Winkler距离）。

这种方法的问题：

• “popular_word + popular_word”的组合非常昂贵

所以，最后回答我的问题：如何以最小的指数增长缓解上述问题？我确实理解我的方法将是CPU密集型的，但由于传统的全文搜索索引看起来非常大，这似乎是唯一合理的道路。 （指出我很好的资源或作品也很感激）

¹ 这或多或少地将非结构化文本人为地分成小段，但是这种人工分裂在相关领域中是标准化的，因此也在这里使用。我没有研究将这些“片段”保持在一起并在fullproof处抛出大量文本的索引大小的影响。我认为这不会产生很大的不同，但如果我弄错了，那么请指出这一点。

Answer 1

这是一个很好的问题，感谢为the IndexedDB tag带来一些品质。

虽然这个答案还没有完全准备就绪，但我想告诉您，如果您使用--enable-experimental-web-platform-features启动Chrome，那么应该有一些可用的功能可以帮助您实现您的目标

• IDBObjectStore.openKeyCursor() - 无价值游标，以防您只能使用干线
• IDBCursor.continuePrimaryKey(key, primaryKey) - 允许您跳过具有相同键的项目

我通过Chrome团队的IDB开发人员了解了这些情况，虽然我还没有亲自试验这些，但这似乎是一个完美的用例。

我的想法是，如果您在同一列上使用两个不同的索引来解决此问题，您可能能够获得您正在寻找的类似连接的行为，而不会使用无偿索引使您的商店膨胀。

虽然IDB中consecutive writes非常糟糕，但读取效果很好。 7700个条目的良好表现应该是非常稳定的。