Frage Bester Datenspeicher für Milliarden von Zeilen


Ich muss in der Lage sein, kleine Datenmengen (ungefähr 50-75 Bytes) für Milliarden von Datensätzen zu speichern (~ 3 Milliarden / Monat für ein Jahr).

Die einzige Voraussetzung sind schnelle Einfügungen und schnelle Suchvorgänge für alle Datensätze mit derselben GUID und die Möglichkeit, auf den Datenspeicher von .net zuzugreifen.

Ich bin ein SQL-Server-Typ und ich denke SQL Server kann Tun Sie dies, aber mit all dem Gerede über BigTable, CouchDB und andere Nosql-Lösungen klingt es mehr und mehr wie eine Alternative zu einem traditionellen RDBS, die aufgrund von Optimierungen für verteilte Abfragen und Skalierung am besten ist. Ich habe versucht, Cassandra und die .net-Bibliotheken derzeit nicht kompilieren oder sind alle Änderungen vorbehalten (zusammen mit Cassandra selbst).

Ich habe in vielen verfügbaren Nosql-Datenspeicher nachgeschaut, kann aber keinen finden, der meine Anforderungen als robuste, produktionsfertige Plattform erfüllt.

Wenn Sie 36 Milliarden kleine, flache Datensätze speichern müssten, damit sie von .net aus zugänglich sind, was würden Sie wählen und warum?


76
2018-05-08 16:11


Ursprung


Antworten:


Speichern ~ 3,5 TB Daten und Einfügen von ca. 1K / sec 24x7, und auch Abfrage mit einer Rate nicht angegeben, ist es möglich mit SQL Server, aber es gibt mehr Fragen:

  • Welche Verfügbarkeitsanforderung haben Sie dafür? 99,999% Uptime, oder ist 95% genug?
  • Welche Zuverlässigkeitsanforderung haben Sie? Fehlt Ihnen eine Beilage, kostet das $ 1M?
  • Welche Wiederherstellungsanforderung haben Sie? Wenn Sie einen Tag Daten verlieren, ist das wichtig?
  • Welche Konsistenzanforderung haben Sie? Muss ein Schreibvorgang beim nächsten Lesevorgang garantiert sichtbar sein?

Wenn Sie alle diese Anforderungen benötigen, habe ich hervorgehoben, dass die Last, die Sie vorschlagen, Millionen an Hardware und Lizenzierung auf einem relationalen System kostet, egal welches Gimmick Sie ausprobieren (Sharding, Partitionierung usw.). Ein Nosql-System würde sich ihrer Definition nach nicht erfüllen alle diese Anforderungen.

Offensichtlich haben Sie schon einige dieser Anforderungen gelockert. Es gibt einen schönen visuellen Leitfaden, der die Nosql-Angebote vergleicht, die auf dem "Pick 2 of 3" -Paradigma basieren Visual Guide zu NoSQL-Systemen:

nosql comparisson

Nach Aktualisierung des OP-Kommentars

Mit SQL Server wäre dies eine einfache Implementierung:

  • eine einzelne Tabelle gruppiert (GUID, Zeit) Schlüssel. Ja, wird es bekommen fragmentiert, aber die Fragmentierung wirkt sich auf Read-Ahead-Operationen aus und Read-Ahead-Operationen werden nur für signifikante Bereichs-Scans benötigt. Da Sie nur nach bestimmten GUIDs und Datumsbereichen suchen, spielt die Fragmentierung keine Rolle. Ja, ist ein breiter Schlüssel, so dass Seiten ohne Blätter eine schlechte Schlüsseldichte haben. Ja, es wird zu einem schlechten Füllfaktor führen. Und ja, Seitenaufteilungen können auftreten. Trotz dieser Probleme ist angesichts der Anforderungen immer noch die beste Cluster-Schlüsselwahl.
  • Partitionieren Sie die Tabelle nach Zeit, damit Sie die Löschung der abgelaufenen Datensätze effizient durchführen können automatisches Schiebefenster. Ergänzen Sie dies mit einer Online-Indexpartitionswiederherstellung des letzten Monats, um den durch das GUID-Clustering eingeführten schlechten Füllfaktor und die fehlerhafte Fragmentierung zu eliminieren.
  • Aktivieren Sie die Seitenkomprimierung. Da die gruppierten Schlüsselgruppen zuerst nach GUID gruppiert sind, werden alle Datensätze einer GUID nebeneinander angezeigt Seitenkomprimierung eine gute Möglichkeit, Wörterbuchkomprimierung zu implementieren.
  • Sie benötigen einen schnellen E / A-Pfad für die Protokolldatei. Sie sind an einem hohen Durchsatz interessiert, nicht an einer niedrigen Latenz für ein Protokoll, um mit 1K-Einfügedaten pro Sekunde Schritt zu halten Strippen ist ein Muss.

Partitionierung und Seitenkomprimierung erfordern jeweils einen Enterprise Edition SQL Server, sie funktionieren nicht mit der Standard Edition und beide sind sehr wichtig um die Anforderungen zu erfüllen.

Als Nebenbemerkung, wenn die Datensätze von einer Front-End-Webserver-Farm stammen, würde ich Express auf jeden Webserver setzen und statt INSERT am Backend würde ich SEND die Informationen an das Back-End, mit einer lokalen Verbindung / Transaktion auf dem Express zusammen mit dem Webserver. Dies gibt der Lösung eine wesentlich bessere Verfügbarkeitsstory.

So würde ich es in SQL Server tun. Die gute Nachricht ist, dass die Probleme, mit denen Sie konfrontiert werden, gut verstanden werden und Lösungen bekannt sind. das bedeutet nicht unbedingt, dass dies besser ist als das, was Sie mit Cassandra, BigTable oder Dynamo erreichen können. Ich werde jemanden wissen lassen, der in Sachen no-sql-ish ist, um ihren Fall zu argumentieren.

Beachten Sie, dass ich nie das Programmiermodell, .Net-Unterstützung und so erwähnt habe. Ich denke wirklich, dass sie in großen Bereitstellungen irrelevant sind. Sie machen einen großen Unterschied im Entwicklungsprozess, aber sobald sie implementiert sind, spielt es keine Rolle, wie schnell die Entwicklung war, wenn der ORM-Overhead die Leistung zerstört :)


94
2018-05-08 17:27



Entgegen der landläufigen Meinung geht es bei NoSQL nicht um Leistung oder Skalierbarkeit. Es geht hauptsächlich darum, die sogenannte Objektrelationale Impedanz zu minimieren, aber es geht auch darum horizontal Skalierbarkeit gegenüber dem typischen vertikal Skalierbarkeit eines RDBMS.

Für die einfache Anforderung von Fast-Inserts und Fast-Lookups reicht fast jedes Datenbankprodukt aus. Wenn Sie relationale Daten oder Joins hinzufügen oder komplexe Transaktionslogik oder Constraints implementieren möchten, benötigen Sie eine relationale Datenbank. Kein NoSQL-Produkt kann vergleichen.

Wenn Sie schemalose Daten benötigen, sollten Sie eine dokumentenorientierte Datenbank wie MongoDB oder CouchDB verwenden. Das lose Schema ist das Hauptmerkmal von diesen; Ich persönlich mag MongoDB und verwende es in einigen benutzerdefinierten Berichtssystemen. Ich finde es sehr nützlich, wenn sich die Datenanforderungen ständig ändern.

Die andere Haupt-NoSQL-Option sind verteilte Key-Value-Stores wie BigTable oder Cassandra. Diese sind besonders nützlich, wenn Sie Ihre Datenbank auf viele Maschinen mit Standardhardware skalieren möchten. Sie funktionieren natürlich auch gut auf Servern, aber nutzen Sie nicht die High-End-Hardware sowie SQL Server oder Oracle oder andere für sie entwickelte Datenbanken vertikal Skalierung, und offensichtlich sind sie nicht relational und sind nicht gut für die Durchsetzung von Normalisierung oder Einschränkungen. Wie Sie vielleicht bemerkt haben, ist die .NET-Unterstützung bestenfalls spärlich.

Alle relationalen Datenbankprodukte unterstützen eine begrenzte Partitionierung. Sie sind nicht so flexibel wie BigTable oder andere DKVS-Systeme, sie lassen sich nicht leicht verteilen Hunderte von Servern, aber es klingt wirklich nicht so, wonach Sie suchen. Sie sind ziemlich gut im Umgang mit Rekordzahlen in Milliardenhöhe, solange Sie die Daten richtig indizieren und normalisieren, die Datenbank auf leistungsstarker Hardware (insbesondere SSDs, wenn Sie sie sich leisten können) ausführen und auf 2 oder 3 oder 5 physische Festplatten partitionieren notwendig.

Wenn Sie die oben genannten Kriterien erfüllen, wenn Sie in einer Unternehmensumgebung arbeiten und Geld für eine anständige Hardware- und Datenbankoptimierung ausgeben, würde ich vorerst bei SQL Server bleiben. Wenn Sie ein paar Cent verdienen und dies auf einer Low-End-Amazon EC2-Cloud-Computing-Hardware ausführen müssen, sollten Sie sich stattdessen für Cassandra oder Voldemort entscheiden (vorausgesetzt, Sie können entweder mit .NET arbeiten).


15
2018-05-08 17:25



Sehr wenige Leute arbeiten mit der Multi-Milliarden-Zeilensatzgröße, und die meisten Male, wenn ich eine Anforderung wie diese beim Stapelüberlauf sehe, sind die Daten nicht in der Nähe der Größe, für die sie gemeldet wird.

36 Milliarden, 3 Milliarden pro Monat, das sind ungefähr 100 Millionen pro Tag, 4,16 Millionen pro Stunde, ~ 70k Reihen pro Minute, 1,1k Zeilen pro Sekunde, die in das System eingespeist werden, in nachhaltiger Weise für 12 Monate, vorausgesetzt keine Ausfallzeit.

Diese Zahlen sind nicht mit großer Wahrscheinlichkeit nicht unmöglich, ich habe größere Systeme gemacht, aber Sie wollen überprüfen, dass das wirklich die Mengen ist, die Sie meinen - sehr wenige Apps haben wirklich diese Menge.

In Bezug auf das Speichern / Abrufen und einen ziemlich kritischen Aspekt, den Sie nicht erwähnt haben, ist das Altern der älteren Daten - die Löschung ist nicht kostenlos.

Die normale Technologie ist die Partitionierung, aber das Suchen / Abrufen, das auf GUID basiert, würde zu einer schlechten Leistung führen, vorausgesetzt, Sie müssen jeden passenden Wert über den gesamten Zeitraum von 12 Monaten erhalten. Sie könnten Clusterindizes auf die GUID-Spalte setzen, um die zugehörigen Daten für Lese- / Schreibzugriffe zu gruppieren, aber bei diesen Mengen und der Einfügegeschwindigkeit ist die Fragmentierung viel zu hoch, um sie zu unterstützen, und sie fällt auf den Boden.

Ich würde auch vorschlagen, dass Sie ein sehr anständiges Hardware-Budget benötigen, wenn dies eine ernsthafte Anwendung mit OLTP-Typ-Reaktionsgeschwindigkeiten ist, das ist durch einige ungefähre Schätzungen unter der Annahme, dass nur sehr wenige Gemeinkosten Indexierung, etwa 2,7 TB Daten.

Im SQL Server-Camp ist nur die neue Paralleldaten-Warehouse-Edition (madison) interessant, die mehr dazu dient, Daten auszusortieren und parallele Abfragen auszuführen, um eine hohe Geschwindigkeit gegen große Datamarts bereitzustellen.


11
2018-05-08 17:10



"Ich muss in der Lage sein, kleine Datenmengen (ungefähr 50-75 Bytes) für Milliarden von Datensätzen zu speichern (~ 3 Milliarden / Monat für ein Jahr).

Die einzige Voraussetzung sind schnelle Einfügungen und schnelle Suchvorgänge für alle Datensätze mit derselben GUID und die Möglichkeit, auf den Datenspeicher von .net zuzugreifen. "

Ich kann Ihnen aus Erfahrung sagen, dass dies in SQL Server möglich ist, weil ich es Anfang 2009 getan habe ... und es ist immer noch Betrieb bis heute und ziemlich schnell.

Die Tabelle wurde in 256 Partitionen partitioniert. Denken Sie daran, dass dies 2005 SQL-Version war ... und wir haben genau das gemacht, was Sie sagen, und das bedeutet, dass Sie Informationen per GUID speichern und schnell per GUID abrufen.

Als ich ging, hatten wir rund 2-3 Milliarden Datensätze, und die Datenwiederherstellung war immer noch ziemlich gut (1-2 Sekunden, wenn durch UI, oder weniger, wenn auf RDBMS), obwohl die Datenaufbewahrungsrichtlinie gerade instanziiert wurde.

Also, kurz gesagt, ich nahm das achte Zeichen (dh irgendwo in der Mitte-ish) aus der GUID-Zeichenfolge und SHA1 Hashed es und als winzige int (0-255) und in der entsprechenden Partition gespeichert und verwendet die gleiche Funktion aufrufen, wenn Sie die Daten zurück.

ping mich, wenn Sie mehr Informationen benötigen ...


2
2018-03-27 19:24



Es gibt eine ungewöhnliche Tatsache, die scheinbar übersehen wird.

"Grundsätzlich muss ich nach dem Einfügen von 30 Millionen Zeilen an einem Tag alle Zeilen mit der gleichen GUID (vielleicht 20 Zeilen) holen und ziemlich sicher sein, dass ich sie alle zurückbekomme"

Wenn nur 20 Spalten benötigt werden, funktioniert ein nicht gruppierter Index auf der GUID problemlos. Sie könnten eine weitere Spalte für die Datenverteilung über die Partitionen hinweg clustern.

Ich habe eine Frage bezüglich der Dateneingabe: Wie wird es eingefügt?

  • Ist dies eine Masseneinfügung nach einem bestimmten Zeitplan (pro Minute, pro Stunde usw.)?
  • Von welcher Quelle werden diese Daten bezogen (flache Dateien, OLTP usw.)?

Ich denke, dass diese beantwortet werden müssen, um die eine Seite der Gleichung zu verstehen.


1
2018-05-09 00:18



Der folgende Artikel beschreibt den Import und die Verwendung von a 16 Milliarde


1
2018-04-24 19:48



Amazon Redshift ist ein großartiger Service. Es war nicht verfügbar, als die Frage ursprünglich im Jahr 2010 veröffentlicht wurde, aber es ist jetzt ein wichtiger Akteur im Jahr 2017. Es ist eine spaltenbasierte Datenbank, die von Postgres gespeist wird, so dass standardmäßige SQL- und Postgres-Connector-Bibliotheken damit arbeiten.

Es wird am besten für Berichtszwecke verwendet, insbesondere für die Aggregation. Die Daten aus einer einzelnen Tabelle werden auf verschiedenen Servern in der Cloud von Amazon gespeichert, verteilt auf die definierten Tabellen-Distkeys, so dass Sie auf verteilte CPU-Leistung angewiesen sind.

So sind SELECTs und speziell aggregierte SELECTs blitzschnell. Das Laden großer Daten sollte vorzugsweise mit dem COPY-Befehl aus Amazon S3-CSV-Dateien erfolgen. Die Nachteile sind, dass DELETEs und UPDATEs langsamer als gewöhnlich sind, aber deshalb ist Redshift nicht primär eine transnationale Datenbank, sondern eher eine Data-Warehouse-Plattform.


0
2018-02-08 00:31