순수 프런트엔드 역전체 텍스트 검색

元のリンク: 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 つの方法があり、どちらも独自の問題があります。

1. 事前に構築されたインデックス ファイル

索引には文書のすべての単語が含まれているため、サイズが大きくなります。
ドキュメントが追加または変更されるたびに、新しいインデックス ファイルをロードする必要があります。
これにより、ユーザーの待ち時間が増加し、大量の帯域幅が消費されます。

1. ドキュメントを読み込み、その場でインデックスを構築する

インデックスの構築は計算集約型のタスクであり、アクセスのたびにインデックスを再構築すると顕著な遅延が発生し、ユーザー エクスペリエンスの低下につながる可能性があります。

---

lunrjs に加えて、次のような他の全文検索ソリューションもあります。

fusejs、文字列間の類似性を計算して検索します。

このソリューションはパフォーマンスが低く、全文検索には適していません (Fuse.js の長いクエリに 10 秒以上かかる、最適化する方法を参照してください)。

検索にブルーム フィルターを使用する TinySearch は、接頭辞検索 (例: goo を入力して Good または Google を検索する) を実行できず、オートコンプリート効果も実現できません。

既存のソリューションには欠点があるため、i18n.site は次の機能を備えた新しい純粋なフロントエンド全文検索ソリューションを開発しました。

1. コンパクトなサイズで多言語検索をサポートします。検索カーネルは、gzip でパッケージ化した場合、わずか 6.9 KB です (比較すると、lunrjs は 25 KB)
2. メモリ使用量が少なく、パフォーマンスが高速な IndexedDB に基づいた転置インデックスを構築します
3. ドキュメントが追加/変更されると、追加または変更されたドキュメントのみが再インデックス化されるため、計算量が削減されます
4. 接頭辞検索をサポートし、ユーザーの入力に応じて検索結果をリアルタイムに表示できます
5. オフラインでの利用可能

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()

場所:

• /p{P}/ は、次のような句読点と一致する正規表現です。 " # $ % & ' ( ) * , - . / : ; < = > ? @ [ ] ^ _ { | } ~. .
  • split('.' )Firefox ブラウザの単語分割が分割されないためです。` .

  インデックスの構築

  IndexedDB に 5 つのオブジェクト ストレージ テーブルが作成されます:

  • 単語: ID - 単語
  • doc: ID - ドキュメント URL - ドキュメントのバージョン番号
  • docWord: ドキュメント ID - 単語 ID の配列
  • prefix: prefix - 単語 ID の配列
  • rindex: 単語 ID - ドキュメント ID - 行番号の配列

  ドキュメント 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.

  IndexedDB High Concurrent Writing

  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()
  `

  Prefix Real-Time 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);
  };
  }
  

  Precision and Recall

  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.

  

  On-Demand Loading

  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.

  Prefix Real-Time 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);
  };
  }
  

  Offline Availability

  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.

  Optimization for Displaying MarkDown Documents

  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.

  

  Summary

  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 중국어 웹사이트의 기타 관련 기사를 참조하세요!