データベースに適切な全文索引がないのはなぜですか

MySQL、SQL Server、Oracleなどの主要なRDBMSシステムのいずれも、フルテキストインデックス作成を適切にサポートしていないのはなぜですか。

ほとんどのデータベースはフルテキストインデックスをある程度サポートしていますが、通常は遅く、機能セットが小さいことに気づきます。本当に優れたフルテキストインデックスが必要なときは常に、データベースの外に出て、Lucene / SolrやSphinxなどを使用する必要があるようです。

これらの全文検索エンジンのテクノロジーがデータベースエンジンに完全に統合されていないのはなぜですか？データを最新の状態に保つことや、結果を他のテーブルと結合できないことなど、データをLucenceなどの別のシステムに保持することには多くの問題があります。これら2つのテクノロジーを統合できない具体的な技術上の理由はありますか？

短い答えは、テキスト検索には、従来のデータベースの設計と使用方法とほとんど共通点がないためです。RDBMSの作成/使用のエースである誰かは、テキスト検索に初めて取り組むとき、虐殺の子羊のようです。

（長い答えて申し訳ありませんが、私は今日ベッドで病気で、他に何もすることができません。）

以下は、簡単にTLの下に来ることができました; DRが、あなたは時間と関心を持っている場合、以下は、ある作品長い答えの。注：私は1986年から商業情報検索システムを実装したことから話しています。技術的には成功しましたが、マーケティングは失敗に終わりました。

IR（Information Retrieval）を適切に行うには、まず何を検索し、どのようにクエリメカニズムを使用してそれを見つけるかを考えることから始める必要があります。これは簡単に聞こえるかもしれませんが、簡単ではありません。ここでは、ドキュメント（またはフィールド）のスキャンを開始する前に決定する必要があることの一部を示します。

1. ケースは重要ですか？DoDはdodと同じですか？"flame"と "FLAME"（バーガーキングウッパーに基づくコロン（はい、本当に））はどうですか？
2. どの種類のトークンをインデックスに登録しますか？あなたは明らかに「パパ」に索引を付けたいと思っています。おそらく「daddy123」に索引を付けたいと思います。「123」にインデックスを付けますか？「12.3」？「192.168.1.1」？
3. ハイフネーションのようなものをどのように扱いますか？やや古くなった例は、「データベース」、「データベース」、「データベース」で、1986年にすべて同時に使用されました。
4. クエリ言語が「Bと同じ文でAを見つける」の概念をサポートしている場合、文の区切りをどのように決定しますか？「？」そして「！」十分に簡単です。それらの「。」は雌犬です。「Mr。」、「2。」、「etc。」などについて考えます。
5. ステミングをサポートしますか？その場合、誤ってPOS（品詞）を変更しないように注意してください。たとえば、「cats」は「cat」にステミングできますが、「blinds」は「blind」にステミングすることもしないこともあります。動詞の場合（「彼は私を盲目にする」）はステムできますが、名詞の場合（「私はあなたのブラインドが好きです）はできません（または少なくともそうすべきではありません）。ステミングは非常に魅力的ですが、ファーストオーダーの沼です。
6. どの言語をサポートしますか？奇妙なことに、ヘップバーンのローマ字表記では日本人にとって問題なく動作する傾向がありますが、英語で機能するものは、フランス語またはドイツ語のいずれかで大きな失敗をする可能性があります。

そしてリストはどんどん続きます。

次に、クエリ言語について考える必要があります。サポートするすべてが単純なブール値である場合は簡単であるように見えるかもしれませんが、ほとんどの人が同意していることの1つは、純粋なブール値がテキストを処理することです。たとえば、あなたが発注と近接し、少年を指定するために、追加の演算子が必要になります、ああ、少年はないことを、これまでのメイクの人生はもっと複雑。また、タイトル、ヘッダー、本文など、どのセクションにいるかを知る必要があります。これにより、コレクション固有のあらゆる種類の解析が楽しくなります。しかし、ドキュメントで発生するトークンのリストを用意するだけではもはや十分ではありません。ドキュメントで発生します。これにより、（docID、sectionID、para-in-section、sentence-in-para、word-in-sentence）のアドレスタプルが生成されます。この情報を効率的に保存および検索すると、おもちゃ以外のコレクションが危険にさらされる可能性があります。

次に、データストアの実際の構造があります。テキストシステムは通常、ドキュメントの「完全な反転」として実装されます。平均DBにはいくつのインデックスがありますか？10？50？500？IRでは、個別のトークンごとに1つ、5,000,000以上のインデックスを持つことは珍しくありません。また、特定のトークンには、1つのインスタンス（「narfle」や「garthok」など）または10,000,000のインスタンス（「the」など）を含めることができます。これは、インデックスを作成および更新するためのメソッド全体が高速である必要があるか、または沼に沈むことを意味します。また、従来のDBが行う他の問題の多くは、ディスクスペース管理、クラッシュリカバリ、実行中のシステムからの一貫したスナップショットなど、まだ残っています。

最後に結果のランキングがあります。大規模なコレクションに対するブールクエリからのランク付けされていない結果セットは、人間には役に立ちません。プログラムには役立つかもしれませんが、それは私が扱っていたものではありませんでした。私たちのシステムはブールを実装しましたが、私たちのセールスポイントは、コサイン係数に基づく類似性検索をサポートする最初の商業的に入手可能なシステムであることでした。このタイプの検索の数学と論理（基本的には、何百万ものドキュメントベクトルに対するクエリベクトルの正規化されたドット積）では、ブールとはまったく異なる方法でデータ表現と格納を行う必要がありました。

このすべて（およびそれ以上）が、「テキスト検索」と「データベース」がほとんど同じ文に属していない理由です。「通常の」ニーズに適したデータベースを選択し、外部IRシステムを使用して、プライマリDBの「ドキュメント」をインデックス付け/検索する方がよいでしょう。

OracleはOracle Textの一部としてかなり高度な全文検索機能を備えており、10年以上もその機能を備えています。SQL Server 2008は、フルテキスト検索もサポートしています。だからあなたの質問の前提が正しいかどうかはわかりません。

質問が「中間層ではなくデータベースで全文検索を行う理由」に沿っている場合は、いくつかの要因があります。データベース開発者は一般に、非構造化データや半構造化データではなく、正規化されたデータを格納したいと考えています。したがって、彼らは一般に、全文検索をサポートするのではなく、着信データを個別の検索可能なフィールドに解析するシステムを設計することを好みます。また、アプリケーション開発者は、非構造化データまたは半構造化データをデータベースのCLOB / BLOBフィールドに格納することを望まない傾向があります。ファイルシステムにデータを格納する方が簡単で、データベースが大きくなりすぎないようにするためです。私はこの議論のファンではありませんが、それは一般的なものです。その結果、ほとんどの人は最終的に彼らが持っているデータで終わります dデータベースの外部に存在する全文検索を実行したいので、データベースの外部にインデックスを付ける必要があります。データのごく一部がデータベースの外部にある場合、中間層のインデックスがあると、はるかに適切なソリューションになります。

非構造化データと半構造化データをOracleに格納する場合は、スタンドアロンのフルテキストインデックス作成ソリューションを使用して、Oracle Textを機能ごとに提供します。

私はPGのFTSで多くの問題を経験したことがありません。

http://www.postgresql.org/docs/current/static/textsearch.html

とはいえ、スフィンクスやルセンなどではありません。主な理由はいくつかあると思います（上で指摘した理由もいくつかあります）。彼らが見逃したのはコスト要因だけだと思います。

FTSは無料ではありません。検索にはメモリ、CPU、ディスクのリソースが必要です。通常、データベースにはFTSを行わなくても十分な作業が含まれます。FTSおよび構造化データストレージを実行する1つのデータベースのスケーリングは、通常、困難を伴います。別々のもの（lucene / sphinx /何でも）のスケーリングとデータベースのスケーリングは通常、それほど苦痛ではありません。

ほとんどの場合、サイジングとあなたのニーズは何ですか。PGのFTSまたはOracle Textを使用して、Google（または広範なWeb検索）のようなものを構築しようとすると、問題が発生します。

本番環境ではPGのFTS機能を使用していますが、検索したいものをかなり小さく制限しています。私は単語文書を検索するのではなく、レコード全体（DB行の組み合わせ）を検索します。たとえば、検索機能の1つは人を検索することです。私たちのDBでは、それらの名前を別々の場所（first_name、last_nameなど）に保存します。さらに、多くの人々は複数の名前を持っています（私はそれが狂ったように聞こえるかもしれませんが、それは完全に本当です）。さらに、多くの人はウムラウトと名前のASCII以外の文字を尊重することを望んでいますが（たとえば、小切手に印刷されている場合）、ウムラウトを入力して人物を見つける方法を覚えていないので、またはで検索できますなしで、通常は必要な人を見つけます。

複数の名前があり、プレーンなASCIIとUTF-8が格納されている場合でも、LOTの検索スペースについては話していません。また、データはすでにDB（それが属する場所）にあるため、DB内で実行することは意味があります。 。

しかし、HRの100万ワードのドキュメントをFTSを使用するためだけにDBにプッシュするのは意味がありません。それらはすでにファイルシステム上のファイルであり、ファイルシステムはDBがそのデータを安全かつ適切に保つことができるよりも優れた仕事をするので、Luceneやsphinxなどを使ってそのデータを検索しましょう。

仕事に適したツールを使用してください！しかし、DBにFTSがないと言うのは真実ではありませんが、私が信じているユースケースは異なります。

データベースのほとんどのアプリケーションは全文検索を必要としません。

それが組み込まれている場合でも、外部インデクサーと同じ問題に直面する場合は、必要かどうかにかかわらず、（時間/空間/コスト/複雑さで）支払うだけです。

全文検索は、リレーショナルデータベース管理システムのポイントではありません。一体、関係部分にはたくさんの穴があります。（クリス・デートの本を読みましたか？）