元のリンク: https://i18n.site/blog/tech/search
数週間の開発を経て、i18n.site (純粋な静的マークダウン多言語翻訳および Web サイト構築ツール) は、純粋なフロントエンド全文検索をサポートするようになりました。
この記事では、i18n.site の純粋なフロントエンド全文検索の技術的な実装について共有します。 i18n.site にアクセスして検索機能を体験してください。
コードはオープンソースです: 検索カーネル / インタラクティブ インターフェイス
ドキュメントや個人のブログなど、中小規模の純粋に静的な Web サイトの場合、独自に構築した全文検索バックエンドを構築するのは重すぎるため、サービス不要の全文検索がより一般的な選択肢です。
サーバーレス全文検索ソリューションは、次の 2 つの主要カテゴリに分類されます。
1 つ目は、全文検索用のフロントエンド コンポーネントを提供する algolia.com などのサードパーティの検索サービス プロバイダーです。
このようなサービスは検索ボリュームに基づいて料金を支払う必要があり、コンプライアンスの問題により中国本土のユーザーは利用できないことがよくあります。
オフラインやイントラネットでは使用できず、重大な制限があります。この記事ではこれ以上詳しく説明しません。
2 番目のカテゴリは、純粋なフロントエンド全文検索です。
現在、一般的な純粋なフロントエンド全文検索ツールには、lunrjs および ElasticLunr.js (lunrjs に基づく二次開発) が含まれます。
lunrjs にはインデックスを構築するための 2 つの方法があり、どちらも独自の問題があります。
索引には文書のすべての単語が含まれているため、サイズが大きくなります。
ドキュメントが追加または変更されるたびに、新しいインデックス ファイルをロードする必要があります。
これにより、ユーザーの待ち時間が増加し、大量の帯域幅が消費されます。
インデックスの構築は計算集約型のタスクであり、アクセスのたびにインデックスを再構築すると顕著な遅延が発生し、ユーザー エクスペリエンスの低下につながる可能性があります。
lunrjs に加えて、次のような他の全文検索ソリューションもあります。
fusejs、文字列間の類似性を計算して検索します。
このソリューションはパフォーマンスが低く、全文検索には適していません (Fuse.js の長いクエリに 10 秒以上かかる、最適化する方法を参照してください)。
検索にブルーム フィルターを使用する TinySearch は、接頭辞検索 (例: goo を入力して Good または Google を検索する) を実行できず、オートコンプリート効果も実現できません。
既存のソリューションには欠点があるため、i18n.site は次の機能を備えた新しい純粋なフロントエンド全文検索ソリューションを開発しました。
i18n.site の技術実装の詳細は以下で紹介されます。
単語のセグメンテーションは、すべての主流ブラウザでサポートされているブラウザのネイティブ Intl.Segmenter を使用します。
単語分割用の Coffeescript コードは次のとおりです:
SEG = new Intl.Segmenter 0, granularity: "word" seg = (txt) => r = [] for {segment} from SEG.segment(txt) for i from segment.split('.') i = i.trim() if i and !'|`'.includes(i) and !/\p{P}/u.test(i) r.push i r export default seg export segqy = (q) => seg q.toLocaleLowerCase()
場所:
IndexedDB に 5 つのオブジェクト ストレージ テーブルが作成されます:
ドキュメント URL とバージョン番号 ver の配列を渡すことにより、ドキュメント テーブルでドキュメントの存在がチェックされます。存在しない場合は、転置インデックスが作成されます。同時に、渡されなかったドキュメントの逆索引は削除されます。
この方法では、増分インデックス作成が可能になり、計算負荷が軽減されます。
In the front-end interface, a progress bar for index loading can be displayed to avoid lag during the initial load. See "Animated Progress Bar, Based on a Single progress + Pure CSS Implementation" English / Chinese.
The project is developed based on the asynchronous encapsulation of IndexedDB, idb.
IndexedDB reads and writes are asynchronous. When creating an index, documents are loaded concurrently to build the index.
To avoid data loss due to concurrent writes, you can refer to the following coffeescript code, which adds a ing cache between reading and writing to intercept competitive writes.
`coffee
pusher = =>
ing = new Map()
(table, id, val)=>
id_set = ing.get(id)
if id_set
id_set.add val
return
id_set = new Set([val]) ing.set id, id_set pre = await table.get(id) li = pre?.li or [] loop to_add = [...id_set] li.push(...to_add) await table.put({id,li}) for i from to_add id_set.delete i if not id_set.size ing.delete id break return
rindexPush = pusher()
prefixPush = pusher()
`
To display search results in real-time as the user types, for example, showing words like words and work that start with wor when wor is entered.
The search kernel uses the prefix table for the last word after segmentation to find all words with that prefix and search sequentially.
An anti-shake function, debounce (implemented as follows), is used in the front-end interaction to reduce the frequency of searches triggered by user input, thus minimizing computational load.
js
export default (wait, func) => {
var timeout;
return function(...args) {
clearTimeout(timeout);
timeout = setTimeout(func.bind(this, ...args), wait);
};
}
The search first segments the keywords entered by the user.
Assuming there are N words after segmentation, the results are first returned with all keywords, followed by results with N-1, N-2, ..., 1 keywords.
The search results displayed first ensure query precision, while subsequent loaded results (click the "Load More" button) ensure recall.
To improve response speed, the search uses the yield generator to implement on-demand loading, returning results after each limit query.
Note that after each yield, a new IndexedDB query transaction must be opened for the next search.
To display search results in real-time as the user types, for example, showing words like words and work that start with wor when wor is entered.
The search kernel uses the prefix table for the last word after segmentation to find all words with that prefix and search sequentially.
An anti-shake function, debounce (implemented as follows), is used in the front-end interaction to reduce the frequency of searches triggered by user input, thus minimizing computational load.
js
export default (wait, func) => {
var timeout;
return function(...args) {
clearTimeout(timeout);
timeout = setTimeout(func.bind(this, ...args), wait);
};
}
The index table does not store the original text, only words, reducing storage space.
Highlighting search results requires reloading the original text, and using service worker can avoid repeated network requests.
Also, because service worker caches all articles, once a search is performed, the entire website, including search functionality, becomes offline available.
The pure front-end search solution provided by i18n.site is optimized for MarkDown documents.
When displaying search results, the chapter name is shown, and clicking navigates to that chapter.
The pure front-end implementation of inverted full-text search, without the need for a server, is very suitable for small to medium-sized websites such as documents and personal blogs.
i18n.site's open-source self-developed pure front-end search is compact, responsive, and addresses the various shortcomings of current pure front-end full-text search solutions, providing a better user experience.
위 내용은 순수 프런트엔드 역전체 텍스트 검색의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!