客户端搜索引擎优化

Question

由于概述的原因， 这个问题我建立我自己的客户端的搜索引擎，而不是使用ydn-full-text它是基于库fullproof 。 它归结为完全fullproof产生“太多的记录”在300.000记录的顺序，而（在词干之后）只有大约7700个独特的单词。 所以我的“理论”是完全基于传统的假设，这些假设仅适用于服务器端：

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

而在客户端：

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

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

这种方法的问题：

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

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

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

Answer 1

这是一个很好的问题，感谢为IndexedDB标记带来一些质量。

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

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

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

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

虽然在IDB中连续写入非常糟糕，但读取很棒。 7700个条目的良好表现应该是非常稳定的。