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?
quelle
Antworten:
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:
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:
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
SEND
die 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 :)
quelle
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).
quelle
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.
quelle
"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 ...
quelle
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:
quelle
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?
Ich denke, diese müssen beantwortet werden, um eine Seite der Gleichung zu verstehen.
quelle
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.
quelle
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).
quelle
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 ..
quelle
Das Speichern von Datensätzen in einfachen Binärdateien, eine Datei pro GUID, würde nicht schneller sein.
quelle
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.
quelle