Feinkörnige Suche über einen großen Datensatz

Ich habe ungefähr 4 Millionen Datensätze pro Tag und muss 7 Jahre online bleiben. Wir sehen uns also 10,2 Milliarden Datensätze an, die ich durchsuchen muss. Die Benutzer erwarten, dass die Suche für eine Benutzeroberfläche schnell genug ist, was zu 3-5 Sekunden führt

Aufgrund der Politik, die außerhalb meiner Kontrolle liegt, kann ich keine Standard-Datenbanklösung verwenden, da dies bedeutet, dass ich die Datenbank einem anderen Team zur Verwaltung übergeben muss (nicht fragen), was bedeutet, dass ich die Fähigkeit zur Optimierung von Hardware und Hardware verliere Software, da sie einen einheitlichen Service für Datenbanken haben und (intern) vom GB in Rechnung gestellt werden. Ich bin sicher, ich werde Kommentare bekommen, die darauf hinweisen, dass ich den Punkt mache, den ich bereits habe, und das Management versteht, was sie von mir verlangen, ist lächerlich.

Ich habe versucht, Lucene als Kern meiner Lösung zu verwenden. Speichern der tatsächlichen Daten, unterteilt nach Typ und Tag, in Flatfiles. Verwenden Sie dann ein Lucene-Dokument, um einige der Felder zu indizieren, nach denen gesucht wird, wobei das einzige "gespeicherte" Feld die ID des Datensatzes ist (damit ich es aus der Einfachdatei lesen kann).

Ich bin nicht genau über Lucene oder Festplatten informiert, aber nach meinem Verständnis wird es anfängliche E / A / Suchzeit für die Suche im Index geben. Wenn ich dann alle Lucene-Dokument-IDs habe, lese ich die Dokumente, die weitere E / A verursachen Ich suche Zeit, dann lese ich den aktuellen Datensatz aus der Wohnung ... Ich kann mir angesichts der Größe des Datensatzes nicht vorstellen, dass dies sehr schnell gehen wird, worüber ich mir ein wenig Sorgen mache.

Lucene hat eine maximale Dokumentgröße von 2,1 Milliarden pro Index, daher werde ich hier mehrere Angaben benötigen.

Sieht dieser Ansatz auf den ersten Blick so aus, als könnte er funktionieren?

Die Daten, die ich speichere, sind Ereignisaktionsdaten. Die meisten Abfragen werden nach Ereignis-ID gruppiert und erhalten die letzten Ereignisaktionsdetails für ein bestimmtes Ereignis. Einige der Abfragen analysieren Ereignisse großer Mengen und ihre einzelnen Ereignisaktionen.

Sie haben nicht gesagt, wie groß die Daten sind, wie groß die einzelnen Felder sind oder welches Budget Sie haben.

Unabhängig davon, für welches Indizierungssystem Sie sich entscheiden, sollten Sie Hardware auf das Problem werfen. Sie sollten die Festplatten nicht nach irgendetwas durchsuchen müssen. Indizieren Sie alle Daten mithilfe eines Schemas, das sehr schnell durchlaufen werden kann (möglicherweise eine sortierte Liste oder ein sortierter Baum). Speichern Sie den Index auf der Festplatte, und speichern Sie dann den gesamten Index im RAM. Möglicherweise benötigen Sie dazu zehn oder sogar Hunderte von Gigabyte RAM.

Wenn die einzelnen Felder groß oder variabel sind, sollten Sie Hashes indizieren.

Der Preis für den Server könnte beängstigend sein.

Wenn Sie alle technischen Details ignorieren, handelt es sich um ein Organisations- / Managementproblem, das vom Management Ihrer Organisation gelöst werden muss.

Ihr Manager muss bereit sein, das Problem nach oben zu treten und / oder seine Benutzer dazu zu bringen, das Problem auf hohem Niveau anzusprechen.

Stellen Sie auf Ihrer Ebene einen Kostenvoranschlag für Oracle und Oracle-Hardware zusammen oder fordern Sie einen Kostenvoranschlag an. Stellen Sie dann eine realistische Schätzung für einen Hadoop-Cluster zusammen.

Trotz des Hype sind diese Cluster nicht billig (Sie benötigen wahrscheinlich 18 8 Prozessorknoten mit 64 GB Speicher und 4 x 2 TB Festplatten, die auf drei Racks verteilt sind, dann weitere 4 Knoten für den Katalog usw.). Unterschätze nicht ; Wenn Sie gewinnen, müssen Sie es implementieren.

Lassen Sie uns zunächst das Problem in Bezug auf seine Anforderungen klar formulieren:

1. Das System muss mindestens 4 Millionen Datensätze pro Tag speichern.
2. Das System muss dem Benutzer eine Suchschnittstelle bereitstellen.
   2.1 Die Suchfunktion muss Ergebnisse in maximal 3 Sekunden zurückgeben
3. Das System muss in der Lage sein, mindestens 10,2 Milliarden Datensätze zu durchsuchen
4. Das System muss eine maßgeschneiderte Datenbank verwenden.
   4.1 Das System muss über Hardware und Software verfügen, die für die zu entwickelnde Datenbank optimiert sind

Es gibt wahrscheinlich zusätzliche nicht funktionale Anforderungen sowie Details zur Größe der einzelnen Datensätze, die wahrscheinlich für Ihre Situation relevant sind.

Die kurze Antwort lautet, dass Sie ein Anforderungsproblem haben. Wenn Sie sich diese Anforderungen ansehen, gelten drei (die ersten drei) korrekt für das System, um dessen Funktion und Verhalten zu definieren. Die letzte Anforderung ist aus puristischer Sicht keine gültige Anforderung, aber ich habe gesehen, dass diese Art von Anforderungen in Arbeitserklärungen enthalten sind.

Die Art und Weise, wie dieses Problem gelöst wird, besteht darin, die Kosten der 4. Anforderung unter Berücksichtigung der anderen drei zu schätzen. Sobald Sie dies getan haben, präsentieren Sie dies als Ihre Lösungskosten. Das Management wird in Panik geraten und Sie sofort fragen, warum das Problem nicht zu einem angemessenen Preis gelöst werden kann. Dies ist der Einstiegspunkt für Ihre Diskussion darüber, was geschehen muss. Halten Sie eine erschwingliche Alternative bereit und präsentieren Sie diese.

Dies steht im Gegensatz zu dem, was Sie gerade tun, bei dem davon ausgegangen wird, dass die anderen drei bei dem letzten nicht erfüllt werden können. Das Management versteht es nicht, weil sie nur Dollarzeichen sehen.

Wenn ich in Ihren Schuhen stecke, würde ich mit einer sehr vernünftigen, buchstäblichen Implementierung beginnen, bei der nur ein reguläres RDBMS verwendet wird, das in die Anwendung eingebettet ist, damit sie nicht das Gefühl haben, etwas unterstützen zu müssen. SQLite, H2 oder eine andere eingebettete Datenbank sollten Folgendes tun: Keine speziellen Flatfiles, keine exotischen Indizes, kein Nichts: Nur eine einfache Anwendung der Standardpraktiken zur Lösung des vorliegenden Problems, wobei die Unermesslichkeit der Daten größtenteils außer Acht gelassen wird. (Ich würde natürlich eine ausreichend große Ganzzahl als Schlüssel wählen, und das ist alles, ziemlich genau.)

Während ich daran arbeite, fallen mir wahrscheinlich ein paar weitere Ideen ein, wie ich es schneller machen kann, ohne auf etwas Exotisches zurückzugreifen.

Dann würde ich dies testen, um zu sehen, wie es funktioniert, und ich würde die Ergebnisse zusammen mit der funktionierenden Lösung den "Befugnissen des Seins" in Ihrer Organisation demonstrieren.

1. Es besteht die Möglichkeit, dass Ihre unkomplizierte Implementierung innerhalb der erforderlichen Einschränkungen ausgeführt wird, sodass Sie genau dort in Ordnung sind, keine weiteren Schritte ausführen müssen und keine Ressourcen verschwendet werden.

2. Wenn die Leistung der unkomplizierten Implementierung außerhalb, aber nicht zu weit außerhalb der erforderlichen Einschränkungen liegt, könnten die "Mächte des Seins" sagen: "Nun, das ist nah genug, wir wollen nichts anderes dagegen tun." so wird es sein. " Auch hier werden keine Ressourcen verschwendet.

3. Wenn die Leistung der einfachen Implementierung außerhalb der erforderlichen Einschränkungen liegt, aber innerhalb derselben Größenordnung liegt, würde ich ihnen sagen, dass sie nur bessere, größere und schnellere Hardware kaufen sollen. Die meisten Chancen stehen gut, dass sie das tun und der Fall abgeschlossen ist.

4. Wenn sie keine bessere, größere und schnellere Hardware kaufen möchten, würde ich empfehlen, dass sie ihre Anforderung überdenken, kein großes, skalierbares RDBMS zu verwenden. Wenn sie vernünftig sind und Sie gezeigt haben, dass Sie auch vernünftig sind, werden sie es wahrscheinlich überdenken.

5. Wenn die Mächte des Seins keinen der vernünftigen Wege beschreiten wollen und stattdessen wollen, dass Sie die Rolle eines Magiers spielen, dann und nur dann würde ich mir Sorgen um exotische Lösungen machen. Viele Chancen stehen gut, dass die Dinge diesen Punkt nicht erreichen werden. Aber selbst wenn dies der Fall ist, ist der Arbeitsaufwand, den Sie bis zu diesem Zeitpunkt vergeblich geleistet haben, relativ gering und das Glücksspiel wert, das möglicherweise ausreicht.

Vom vorderen Ende aus denken ...

Wenn Sie Ihre Nachschlagetypen in der Benutzeroberfläche trennen, können möglicherweise vernünftigere Einschränkungen auftreten.

Es hört sich so an, als ob ein Nachschlagetyp aktuelle Ereignisaktionsdaten für ein Ereignis sind, mit denen Sie bei Ihrer Datensuche nach Zeit isolieren können. Dies ergibt möglicherweise einen viel kleineren Datensatz, mit der wahrscheinlichen Erwartung eines Benutzers, dass er bald abgerufen wird.

Andere Arten der Suche, bei denen große Datenmengen oder alte Zeitrahmensuchen durchgeführt werden müssen, können mit einer anderen Benutzeroberfläche (oder mehreren Benutzeroberflächen) versehen werden, wobei ein netter Drehknopf darauf hinweist, dass ... jetzt nachgedacht wird. Da dies vom Benutzer als mühsamerer Anforderungssatz verstanden werden kann, kann Geduld vernünftigerweise erwartet werden. Und natürlich realistisch notwendig.

Ich weiß nicht, ob Sie in der Lage sind, das Front-Tend-Design zu beeinflussen, aber wenn Sie die Einschränkungen vermitteln können, mit denen Sie arbeiten, werden hoffentlich diejenigen, die mit der Benutzerinteraktion umgehen, mit Verständnis reagieren (zumindest einige).