25万件未満の潜在的なレコードを処理する軽量のドキュメントインデックス

最近、ドキュメントインデックスエンジンの制限にからかわれています。かなり堅牢な検索機能を必要とする小さなWebサイトを開発していましたが、ハードウェアの制約により、このニーズを処理するLucene風のソリューション（通常のSolrやElasticSearchなど）を展開できませんでした。

それでも、データベースを多用する複雑なデータや計算を提供する必要がありましたが、25万件を超える潜在的なレコードを処理する必要はありませんでした。これを処理するためだけにSolrまたはESインスタンス全体をデプロイすることは、無駄に思えました。

考えてみたらかなり大きな問題のようです。ほとんどの人は、SQLだけで検索要件を処理します。彼らはデータに対してSQLクエリを実行するだけです。彼らの検索機能もひどいものになります。

• 一部のシステム（特に共有ホスト）では、ブランケットフルテキストワイルドカード検索を行うと速度が大幅に低下し、特に複雑なクエリや多数の結合がある場合にデータベースがダウンする可能性があります。

• ユーザーからの単一のリクエストに対して複数のクエリを実行することになります。ますます複雑なクエリでこれを回避できるかもしれませんが、前のポイントを参照してください。

• フルテキストエンジンに通常存在する機能の欠如。

データベースにはサーバーとしてデプロイする必要があるという同じ問題があり、その後SQLiteが登場し、突然、単一のファイルに自己完結型のデータベースをデプロイできるようになりました。私のグーグルは何も生成していません-全文索引付け/検索のためにこのようなものが存在するかどうか疑問に思います。

軽量のドキュメントインデックスを実装するか（たとえば、別の質問への回答で説明されているように）、またはこれらの状況でSQLを使い続けるかを決定するときに考慮すべき要素は何ですか？

ご存知のように、redisの使用を検討する必要があります。

• コンテキストのアイデアを使用します。ドキュメントの詳細を知らずに深く掘り下げるのは難しいでしょう。多くの場合、ドキュメントの見出しから多くのことを識別できます。各ドキュメントのプロファイリングは、Webクロールと同様に、基本的な最初のステップです。

• キーワードの辞書にある単語の各ドキュメントを数えます。プロジェクト全体に対する各単語の人気度を追跡します。ドキュメントまたはセットで高い関連性を検出できる場合は、このカウントのイテレータにさらに重みを追加します。
  
  これが最初に行うことは、あなたのセット全体の包括的なリストをあなたに与えることです。そのリストにないものはすべて、「結果なし」が自動的に返されます。結果のランキングが人気の下位5〜20％未満（インデックスで検索クエリを実行している場合）の場合も、単に結果はないと言うことをお勧めします。

• あなたがいる場合です Redisのようなもので行く、あるいは単にあなたが記述子ファイルまたはミニDBファイルとメモリに前後それぞれ固有のドキュメント背中とを記述したページオブジェクトを使用してドキュメントをペアにすることができ、独自のメモリ構造を作ります。よくある検索をスロットで競うか、検索ごとに成長する時間を与えることにより、一般的な検索をメモリに保持します。

• さらに進むには、2つ以上のドキュメントのリンク/参照/ポインター/インデックス/何でもグループ化する参照データと、キーワードまたはフレーズのプールの保存を開始します。基本的には、タグクラウドを取得します。

• さらに、辞書内の単語の後に、類似したメタデータ/タイトルのドキュメントで一般的に正確な文字列が先行または先行する場合を追跡することにより、フレーズ検出を行います。これは集中的ですが、データをレンダリングするために必要なパスは1つだけです。

• データを分離し、実際の使用において互いに関連するグループを維持する方法が多いほど、優れています。

• ユーザーが上位3つではない結果をクリックするたびに追跡することにより、正確性の可能性を関連付けます。完璧な結果が得られなかったユーザーの検索を監視することで、フレーズ検出を改善できます。クライアントの検索に関連するようにクエリを強制します。

• ドキュメントの更新を監視する必要がありますか？Chronjobs /シェルスクリプトまたはスケジュールされたタスク/バッチスクリプトが役立ちます。当然ながら、スケジュールとスクリプト作成にはさまざまなオプションがあります。

• ディスクを浪費し、速度を上げ、複雑さを失います。ドキュメントの複数のツリーおよび/またはドキュメントへのリンクのツリーを保存します。基準が満たされたツリーのみを検索するか、少なくともほとんどの場合、結果をより早く取得することを優先します。

• 独自の軽量置換エンジンを作成するか、迅速な文字検出を使用し、正規表現を使用しないものを見つけます。または、数時間で正規表現を使用して1つだけ作成しますが、十分な検索ではパフォーマンスの違いがここで顕著になります。

• とてもたくさんのこと。

これらは、堅牢なドキュメントのインデックス作成と検索を実装するための可能なソリューションとして意図されています。すべてが含まれているわけではありません。そして、おそらく、予備のボックスを手に入れ、ニューラルネットをその上に投げ、そのニューラルネットへの素晴らしいWebインターフェイスを作成するために数日を費やす方が良いでしょう。