データベースに適切な全文索引がないのはなぜですか
MySQL、SQL Server、Oracleなどの主要なRDBMSシステムのいずれも、フルテキストインデックス作成を適切にサポートしていないのはなぜですか。
ほとんどのデータベースはフルテキストインデックスをある程度サポートしていますが、通常は遅く、機能セットが小さいことを理解しています。本当に優れたフルテキストインデックスが必要な場合は、データベースの外に出て、Lucene/SolrやSphinxなどを使用する必要があるようです。
これらの全文検索エンジンのテクノロジーがデータベースエンジンに完全に統合されていないのはなぜですか？データを最新の状態に保つことや、結果を他のテーブルと結合できないことなど、データをLucenceなどの別のシステムに保持することには多くの問題があります。これら2つのテクノロジーを統合できない具体的な技術上の理由はありますか？
短い答えは、テキスト検索には、従来のデータベースの設計と使用方法と共通する何もないためです。 RDBMSの作成/使用のエースである誰かは、テキスト検索に初めて取り組むとき、 虐殺の子羊 のような人です。
（長い答えて申し訳ありませんが、私は今日ベッドで病気で、他に何もすることができません。）
以下はTL; DRの下で簡単に発生する可能性がありますが、時間と興味があれば、より長い答えのpieceが続きます。注：私は1986年から商業情報検索システムを実装したことから話しています。技術的には成功しましたが、マーケティングは失敗に終わりました。
IR（Information Retrieval）を適切に行うには、検索するwhatとhowについて考えることから始める必要があります。クエリメカニズム。これは簡単に聞こえるかもしれませんが、何でもしかし簡単です。ここでは、ドキュメント（またはフィールド）のスキャンを開始する前に決定する必要があることの一部を示します。
- ケースは重要ですか？ DoDはdodと同じですか？ "flame"と "FLAME"（バーガーキングホッパーに基づいたコロン（はい、本当に））はどうですか？.
- どの種類のトークンをインデックスに登録しますか？あなたは明らかに「パパ」に索引を付けたいと思っています。おそらく「daddy123」に索引を付けたいと思います。 「123」にインデックスを付けますか？ 「12.3」？ 「192.168.1.1」？
- ハイフネーションなどをどのように扱いますか？やや古くなった例は、「データベース」、「データベース」、「データベース」で、1986年にすべて同時に使用されました。
- クエリ言語が「Bと同じ文でAを見つける」の概念をサポートしている場合、文の区切りをどのように決定しますか？ 「？」そして「！」十分に簡単です。それらの「。」は雌犬です。 「Mr。」、「2。」、「etc。」などについて考えます。
- ステミングをサポートしますか？その場合、誤ってPOS（品詞）を変更しないように注意してください。例えば。 「猫」は「猫」にステミングできますが、「ブラインド」は「ブラインド」にステミングすることも、しないこともあります。動詞の場合（「彼は私を盲目にする」）はステムできますが、名詞の場合（「私はあなたのブラインドが好きです」）はできません（または、少なくともそうすべきではありません）。ファーストオーダーの沼です。
- どの言語をサポートしますか？奇妙なことに、奇妙なことに Hepburn Romanji 表現では日本語でうまく機能する傾向がありますが、英語で機能するものはフランス語またはドイツ語で大きな失敗をする可能性があります。
そしてリストはどんどん続きます。
次に、クエリ言語について考える必要があります。サポートするすべてが単純なブールである場合、それは簡単であるように思われるかもしれませんが、ほとんど普遍的に合意されていることの1つは、テキストの純粋なブールsucksです。 。たとえば、順序と近接性を指定するために追加の演算子が必要になります。また、男の子はそうしますそれは、人生をより複雑にします。また、タイトル、ヘッダー、本文など、sectionがどのセクションにあるかを知る必要があります。これにより、コレクション固有のあらゆる種類の解析が楽しくなります。しかし今では、ドキュメント内で発生するトークンのリストを用意するだけでは十分ではなく、それらが発生するドキュメント内の場所を知る必要があります。これにより、アドレスタプル（docID、sectionID、para-in-section、sentence-in-para、Word-in-sentence）が生成されます。この情報を効率的に保存および検索すると、おもちゃ以外のコレクションが危険にさらされる可能性があります。
次に、データストアの実際の構造があります。テキストシステムは通常、ドキュメントの「完全反転」として実装されます。平均DBにはいくつのインデックスがありますか？ 10？ 50？ 500？ IRでは、5,000,000以上のインデックスが、個別のトークンごとに1つあることは珍しくありません。また、特定のトークンには、1つのインスタンス（「narfle」や「garthok」など）または10,000,000のインスタンス（「the」など）を含めることができます。これは、インデックスを作成および更新するためのメソッド全体が高速である必要があること、または沼に沈むことを意味します。また、従来のDBが行う他の多くの問題がまだあります。ディスク領域管理、クラッシュリカバリ、実行中のシステムからのコヒーレントスナップショットなどです。
最後に結果のランキングがあります。大規模なコレクションに対するブールクエリからのランク付けされていない結果セットは、人間には役に立ちません。プログラムには役立つかもしれませんが、それは私が扱っていたものではありませんでした。私たちのシステムはブールを実装しましたが、私たちのセールスポイントは、 コサイン係数 に基づく類似性検索をサポートする最初の商業的に入手可能なシステムであることです。このタイプの検索の数学と論理（基本的には、何百万ものドキュメントベクトルに対するクエリベクトルの正規化されたドット積）では、ブールとはまったく異なる方法でデータ表現と格納を行う必要がありました。
このすべて（およびそれ以上）が、「テキスト検索」と「データベース」がほとんど同じ文に属していない理由です。 「通常の」ニーズに適したデータベースを選び、外部IRシステムを使用して、プライマリDBの「ドキュメント」のインデックス作成/検索を行う方がよいでしょう。
オラクルは Oracle Text の一部としてかなり高度な全文検索機能を備えており、10年以上もその機能を備えています。 SQL Server 2008は フルテキスト検索 もサポートしています。だからあなたの質問の前提が正しいかどうかはわかりません。
質問が「中間層ではなくデータベースで全文検索を行う理由」に沿っている場合は、いくつかの要因があります。データベース開発者は通常、非構造化データや半構造化データではなく、正規化されたデータを格納したいと考えています。したがって、彼らは一般的に、全文検索をサポートするのではなく、着信データを個別の検索可能なフィールドに解析するシステムを設計することを好みます。また、アプリケーション開発者は、非構造化データまたは半構造化データをデータベースのCLOB/BLOBフィールドに格納することを望まない傾向があります。ファイルシステムにデータを格納する方が簡単で、データベースが大きくなりすぎないようにするためです。私はこの議論のファンではありませんが、それは一般的なものです。その結果、ほとんどの人は、データベースの外に住んでいるときにフルテキスト検索を実行したいデータを取得することになるため、データベースの外にインデックスを付ける必要があります。データのごく一部がデータベースの外部にある場合、中間層のインデックスがあると、はるかに適切なソリューションになります。
非構造化データと半構造化データを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機能を運用環境で使用していますが、検索したいものをかなり小さく制限しています。 Word文書を検索するのではなく、レコード全体（DB行の組み合わせ）を検索します。たとえば、検索機能の1つは人を検索することです。私たちのDBでは、名前を別々の場所（first_name、last_nameなど）に保存します。さらに、多くの人々は複数の名前を持っています（私はそれが狂ったように聞こえるかもしれませんが、それは完全に本当です）。さらに、多くの人はウムラウトと名前のASCII以外の文字が尊重されることを望んでいます（たとえば、小切手に印刷されている場合）が、ウムラウトを入力して人物を見つける方法を覚えていないため、またはで検索できますなしで、通常は必要な人を見つけます。
複数の名前があり、プレーンなASCIIとUTF-8が格納されている場合でも、LOTの検索スペースについては話していません。また、データはすでにDB（それが属する場所）にあるため、DB内で実行することは意味があります。 。
しかし、HRの100万個のWordドキュメントをFTSを使用するためだけにDBにプッシュすることは意味がありません。それらはすでにファイルシステム上のファイルであり、ファイルシステムはDBがそのデータを安全かつ健全に保つことができるよりも優れた仕事をするので、Luceneやsphinxなどを使ってそのデータを検索しましょう。
仕事に適したツールを使用してください！しかし、DBにFTSがないと言うのは本当ではありませんが、私が信じるユースケースは異なります。
データベースのほとんどのアプリケーションは全文検索を必要としません。
それが組み込まれている場合でも、外部インデクサーと同じ問題に直面する場合は、必要かどうかに関係なく（時間/空間/コスト/複雑さで）支払うだけです。
全文検索はrelationalデータベース管理システムの要点ではありません。一体、関係部分にはたくさんの穴があります。 （クリス・デートの本を読みましたか？）