5

私はdjangoの全文検索エンジンを研究しています。インストールが簡単で、インデックス作成が高速で、インデックス更新が高速で、インデックス作成中にブロックされず、検索が高速でなければなりません。

多くの Web ページを読んだ後、短いリストを作成しました。フィールドの重み付けなど)。

次に、いくつかのベンチマークを作成しました。そのために、ネット上で多くの無料の書籍を収集して、1 485 000 レコード (id、タイトル、本文) を持つデータベース テーブルを生成しました。各レコードの長さは約 600 バイトです。データベースから、既存の 100,000 語のリストも生成し、それらをシャッフルして検索リストを作成しました。テストのために、私は自分のラップトップ (4Go RAM、デュアル コア 2.0Ghz) で 2 回実行しました。 . 「自家製」のベンチマーク結果は次のとおりです。

1485000 records with Title (150 bytes) and body (450 bytes)

Mysql 5.0.75/Ubuntu 9.04 Fulltext :
==========================================================================

Full indexing : 7m14.146s

1 thread, 1000 searchs with single word randomly taken from database : 
First run : 0:01:11.553524
next run : 0:00:00.168508

Mysql 5.5.4 m3/Ubuntu 9.04 Fulltext :
==========================================================================

Full indexing : 6m08.154s

1 thread, 1000 searchs with single word randomly taken from database : 
First run : 0:01:09.553524
next run : 0:00:20.316903

1 thread, 100000 searchs with single word randomly taken from database : 
First run : 9m09s
next run : 5m38s

1 thread, 10000 random strings (random strings should not be found in database) :
just after the 100000 search test : 0:00:15.007353

1 thread, boolean search : 1000 x (+word1 +word2) 
First run : 0:00:21.205404
next run : 0:00:00.145098

Djapian Fulltext : 
==========================================================================

Full indexing : 84m7.601s

1 thread, 1000 searchs with single word randomly taken from database with prefetch : 
First run : 0:02:28.085680
next run : 0:00:14.300236

python-xapian Fulltext :
==========================================================================

1 thread, 1000 searchs with single word randomly taken from database : 
First run : 0:01:26.402084
next run : 0:00:00.695092

django-sphinx Fulltext :
==========================================================================

Full indexing : 1m25.957s

1 thread, 1000 searchs with single word randomly taken from database : 
First run : 0:01:30.073001
next run : 0:00:05.203294

1 thread, 100000 searchs with single word randomly taken from database : 
First run : 12m48s
next run : 9m45s

1 thread, 10000 random strings (random strings should not be found in database) :
just after the 100000 search test : 0:00:23.535319

1 thread, boolean search : 1000 x (word1 word2) 
First run : 0:00:20.856486
next run : 0:00:03.005416

ご覧のとおり、Mysql は全文検索に関してそれほど悪くはありません。さらに、そのクエリ キャッシュは非常に効率的です。

インストールするものは何もなく (Innodb プロダクション テーブルを MyISAM 検索テーブルに同期するための小さなスクリプトを書くだけでよい)、ステミングなどの高度な検索機能は本当に必要ないので、Mysql は私には良い選択のように思えます...

質問は次のとおりです。Mysql 全文検索エンジンと sphinx および xapian についてどう思いますか?

4

3 に答える 3

4

私はXapianをテストしていませんが、昨年、全文ソリューションを比較するプレゼンテーションを行いました：http: //www.slideshare.net/billkarwin/practical-full-text-search-with-my-sql

Sphinxは検索で最速です。ただし、インデックスにデータを追加することは、インデックス全体を最初から作成するのと同じくらい費用がかかるため、段階的に入ってくるデータにインデックスを付けることは困難です。

そのため、2つのSphinxインデックスを維持している人もいます。1つはアーカイブデータを含む大きなインデックスで、もう1つは最近のデータを含む小さなインデックスです。定期的に（たとえば毎週）、最近のインデックスをアーカイブされたインデックスにマージし（2つのインデックスをマージする方が安価です）、新しい週に備えて小さなインデックスを切り捨てます。これはフォーラムのようなものにはうまく機能しますが、ウィキにはあまり適していません。

ApacheSolrもチェックしてください。これはLuceneのラッパーであり、Luceneの使用をはるかに簡単にし、さらに機能的にします。そのプレゼンテーションをデザインしたとき、私はSolrについて知りませんでした。

ワシントンタイムズは、Djangoと一緒にSolrを使用するプロジェクトの例です。

于 2010-05-05T21:52:14.210 に答える
2

MyISAM の全文を読めるなら、それで十分です。データベースに組み込まれていると確かに便利なので、他のテーブルへの結合を使用して簡単かつ比較的効率的に検索を実行できます。そしてブールモード検索は素晴らしいです。

欠点は、単語のマッチングがかなり初歩的であることです。明らかにステミングはありませんが、ハイフン/アポストロフィの特別な処理もありません。また、デフォルトの最小単語長とストップ リストは非常に過剰です。(ソフトウェアが「howbeit」が一般的に入力された単語であると判断した場合は、心配してください!)

最悪の場合: もちろん、これは厄介な古い MyISAM 専用であるため、InnoDB テーブルに適切に収まることはありません。( InnoDB を使用していますよね? )

于 2010-05-05T22:07:32.240 に答える
1

また、MySQL のフル テキスト機能の使いやすさと Sphinx のパワーと柔軟性を組み合わせたSphinxQLを検討することもできます。

インストール手順はこちら

于 2010-05-06T12:42:12.017 に答える