まず最初に、全文検索に馴染みが薄い人向けに、背景知識を紹介しておく。一般的なコンピュータサイエンス用語では、全文検索(リンク)は単に、あるドキュメント内の すべてのテキストを検索することを意味する。これの別の手段は、タイトルやキーワードなどのメタデータを調べることである。
SQL Serverという観点では、Full Text Search(リンク)は、リレーショナルデータベースやファイルシステムに格納されたテキストに対して高度な検索機能を提供する。検索はリテラルストリングに限定 されない。アプリケーションは語幹の抽出(リンク)などを理解する。これにより、「swim」を検索するとき、「swims」「swimming」そして 「swam」も返す。特定の語が他の語よりも重要である、加重検索もサポートしており、また2つのフレーズが互いに接近していなければならないような場合 の検索もサポートする。検索基準に基づき、その結果が位置付けられる。
以前のバージョンでは、Full Text Searchは外部サービスであって、残りのSQLサーバと一緒に実行された。この設計で、索引付けされるテーブルやコラムからのデータは、SQL ServerからFull Text Searchサービスにシップされなけらばならない。Full Text Searchカタログは残りのデータベースでバックアップされず、2つのサービスはメモリーやCPUリソースを容易に共有することができない。
こうした問題などに対処するために、SQL Server 2008はFull Text Searchをデータベースに移行した。サーバリソースは、SQL Server自体により動的に管理可能であるので、要求が変わるるごとに、メモリーおよびCPU割り当てを自動的に切り替える。残念ながら、デベロッパは この新たな設計の意図的でない結果にぶち当たっている。
ぶつかり続けている具体的な問題は、トランザクションである。トランザクションデータベースであるため、SQL ServerはつねにACID(リンク)のルールを遵守する。これは検索を実行中であっても、行、ページもしくはテーブル全体がロック可能であることを意味する。こ れは、それほど悪くはないが、Brent Ozar氏(リンク)が説明しているように、誤った検索は混乱を招く原因となる。
Revisionsで全文検索をし、共通キーワードにたとえば、SQLを含めた場合、数万という結果と適合する。これら向けのクエリー計画を見ると、 50000から100000の読み取りがある。重い挿入があるテーブル内でそれをおこなうと、トランザクションが厄介になる。
Jeff Attwood氏は続けている。
stackoverflow.comでの全文検索に非常に依存している。それはSQL Server 2005のもとで、驚くほどよく機能した。残念なことに、SQL Server 2008ではもはやそうはいかない。
Brent氏は、SQL Serverチームにこのことについてフォローアップしており、テストするデータベースのコピーがある。これまでの驚くほどお粗末なSQL Server 2008の全文検索結果、および明らかなアーキテクチャの変更に基づき、SQLチームが何かしてくれると楽観視している。
参照しているStackOverflow(リンク)と いうサイトは、最終的にFull Text Searchを使用する計画はない。最終的にLucene.Net(リンク)と呼ばれる矛盾する検索エンジンに移行する計画をたてている。しかし、Full Text Searchを引き続き使用する計画がある人は、Server 2005から2008へアップグレードした後、この分野を徹底的にテストするべきである。