客戶端搜索引擎優化

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個條目的良好表現應該是非常穩定的。