由于this question中列出的原因,我在构建我自己的客户端搜索引擎,而不是使用基于fullproof的ydn-full-text库.归结为,fullproof按顺序产生了“太奇怪的记录” 300.000个记录中,而(词干之后)只有大约7700个唯一词.因此,我的“理论”是完全证明是基于仅适用于服务器端的传统假设：

>巨大的指数很好
>处理器功能昂贵
>(以及处理更长记录的假设,这仅适用于我的情况,因为我的记录平均只有24个单词1)

而在客户端：

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

基于这些假设,我从一个基本的反向索引开始(由于IndexedDB是一个文档/ nosql数据库,因此仅提供7700条记录).这个倒排的索引是使用Lancaster词干(两个或三个流行词中最激进的一个)提取的,在搜索过程中,我将检索每个单词的索引,并根据不同索引的重叠程度和相似度分配分数单词与原始单词的比(Jaro-Winkler距离).

这种方法的问题：

>“ popular_word Popular_word”的组合非常昂贵

因此,终于引起了我的问题：如何以最小的指数增长来缓解上述问题？我确实知道我的方法将占用大量CPU,但是由于传统的全文本搜索索引似乎无法使用,因此这似乎是唯一可行的方法. (也向我指出了良好的资源或作品)

1这或多或少是将非结构化文本人为分割成小段,但是这种人为分割在相关领域中是标准化的,因此也已在此处使用.我尚未研究将这些“代码段”放在一起并在fullproof处抛出大量文本对索引大小的影响.我认为这不会产生太大的变化,但是如果我弄错了,请务必指出这一点.

解决方法:

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

尽管此答案尚未完全准备就绪,但我想告诉您,如果您使用–enable-experimental-web-platform-features启动Chrome,那么应该有一些可用的功能可以帮助您实现自己的目标期待做.

> IDBObjectStore.openKeyCursor()-无值游标,以防万一您只能摆脱茎
> IDBCursor.continuePrimaryKey(key,primaryKey)-允许您跳过具有相同密钥的项目

我是通过Chrome小组的IDB开发人员获悉这些信息的,尽管我尚未亲自对其进行实验,但这似乎是完美的用例.

我的想法是,如果在同一列上使用两个不同的索引来解决此问题,则可能会获得所需的类似联接的行为,而不会因免费索引而使商店肿.

尽管IDB中的consecutive writes非常糟糕,但读取效果却很好.跨7700个条目的良好性能应该是很稳定的.