Warum haben Datenbanken keine guten Volltextindizes?

Warum unterstützt keines der wichtigsten RDBMS-Systeme wie MySQL, SQL Server, Oracle usw. die Volltextindizierung?

Mir ist klar, dass die meisten Datenbanken bis zu einem gewissen Grad Volltextindizes unterstützen, diese jedoch normalerweise langsamer und mit einem kleineren Funktionsumfang sind. Es scheint, dass Sie jedes Mal, wenn Sie einen wirklich guten Volltextindex wünschen, die Datenbank verlassen und etwas wie Lucene / Solr oder Sphinx verwenden müssen.

Warum ist die Technologie in diesen Volltextsuchmaschinen nicht vollständig in die Datenbankmaschine integriert? Es gibt viele Probleme, die Daten in einem anderen System wie Lucence zu speichern, einschließlich der Aktualisierung der Daten und der Unfähigkeit, die Ergebnisse mit anderen Tabellen zu verknüpfen. Gibt es einen bestimmten technologischen Grund, warum diese beiden Technologien nicht integriert werden können?

Die kurze Antwort lautet, dass das Abrufen von Text fast nichts mit dem Design und der Verwendung traditioneller Datenbanken zu tun hat . Jemand, der ein Ass beim Erstellen / Verwenden eines RDBMS ist, ist wie ein Lamm zum Schlachten, wenn er sich zum ersten Mal dem Abrufen von Text nähert.

(Entschuldigung für die lange Antwort, aber ich bin heute krank im Bett und habe nichts anderes zu tun.)

Im Folgenden könnte leicht kommen unter TL; DR, aber wenn Sie die Zeit und das Interesse haben, was folgt , ist ein Stück der längeren Antwort. Hinweis: Ich spreche von der Implementierung eines kommerziellen Informationsabrufsystems ab 1986. Wir waren ein technischer Erfolg, aber ein Marketing-Flop.

Um IR (Information Retrieval) ordnungsgemäß ausführen zu können, müssen Sie zunächst überlegen, wonach Sie suchen und wie Sie es mithilfe Ihres Abfragemechanismus finden. Das mag einfach klingen, ist aber alles andere als einfach. Hier sind nur einige der Dinge, die Sie entscheiden müssen, bevor Sie überhaupt mit dem Scannen Ihrer Dokumente (oder Felder) beginnen.

1. Ist der Fall wichtig? Ist DoD dasselbe wie Dod? Wie wäre es mit "Flamme" und "FLAMME" (ein Köln basierend auf dem Burger King Whopper (ja, wirklich)).
2. Welche Arten von Token werden Sie indizieren? Sie möchten offensichtlich "Papa" indizieren. Sie möchten wahrscheinlich "daddy123" indizieren. Möchten Sie "123" indizieren? "12.3"? "192.168.1.1"?
3. Wie gehen Sie mit Dingen wie Silbentrennung um? Ein etwas veraltetes Beispiel sind "Datenbank", "Datenbank" und "Datenbank", die alle 1986 gleichzeitig verwendet wurden.
4. Wie bestimmen Sie Satzumbrüche, wenn Ihre Abfragesprache das Konzept "A im selben Satz wie B finden" unterstützt? Obwohl '?' und '!' sind einfach genug, die sind eine Schlampe. Denken Sie an Dinge wie "Mr.", "2.", "etc." usw.
5. Wirst du das Stemming unterstützen? Wenn ja, wie vorsichtig werden Sie sein, um den POS (Part Of Speech) nicht versehentlich zu ändern? ZB können "Katzen" zu "Katze" stammen, aber "Jalousien" können zu "Blind" gehören oder nicht. Wenn es ein Verb war ("Er macht mich blind"), dann können Sie stammen, aber wenn es ein Substantiv war ("Ich mag Ihre Jalousien), können Sie nicht (oder sollten es zumindest nicht). Stemming ist sehr verführerisch, aber es ist ist ein Sumpf der Ersten Ordnung.
6. Welche Sprachen werden Sie unterstützen? Was auf Englisch funktioniert, kann auf Französisch oder Deutsch sehr scheitern, obwohl es seltsamerweise für Japaner in der Hepburn Romanji- Darstellung in Ordnung ist .

Und die Liste geht weiter und weiter.

Dann müssen wir über unsere Abfragesprache nachdenken. Es mag den Anschein haben, dass wenn alles, was Sie unterstützen wollen, ein einfacher Boolescher Wert ist, es einfach sein sollte, aber das eine, worüber man sich allgemein einig ist, ist, dass der reine Boolesche Wert für Text scheiße ist . Zum Beispiel benötigen Sie zusätzliche Operatoren, um die Reihenfolge und die Nähe festzulegen, und Junge, oh, Junge macht das Leben jemals komplizierter. Sie müssen auch wissen, in welchem Bereich Sie sich befinden - Titel, Kopfzeile, Text usw. -, was zu allerlei sammlungsspezifischem Parsing-Spaß führt. Aber jetzt reicht es nicht mehr aus, nur eine Liste der Token im Dokument zu haben. Sie müssen wissen, woim doc kommen sie vor. Dies führt zu einem Adresstupel von (docID, sectionID, para-in-section, Satz-in-para, Wort-in-Satz). Das effiziente Speichern und Durchsuchen dieser Informationen kann für eine Nicht-Spielzeug-Sammlung schwierig werden.

Dann gibt es die tatsächliche Struktur Ihres Datenspeichers. Textsysteme werden normalerweise als "vollständige Inversion" der Dokumente implementiert. Wie viele Indizes hat die durchschnittliche DB? 10? 50? 500? Im IR ist es nicht ungewöhnlich, 5.000.000 oder mehr Indizes zu haben, einen für jedes einzelne Token. Und jedes gegebene Token kann 1 Instanz (z. B. "Narfle" oder "Garthok") oder 10.000.000 Instanzen (z. B. "The") haben. Dies bedeutet, dass Ihre gesamte Methode zum Erstellen und Aktualisieren von Indizes blitzschnell sein muss, sonst sinken Sie in den Sumpf. Und Sie haben noch viele andere Probleme, die eine herkömmliche Datenbank hat: Speicherplatzverwaltung, Wiederherstellung nach einem Absturz, kohärenter Snapshot von einem laufenden System usw. usw.

Endlich gibt es ein Ergebnisranking. Eine nicht eingestufte Ergebnismenge aus einer Booleschen Abfrage für eine große Sammlung ist für einen Menschen nutzlos. Es mag für ein Programm nützlich sein, aber damit habe ich mich nicht befasst. Obwohl unser System Boolean implementiert hat, war unser Verkaufsargument, dass wir das erste im Handel erhältliche System waren, das die Ähnlichkeitssuche basierend auf dem Kosinuskoeffizienten unterstützte . Die Mathematik und Logik dieser Art der Suche (im Grunde ein normalisiertes Punktprodukt des Abfragevektors gegen Millionen von Dokumentvektoren) erforderte radikal andere Ansätze für die Darstellung und Speicherung von Daten als Boolean - definitiv nichts, was in Ihrer durchschnittlichen Datenbank verfügbar ist.

All dies (und mehr) ist der Grund, warum "Textabruf" und "Datenbank" fast nicht zum selben Satz gehören. Ich denke, Sie sollten besser eine gute Datenbank für Ihre "normalen" Anforderungen auswählen und dann ein externes IR-System verwenden, um die "Dokumente" in Ihrer primären Datenbank zu indizieren / zu durchsuchen.

Oracle verfügt über ziemlich ausgefeilte Volltextsuchfunktionen als Teil von Oracle Text und hat diese seit mehr als einem Jahrzehnt. SQL Server 2008 unterstützt auch die Volltextsuche . Ich bin mir also nicht sicher, ob die Prämisse Ihrer Frage richtig ist.

Wenn Ihre Frage wirklich eher im Sinne von "Warum führen wir nicht mehr Volltextsuche in Datenbanken als in mittleren Ebenen durch" lautet, gibt es einige Faktoren. Datenbankentwickler möchten im Allgemeinen normalisierte Daten speichern, nicht unstrukturierte oder halbstrukturierte Daten. Daher würden sie es im Allgemeinen vorziehen, Systeme zu entwerfen, die die eingehenden Daten in separate durchsuchbare Felder analysieren, anstatt die Volltextsuche zu unterstützen. Anwendungsentwickler möchten in der Regel auch keine unstrukturierten oder halbstrukturierten Daten in CLOB / BLOB-Feldern in der Datenbank speichern, da sie es als einfacher ansehen, die Daten in einem Dateisystem zu speichern, und nicht möchten, dass die Datenbank zu groß wird. Ich bin kein Fan dieses Arguments, aber es ist weit verbreitet. Infolgedessen erhalten die meisten Menschen die Daten, die sie ' Ich möchte Volltextsuchen durchführen, wenn ich außerhalb einer Datenbank lebe, daher muss sie außerhalb einer Datenbank indiziert werden. Wenn auch nur ein relativ kleiner Teil Ihrer Daten außerhalb der Datenbank gespeichert ist, wird der Middle Tier-Index zu einer viel schmackhafteren Lösung.

Wenn Sie Ihre unstrukturierten und halbstrukturierten Daten in Oracle speichern, würde ich Oracle Text Feature für Feature mit einer der eigenständigen Volltext-Indizierungslösungen einrichten.

Ich hatte noch nie viele Probleme mit FTS in PG.

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

Das heißt, es ist nicht Sphinx oder Lucene oder was auch immer. Ich denke, es gibt einige Hauptgründe (einige haben oben darauf hingewiesen). Ich denke, der einzige, den sie verpasst haben, wäre der Kostenfaktor.

FTS ist nicht kostenlos. Die Suche erfordert Speicher-, CPU- und Festplattenressourcen. Datenbanken haben normalerweise genug Arbeit, ohne FTS zu machen. Das Skalieren einer Datenbank mit FTS und strukturierter Datenspeicherung ist normalerweise schmerzhaft. Das Skalieren einzelner Dinge (Lucene / Sphinx / was auch immer) und das Skalieren einer Datenbank ist normalerweise weniger schmerzhaft.

Meistens geht es um die Größenbestimmung und Ihre Bedürfnisse. Der Versuch, mit PGs FTS oder Oracle Text so etwas wie Google (oder eine breite Websuche) zu erstellen, ist problematisch.

Ich verwende die FTS-Funktionen von PG in einer Produktionsumgebung, aber ich halte die Dinge, die ich suchen möchte, ziemlich klein / begrenzt. Ich suche keine Word-Dokumente, sondern ganze Datensätze (eine Kombination von DB-Zeilen). Eine unserer Suchfunktionen ist beispielsweise die Suche nach Personen. In unserer Datenbank möchten wir ihre Namen an verschiedenen Orten speichern (Vorname, Nachname usw.). Außerdem haben viele Leute mehr als einen Namen (ich weiß, dass es vielleicht verrückt klingt, aber es ist absolut wahr). Außerdem möchten viele Menschen, dass ihre Umlaute und was nicht-ASCII-Zeichen in ihrem Namen respektiert werden (z. B. wenn sie auf ihrem Scheck gedruckt sind), aber niemand wird sich daran erinnern, wie man den Umlaut eingibt, um die Person zu finden. Deshalb lassen wir Sie entweder mit oder suchen ohne und in der Regel finden Sie die Person, die Sie wollen.

Selbst mit mehreren Namen und der Speicherung von einfachem ASCII und UTF-8 sprechen wir nicht über viel Suchraum UND die Daten befinden sich bereits in der Datenbank (wo sie hingehören). Daher ist es sinnvoll, dies innerhalb der Datenbank zu tun .

Es macht jedoch keinen Sinn, die 1 Million Word-Dokumente von HR in eine Datenbank zu verschieben, um FTS für sie zu verwenden. Es handelt sich bereits um Dateien im Dateisystem, und das Dateisystem leistet einen besseren Job als eine Datenbank, um diese Daten sicher und vernünftig zu halten. Verwenden wir also Lucene oder Sphinx oder was auch immer, um diese Daten zu durchsuchen.

Verwenden Sie das richtige Werkzeug für den Job! Aber zu sagen, dass DBs kein FTS haben, ist nicht wahr, aber der Anwendungsfall, den ich glaube, ist anders.

Die meisten Anwendungen einer Datenbank benötigen keine Volltextsuche.

Wenn es eingebaut wäre, würde es immer noch die gleichen Probleme haben wie ein externer Indexer, Sie würden nur dafür bezahlen (in Zeit / Raum / Kosten / Komplexität), ob Sie es brauchen oder nicht.

Die Volltextsuche ist nicht der Punkt eines relationalen Datenbankverwaltungssystems. Heck, es gibt viele Löcher im relationalen Teil. (Hast du das Buch von Chris Date gelesen?)