客户端搜索引擎优化

Question

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

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

而在客户端：

• 庞大的索引需要很长时间才能填充
• 处理能力仍然有限，但比服务器端相对便宜

基于这些假设，我从一个基本的倒排索引开始（仅给出 7700 条记录，因为 IndexedDB 是一个文档/nosql 数据库）。这个倒排索引是使用 Lancaster 词干提取器（两个或三个流行词干分析器中最激进的一个）提取的，在搜索过程中，我会检索每个单词的索引，根据不同索引的重叠和相似性分配一个分数输入单词与原始单词的比较（Jaro-Winkler 距离）。

这种方法的问题：

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

所以，终于要回答我的问题了：如何以最小的索引增长来缓解上述问题？我确实知道我的方法会占用大量 CPU，但是由于传统的全文搜索索引似乎大得无法使用，这似乎是唯一合理的选择。 （向我指出好的资源或作品也很感激）

¹ 这是或多或少人为地将非结构化文本拆分成小段，但是这种人为拆分在相关领域是标准化的，因此也已在此处使用。我还没有研究将这些“sn-ps”放在一起并在fullproof 处投掷大量文本对索引大小的影响。我认为这不会有很大的不同，但如果我弄错了，请指出这一点。

Answer 1

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

虽然此答案尚未完全投入生产，但我想让您知道，如果您使用 --enable-experimental-web-platform-features 启动 Chrome，那么应该有一些可用的功能可以帮助您实现您想要做的事情。

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

我是通过 Chrome 团队的 IDB 开发人员得知这些的，虽然我自己还没有对它们进行试验，但这似乎是一个完美的用例。

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

虽然 consecutive writes 在 IDB 中非常糟糕，但读取效果非常好。跨越 7700 个条目的良好性能应该是相当可靠的。