Frage

Ich baue einen Index von Daten, die viele Drillinge in Form (document, term, weight) mit sich bringen zu speichern. Ich werde Speichern von ein paar Millionen solcher Reihen auf. Zur Zeit mache ich dies in MySQL als eine einfache Tabelle. Ich bin Speichern der Dokumenten- und Begriff Identifikatoren als String-Werte als Fremdschlüssel zu anderen Tabellen. Ich bin neu zu schreiben die Software und die Suche nach besseren Möglichkeiten, die Daten zu speichern.

auf dem Weg der Suche HBase arbeitet, scheint dies das Schema recht gut zu passen. Stattdessen viele Drillinge zu speichern, konnte ich Karte document {term => weight}.

Ich tue dies auf einem einzelnen Knoten , so dass ich kümmere mich nicht um verteilten Knoten usw. Soll ich mit MySQL nur bleiben, weil es funktioniert, oder wäre es klug, HBase zu versuchen? Ich sehe, dass Lucene es für die Volltextindizierung verwendet (was analog ist, was ich tue). Meine Frage ist wirklich, wie würde ein einzelner HBase Knoten mit einem einzigen MySQL Knoten vergleichen? Ich bin von Scala kommen, so könnte eine direkte Java API einen Vorteil gegenüber JDBC haben und MySQL Parsen etc jede Abfrage?

Mein Hauptanliegen ist Eintragsgeschwindigkeit, wie zuvor die Engpass war. Nach der Verarbeitung, werde ich wahrscheinlich die Daten wieder in MySQL bis Ende setzte für die Live-Abfrage-, weil ich einige Berechnungen tun muß, die innerhalb von MySQL besser gemacht werden.

Ich werde versuchen, beide Prototyping, aber ich bin sicher, dass die Gemeinschaft mir einige wertvolle Einblicke in diese geben kann.

War es hilfreich?

Lösung

Verwenden Sie das richtige Werkzeug für den Job.

Es gibt eine Menge von anti-RDBMS oder BASE-Systemen (Grundsätzlich verfügbar, Soft-State, schließlich konsistent), im Gegensatz zu ACID (Unteilbarkeit, Konsistenz, Isolation, Durability) von hier und hier .

Ich habe traditionellen RDBMS verwendet und wenn Sie CLOBs / BLOBs speichern können, sie tun nicht integrierte Indizes für die Suche dieser Objekte speziell angepasst hat.

Sie möchten die meiste Arbeit tun (die gewichteten Frequenz Berechnung für jedes Tupel gefunden), wenn ein Dokument eingefügt wird.

Sie könnten auch einige Arbeit Scoring den Nutzen tun wollen jedes (DocumentID, Suchbegriff) Paar nach jeder Suche.

Auf diese Weise können Sie immer besser suchen jedes Mal geben.

Sie wollen auch eine Punktzahl oder Gewicht für jede Suche speichern und gewichtet Noten für Ähnlichkeit zu anderen suchen.

Es ist wahrscheinlich, dass einige Suchanfragen sind häufiger als andere, und dass die Benutzer formulieren ihre Suchanfrage nicht richtig, obwohl sie bedeuten eine gemeinsame Suche zu tun.

ein Dokument einfügen sollte auch einige Änderungen an das Suchgewicht verursachen Indizes.

Je mehr ich darüber nachdenke, desto komplexer die Lösung wird. Sie müssen mit einem guten Design beginnen. Je mehr Faktoren, die Ihre Design geht davon aus, desto besser das Ergebnis.

Andere Tipps

MapReduce scheint wie eine gute Möglichkeit, die Tupel zu erzeugen. Wenn Sie einen scala Job in eine JAR-Datei bekommen kann (nicht sicher, da ich nicht scala benutzt habe vor und bin ein Jvm n00b), würde es sich um eine einfach Sache sein, es zu senden an und ein bisschen ein Wrapper zu schreiben, um sie auszuführen auf der Karte reduzieren Cluster.

Wie die Tupel für die Speicherung, nachdem Sie fertig sind, könntest du auch ein Dokument basierte Datenbank wie mongodb , wenn Sie nur Tupel zu speichern.

In der Regel, es klingt wie Sie etwas mehr statistische mit den Texten tun ... Haben Sie einfach betrachtet mit Lucene oder Solr zu tun, was Sie tun, anstatt zu schreiben Ihre eigenen?

scroll top