いろいろ全文検索エンジンあるけど、いったいどれがどう違うのか迷う。なので、どれは何ができて、何ができないか、主だった違いポイントをまとめてみた。対象は Lucene, HyperEstraier, Rast, Namazu, Senna, Oracle Text。
【検索エンジン <-> RDBMS+全文検索エンジン】
- 検索エンジン単体では relation が張れない（当然）。次のような SQL 相当の事ができない（しない）。
SELECT * FROM test,test2 WHERE test.testCol1=test2.testCol2 AND MATCH(testCol1) AGAINST 'ほげ'
- 検索エンジンの sort は、score ベースである。ORDER BY を指定しないと順序不定、ということはない。
- 検索エンジン単体のほうがスコアリングに手を出しやすい。
- 検索エンジン単体だと limit,offset 指定がなくて全結果が返ってくるインターフェースしかない状態に陥ることもある。
- 検索エンジン単体のほうが表記ゆれに手を出しやすい。
- HA 構成は、検索エンジン単体のほうが組みやすい。
- 基本的には、検索エンジンのほうが機能要素として小さい。
- 属性検索を備えている検索エンジンは、ほぼ RDBMS のテーブル相当の動きができる。
- 検索エンジンは検索条件式が特殊。RDBMS は SELECT に方言レベルの違いがある。
【検索要素の捕らえ方】
- Lucene におけるドキュメントは「属性」を持っていて、その属性は全文検索の対象かあるいはただのデータ。
- HyperEstraier におけるドキュメントは「本文＋属性」で、本文のみが全文検索対象。
- Rast は HyperEstraier と同じ。
- Namazu におけるドキュメントは「本文」のみ。
- Senna は Lucene の属性を RDBMS のテーブルに押し出したと見ることもできる。
検索時に Index は一つしか使いませんという割りきりができる場合は、HyperEstraier, Rast, Namazu。
検索時に Index は一つで形態素解析しか使いませんという割りきりができる場合は、Namazu。
検索時に Index は一つで N-gram しか使いませんという割りきりができる場合は、Rast。
複数属性（フィールド）があって、それぞれに全文検索したい場合は、Lucene か Senna。
Lucene は解析エンジンがプラグイン化されている。
いわゆる RDBMS でのテーブルのような感覚により近しいのは Lucene。
HyperEstraier はドラフト文書形式の制約に縛られやすく、改行コードが扱いにくい。
HyperEstraier は独自の表記ゆれ修正を施すので、オリジナルデータは別の場所に保存しておかなければならない（ファイルシステムとして使用することはできない）。
【PostgreSQL <-> MySQL <-> Oracle】
PostgreSQL + Ludia(Senna)
INDEX作成 : CREATE INDEX ON test USING fulltext(testCol1)
@@演算子 : SELECT * FROM test WHERE testCol1 @@ 'ほげ'
MySQL + Triton(Senna)
INDEX作成 : CREATE FULLTEXT INDEX ON test(testCol1)
MATCH関数 : SELECT * FROM test WHERE MATCH(testCol1) AGAINST 'ほげ'
Oracle (Oracle text)
INDEX作成 : CREATE INDEX idx_testCol1 ON test(testCol1) INDEXTYPE IS CTXSYS.CONTEXT
CONTAINS関数 : SELECT *,score(1) FROM test WHERE CONTAINS(testCol1, 'ほげ', 1) > 0
- レプリケーション構成（HA）の問題が出やすいのは PostgreSQL
- INDEX のモジュール化が進んでいるのは PostgreSQL。Ludia はかなり美しく plugin できるようだ。
- Oracle は文脈とか見たりしてスコアリングをいろいろやりたいと思っているらしい。…ガンバレ。
