Bester Datenspeicher für Milliarden von Zeilen

Ich muss in der Lage sein, kleine Datenbits (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, über .net auf den Datenspeicher zuzugreifen.

Ich bin ein SQL Server-Typ und ich denke, SQL Server kann dies, aber bei all dem Gerede über BigTable, CouchDB und andere nosql-Lösungen klingt es immer mehr so, als wäre eine Alternative zu einem herkömmlichen RDBS aufgrund von Optimierungen für am besten verteilte Abfragen und Skalierung. Ich habe Cassandra ausprobiert und die .net-Bibliotheken werden derzeit nicht kompiliert oder können sich alle ändern (zusammen mit Cassandra selbst).

Ich habe viele verfügbare NOSQL-Datenspeicher untersucht, kann jedoch keinen finden, der meinen Anforderungen als robuste produktionsbereite Plattform entspricht.

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

Das Speichern von ~ 3,5 TB Daten und das Einfügen von ca. 1 KB / s rund um die Uhr sowie das Abfragen mit einer nicht angegebenen Rate ist mit SQL Server möglich, es gibt jedoch weitere Fragen:

• Welche Verfügbarkeitsanforderungen haben Sie dafür? 99,999% Betriebszeit oder sind 95% genug?
• Welche Zuverlässigkeitsanforderungen haben Sie? Kostet das Fehlen eines Einsatzes 1 Million US-Dollar?
• Welche Anforderungen an die Wiederherstellbarkeit haben Sie? Wenn Sie einen Tag Daten verlieren, spielt das eine Rolle?
• Welche Konsistenzanforderungen haben Sie? Muss garantiert werden, dass ein Schreibvorgang beim nächsten Lesevorgang sichtbar ist?

Wenn Sie all diese Anforderungen benötigen, die ich hervorgehoben habe, wird die von Ihnen vorgeschlagene Last Millionen an Hardware und Lizenzen auf einem relationalen System oder einem beliebigen System kosten, unabhängig davon, welche Spielereien Sie versuchen (Sharding, Partitionierung usw.). Ein nosql-System würde ihrer Definition nach nicht alle diese Anforderungen erfüllen.

Offensichtlich haben Sie einige dieser Anforderungen bereits gelockert. Es gibt eine schöne visuelle Anleitung, die die NOSQL-Angebote anhand des Paradigmas "Auswahl 2 aus 3" im Visual Guide für NoSQL-Systeme vergleicht :

Nach dem OP-Kommentar-Update

Mit SQL Server wäre dies eine einfache Implementierung:

• ein einzelner Tabellenclusterschlüssel (GUID, Zeit). Ja, wird bekommen fragmentiert , aber die Fragmentierung wirkt sich auf Read-Aheads aus, und Read-Aheads werden nur für signifikante Entfernungsscans benötigt. Da Sie nur nach einer bestimmten GUID und einem bestimmten Datumsbereich fragen, spielt die Fragmentierung keine große Rolle. Ja, ist ein breiter Schlüssel, daher haben Nicht-Blattseiten eine schlechte Schlüsseldichte. Ja, dies führt zu einem schlechten Füllfaktor. Und ja, es können Seitenteile auftreten. Trotz dieser Probleme ist es angesichts der Anforderungen immer noch die beste Wahl für Clusterschlüssel.
• Partitionieren Sie die Tabelle nach Zeit, damit Sie die abgelaufenen Datensätze über ein automatisches Schiebefenster effizient löschen können . Ergänzen Sie dies mit einer Neuerstellung der Online-Indexpartition des letzten Monats, um den durch das GUID-Clustering verursachten schlechten Füllfaktor und die Fragmentierung zu beseitigen.
• Aktivieren Sie die Seitenkomprimierung. Da die Schlüsselgruppen zuerst nach GUID gruppiert werden, befinden sich alle Datensätze einer GUID nebeneinander, wodurch eine Seitenkomprimierung erfolgt eine gute Chance für die Bereitstellung der Wörterbuchkomprimierung .
• Sie benötigen einen schnellen E / A-Pfad für die Protokolldatei. Sie sind an einem hohen Durchsatz interessiert, nicht an einer geringen Latenz, damit ein Protokoll mit 1K-Einfügungen / Sek. Schritt hält. Daher ist das Entfernen ein Muss.

Für die Partitionierung und Seitenkomprimierung ist jeweils ein Enterprise Edition SQL Server erforderlich. Sie funktionieren nicht mit der Standard Edition und beide sind sehr wichtig, um die Anforderungen zu erfüllen.

Als Randnotiz: Wenn die Datensätze von einer Front-End-Webserverfarm stammen, würde ich Express auf jeden Webserver setzen und anstelle von INSERT im Back-End SENDdie Informationen über eine lokale Verbindung / Transaktion an das Back-End senden auf dem Express zusammen mit dem Webserver. Dies gibt der Lösung eine viel bessere Verfügbarkeitsgeschichte.

So würde ich es in SQL Server machen. Die gute Nachricht ist, dass die Probleme, mit denen Sie konfrontiert werden, gut verstanden 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, der sich mit Dingen auskennt, die nicht mit SQL zu tun haben, besser über seinen Fall streiten.

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

Entgegen der landläufigen Meinung geht es bei NoSQL nicht um Leistung oder gar Skalierbarkeit. Es geht hauptsächlich um die Minimierung der sogenannten objektrelationalen Impedanzfehlanpassung, aber auch um die horizontale Skalierbarkeit im Vergleich zur typischeren vertikalen Skalierbarkeit eines RDBMS.

Für die einfache Anforderung von Fasteneinfügungen und schnellen Suchvorgängen ist fast jedes Datenbankprodukt geeignet. Wenn Sie relationale Daten oder Verknüpfungen hinzufügen möchten oder komplexe Transaktionslogik oder Einschränkungen haben, die Sie erzwingen müssen, möchten Sie eine relationale Datenbank. Kein NoSQL-Produkt kann es vergleichen.

Wenn Sie schemenlose Daten benötigen, sollten Sie eine dokumentorientierte Datenbank wie MongoDB oder CouchDB verwenden. Das lose Schema ist die Hauptattraktion 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 Hauptoption von NoSQL sind verteilte Schlüsselwertspeicher wie BigTable oder Cassandra. Diese sind besonders nützlich, wenn Sie Ihre Datenbank auf viele Computer skalieren möchten, auf denen Standardhardware ausgeführt wird. Sie funktionieren natürlich auch auf Servern einwandfrei, nutzen jedoch nicht die High-End-Hardware sowie SQL Server oder Oracle oder eine andere Datenbank, für die sie entwickelt wurden vertikale Skalierung entwickelt wurden. Offensichtlich sind sie nicht relational und eignen sich nicht zur Durchsetzung der Normalisierung oder Einschränkungen. Wie Sie bereits bemerkt haben, ist die .NET-Unterstützung bestenfalls fleckig.

Alle relationalen Datenbankprodukte unterstützen eine begrenzte Partitionierung. Sie sind nicht so flexibel wie BigTable oder andere DKVS-Systeme, sie lassen sich nicht einfach auf Hunderte verteilen von Servern , aber es hört sich wirklich nicht so an, als ob Sie danach suchen. Sie sind ziemlich gut darin, die Anzahl der Datensätze in Milliardenhöhe zu verarbeiten, solange Sie die Daten ordnungsgemäß indizieren und normalisieren, die Datenbank auf leistungsstarker Hardware (insbesondere SSDs, wenn Sie sie sich leisten können) ausführen und auf 2, 3 oder 5 physischen Festplatten partitionieren, wenn notwendig.

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

Sehr wenige Leute arbeiten mit der eingestellten Größe von mehreren Milliarden Zeilen. In den meisten Fällen, in denen ich eine solche Anforderung beim Stapelüberlauf sehe, sind die Daten nicht annähernd so groß wie die Größe, als die sie gemeldet werden.

36 Milliarden, 3 Milliarden pro Monat, das sind ungefähr 100 Millionen pro Tag, 4,16 Millionen pro Stunde, ~ 70.000 Zeilen pro Minute, 1,1.000 Zeilen pro Sekunde, die 12 Monate lang nachhaltig in das System gelangen, ohne Ausfallzeiten.

Diese Zahlen sind bei weitem nicht unmöglich, ich habe größere Systeme erstellt, aber Sie möchten überprüfen, ob dies wirklich die Mengen sind, die Sie meinen - nur sehr wenige Apps haben diese Menge wirklich.

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

Die normale Technologie ist die Partitionierung. Das Suchen / Abrufen auf GUID-Basis würde jedoch zu einer schlechten Leistung führen, vorausgesetzt, Sie müssen jeden übereinstimmenden Wert über den gesamten Zeitraum von 12 Monaten erhalten. Sie könnten einen Clustered-Index in die GUID-Spalte einfügen, um die zugehörigen Datencluster zum Lesen / Schreiben zu erhalten. Bei diesen Mengen und der Einfügegeschwindigkeit ist die Fragmentierung jedoch 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 es sich um eine seriöse Anwendung mit Antwortgeschwindigkeiten vom Typ OLTP handelt, dh nach ungefähren Schätzungen, bei der nur sehr wenige Overheads für die Indizierung von etwa 2,7 TB Daten angenommen werden.

Im SQL Server-Camp sollten Sie sich nur die neue parallele Data Warehouse-Edition (Madison) ansehen, die eher zum Sharding von Daten und zum Ausführen paralleler Abfragen entwickelt wurde, um eine hohe Geschwindigkeit für große Datamarts zu erzielen.

"Ich muss in der Lage sein, kleine Datenbits (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, über .net auf den Datenspeicher 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 bis heute in Betrieb und ziemlich schnell.

Die Tabelle wurde in 256 Partitionen partitioniert. Beachten Sie, dass dies die SQL-Version von 2005 war. Wir haben genau das getan, was Sie sagen. Das heißt, Informationen werden nach GUID gespeichert und schnell nach GUID abgerufen.

Als ich ging, hatten wir ungefähr 2-3 Milliarden Datensätze, und der Datenabruf war immer noch recht gut (1-2 Sekunden, wenn Sie über die Benutzeroberfläche kommen, oder weniger, wenn Sie RDBMS verwenden), obwohl die Richtlinie zur Vorratsdatenspeicherung gerade instanziiert werden sollte.

Kurz gesagt, ich habe das 8. Zeichen (dh irgendwo in der Mitte) aus der GUID-Zeichenfolge genommen und SHA1 hat es gehasht und als winziges int (0-255) umgewandelt und in einer geeigneten Partition gespeichert und beim Abrufen denselben Funktionsaufruf verwendet die Daten zurück.

Pingen Sie mich an, wenn Sie weitere Informationen benötigen ...

Der folgende Artikel beschreibt den Import und die Verwendung einer 16- Milliarden- Zeilentabelle in Microsoft SQL. http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table .

Aus dem Artikel:

Hier sind einige destillierte Tipps aus meiner Erfahrung:

• Je mehr Daten Sie in einer Tabelle mit einem definierten Clustered-Index haben, desto langsamer wird es, unsortierte Datensätze in diese Tabelle zu importieren. Irgendwann wird es zu langsam, um praktisch zu sein.
• Wenn Sie Ihre Tabelle in die kleinstmögliche Datei exportieren möchten, legen Sie das native Format fest. Dies funktioniert am besten mit Tabellen, die hauptsächlich numerische Spalten enthalten, da sie in Binärfeldern kompakter dargestellt werden als Zeichendaten. Wenn alle Ihre Daten alphanumerisch sind, werden Sie nicht viel gewinnen, wenn Sie sie im nativen Format exportieren. Wenn in den numerischen Feldern keine Nullen zugelassen werden, können die Daten weiter komprimiert werden. Wenn Sie zulassen, dass ein Feld nullwertfähig ist, enthält die Binärdarstellung des Felds ein 1-Byte-Präfix, das angibt, wie viele Datenbytes folgen werden.
• Sie können BCP nicht für mehr als 2.147.483.647 Datensätze verwenden, da die BCP-Zählervariable eine 4-Byte-Ganzzahl ist. Ich konnte auf MSDN oder im Internet keinen Hinweis darauf finden. Wenn Ihre Tabelle aus
  mehr als 2.147.483.647 Datensätzen besteht, müssen Sie sie in Blöcken exportieren
  oder Ihre eigene Exportroutine schreiben.
• Das Definieren eines Clustered-Index für eine vorab ausgefüllte Tabelle beansprucht viel Speicherplatz. In meinem Test explodierte mein Protokoll
  vor Abschluss auf das Zehnfache der ursprünglichen Tabellengröße.
• Fügen Sie beim Importieren einer großen Anzahl von Datensätzen mit der Anweisung BULK INSERT den Parameter BATCHSIZE ein und geben Sie an, wie viele
  Datensätze gleichzeitig festgeschrieben werden sollen . Wenn Sie diesen Parameter nicht angeben, wird
  Ihre gesamte Datei als einzelne Transaktion importiert, was
  viel Protokollspeicherplatz erfordert.
• Der schnellste Weg, Daten in eine Tabelle mit einem Clustered-Index zu übertragen, besteht darin, die Daten zuerst vorzusortieren. Sie können es dann mit der Anweisung BULK
  INSERT mit dem Parameter ORDER importieren .

Es gibt eine ungewöhnliche Tatsache, die übersehen zu werden scheint.

" Grundsätzlich muss ich nach dem Einfügen von 30Mil-Zeilen an einem Tag alle Zeilen mit derselben GUID (möglicherweise 20 Zeilen) abrufen und ziemlich sicher sein, dass ich sie alle zurückerhalte. "

Da nur 20 Spalten benötigt werden, funktioniert ein nicht gruppierter Index für die GUID einwandfrei. Sie können für die Datenverteilung über Partitionen in einer anderen Spalte gruppieren.

Ich habe eine Frage zur Dateneinfügung: Wie wird sie eingefügt?

• Handelt es sich um einen Masseneinsatz nach einem bestimmten Zeitplan (pro Minute, pro Stunde usw.)?
• Aus welcher Quelle werden diese Daten abgerufen (Flatfiles, OLTP usw.)?

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

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 handelt sich um eine spaltenbasierte Datenbank, die von Postgres gespalten wurde, sodass Standard-SQL- und Postgres-Connector-Bibliotheken damit funktionieren.

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

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

Sie können versuchen, Cassandra oder HBase zu verwenden, müssen sich jedoch darüber informieren, wie Sie die Spaltenfamilien gemäß Ihrem Anwendungsfall entwerfen. Cassandra bietet eine eigene Abfragesprache, Sie müssen jedoch Java-APIs von HBase verwenden, um direkt auf die Daten zugreifen zu können. Wenn Sie Hbase verwenden müssen, empfehle ich, die Daten mit Apache Drill von Map-R abzufragen, einem Open Source-Projekt. Die Abfragesprache von Drill ist SQL-kompatibel (Schlüsselwörter in Drill haben dieselbe Bedeutung wie in SQL).

Mit so vielen Datensätzen pro Jahr wird Ihnen irgendwann der Platz ausgehen. Warum nicht Dateisystemspeicher wie xfs, der 2 ^ 64 Dateien unterstützt und kleinere Boxen verwendet? Unabhängig davon, wie ausgefallen die Leute sein wollen oder wie viel Geld man am Ende ausgeben würde, um ein System mit einer beliebigen Datenbank SQL NoSQL zu bekommen. Diese vielen Aufzeichnungen werden normalerweise von Elektrizitätsunternehmen und Wetterstationen / -anbietern wie dem Umweltministerium gemacht, die kleinere kontrollieren Stationen im ganzen Land. Wenn Sie so etwas wie Druck speichern ... Temperatur ... Windgeschwindigkeit ... Luftfeuchtigkeit usw. ... und Guid ist der Ort ... können Sie die Daten immer noch durch Jahr / Monat / Tag / Stunde teilen. Angenommen, Sie speichern 4 Jahre Daten pro Festplatte. Sie können es dann auf einem kleineren Nas mit Spiegel laufen lassen, wo es auch bessere Lesegeschwindigkeiten und mehrere Einhängepunkte bietet. basierend auf dem Jahr, in dem es erstellt wurde. Sie können einfach ein Webinterface für Suchvorgänge erstellen. So Dumping location1 / 2001/06/01 // Temperatur und Standort1 / 2002/06/01 // Temperatur würde nur den Inhalt der Stundentemperatur für den 1. Sommertag in diesen 2 Jahren (24h * 2) 48 kleinen Dateien ausgeben, anstatt eine Datenbank mit Milliarden von Datensätzen und möglicherweise Millionen ausgegebener Daten zu durchsuchen. Einfache Art, Dinge zu betrachten. 1,5 Milliarden Websites auf der Welt mit Gott weiß, wie viele Seiten jeder hat. Wenn ein Unternehmen wie Google Millionen pro 3 Milliarden Suchanfragen ausgeben müsste, um Supercomputer dafür zu bezahlen, wären sie pleite. Stattdessen haben sie die Stromrechnung ... ein paar Millionen Mistcomputer. Und Koffeinindizierung ... zukunftssicher ... mehr hinzufügen. Und ja, wo die Indizierung unter SQL Sinn macht, ist es großartig, Supercomputer für beschissene Aufgaben mit festen Dingen wie Wetter zu bauen ... Statistiken und so weiter, damit Techniker damit prahlen können, dass ihre Systeme in x Sekunden xtb knirschen ... Geldverschwendung, die sein kann woanders verbracht ..

Das Speichern von Datensätzen in einfachen Binärdateien, eine Datei pro GUID, würde nicht schneller sein.

Sie können MongoDB verwenden und die Guid als Sharding-Schlüssel verwenden. Dies bedeutet, dass Sie Ihre Daten auf mehrere Computer verteilen können. Die Daten, die Sie auswählen möchten, befinden sich jedoch nur auf einem Computer, da Sie sie mit dem Sharding-Schlüssel auswählen.

Sharding in MongoDb ist noch nicht produktionsbereit.