私は、680 万件のレコードを持つコレクションの全文検索をサポートするサービスの mongodb データベースをホストしています。
そのテキスト インデックスには、さまざまな重みを持つ 10 個のフィールドが含まれています。
ほとんどの検索には 1 秒もかかりません。一部の検索には 2 ～ 3 秒かかります。ただし、一部の検索には 15 ～ 60 秒かかります。私のアプリケーションでは、15 ～ 60 秒の検索ケースは受け入れられません。それらを高速化する方法を見つける必要があります。
インデックスで非常に一般的な単語が検索クエリで使用されている場合、検索には 15 ～ 60 秒かかります。
テキスト検索機能は遅延パラメーターをサポートしていないようです。私が最初に考えたのは、最も一般的な 50 個の単語のリストをテキスト インデックスにキャッシュし、mongodb にそれらの最後の (遅延) 評価と、あまり一般的でないパラメーターによって返されたフィルター結果を評価するように依頼することでした。うまくいけば、人々はまだ私と一緒にいます。たとえば、「products chocolate」というクエリがあるとします。ここで、products は一般的で、chocolate は一般的ではありません。最初に「チョコレート」を評価するようmongodbに依頼し、次に「製品」という用語でそれらの結果をフィルタリングできるようにしたいと思います。これを達成する方法を知っている人はいますか？
上記のシナリオは、データベース クエリから最も一般的な単語 (つまり、「製品」) を省略し、データベースによって検出されたレコードを受け取った後、アプリケーション側で一般的な用語フィルターを再適用することで実現できます。すべてのクエリ ロジックがデータベース上で発生することが望ましいですが、高速支払いのためにアプリケーション側の処理に対してオープンです。
このデザインにはまだいくつかの穴があります。ユーザーが一般的な用語だけを検索する場合、すべての用語でデータベースをヒットするしかありません。事前に読んだ結果、同じコレクションに複数のテキスト インデックス (名前が異なる) を持つことは推奨されていない (またはサポートされていない) ことがわかりました。私の計画は、2 つの同一のテーブルを作成することです。それぞれに 680 万件のレコードがあり、インデックスが異なります。1 つは一般的な単語用で、もう 1 つは一般的でない単語用です。これはぎこちなくてぎこちなく感じますが、速度を上げるために喜んでこれを行います。
このシステムを高速化する方法について、洞察やアドバイスを持っている人はいますか? データベースを高速に保つために、できるだけ多くの処理をデータベースで実行したいと考えています。私の小さな 6.8M レコード テーブルは、mongodb が確認した最大のものではないと確信しています。ありがとう！