由于 this question 中列出的原因我正在构建自己的客户端搜索引擎，而不是使用基于 fullproof 的 ydn-full-text 库.归结为 fullproof以 300.000 条记录的顺序产生“太多记录”，而(在词干提取之后)只有大约 7700 个独特的单词。所以我的“理论”是完全证明基于仅适用于服务器端的传统假设:
- 大索引没问题
- 处理器能力很昂贵
- (处理较长记录的假设仅适用于我的情况，因为我的记录平均只有 24 个字1)
而在客户端:
- 庞大的索引需要很长时间才能填充
- 处理能力仍然有限，但比服务器端便宜
基于这些假设，我从一个基本的倒排索引开始(仅提供 7700 条记录，因为 IndexedDB 是一个文档/nosql 数据库)。这个倒排索引是使用 Lancaster 词干分析器(两个或三个流行词干分析器中最激进的一个)进行词干提取的，在搜索过程中，我会检索每个单词的索引，根据不同索引的重叠和相似性分配一个分数输入词与原始词的对比(Jaro-Winkler 距离)。
这种方法的问题:
- “popular_word + popular_word”的组合非常昂贵
那么，终于到了我的问题:我怎样才能以最小的索引增长来缓解上述问题？我知道我的方法会占用 CPU 资源，但由于传统的全文搜索索引似乎大得无法使用，这似乎是唯一可行的方法。 (也欢迎指点我好的资源或作品)
1 这或多或少是将非结构化文本人为地分割成小段，但是这种人为分割在相关领域是标准化的，所以也被用在这里。我还没有研究将这些“片段”放在一起并在 fullproof 处抛出大量文本对索引大小的影响。 .我认为这不会产生很大的不同，但如果我弄错了，请指出这一点。
最佳答案
这是一个很好的问题，感谢您为 the IndexedDB tag 带来一些质量.
虽然这个答案还没有完全准备好，但我想让您知道，如果您使用 --enable-experimental-web-platform-features 启动 Chrome，那么应该有几个功能可用的，可以帮助您实现您想要做的事情。
IDBObjectStore.openKeyCursor()- 无值游标，以防您只使用 stemIDBCursor.continuePrimaryKey(key, primaryKey)- 允许您跳过具有相同键的项目
我是通过 Chrome 团队的 IDB 开发人员得知这些的，虽然我还没有亲自试验过它们，但这似乎是一个完美的用例。
我的想法是，如果您在同一列上使用两个不同的索引来解决这个问题，您可能能够获得您正在寻找的类似连接的行为，而不会因不必要的索引而使您的商店膨胀。
同时 consecutive writes在 IDB 中非常糟糕，读取很棒。跨 7700 个条目的良好性能应该是相当站得住脚的。
关于javascript - 客户端搜索引擎优化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21895680/