Terabyte-Datensatz

Ich habe das Gefühl, dass die meisten Datenbanksysteme aus den 80er Jahren stammen und Tabellen, ACID-Transaktionen und Einschränkungen stereotyp implementieren. Sie wurden unter Berücksichtigung der Verknappung von Speicher, Festplatte und Rechenleistung gebaut.

Ich frage mich, ob es ein Speichersystem gibt (das nicht unbedingt über SQL zugänglich ist), das Folgendes verarbeiten kann:

Diagramme (Abfrage a la SPARQL).
Matrix (n-dimensional) ebenfalls spärlich. Unterstützung von Trivial-Matrix-Algorithmen wie SVD, Clustering.
effiziente Verwaltung großer Datenmengen (Terabyte), die sich nicht kontinuierlich ändern; Die Änderung erfolgt durch tägliche Chargen.
Verwenden Sie große Festplattensysteme (14 TB RAID5 kosten heute weniger als 1500 US-Dollar). Dies bedeutet mehr Platz für Indizes, vorberechnete Ergebnisse usw.
Verwenden Sie GPU / mehrere Kerne / Prozessoren / Knoten für eine große Abfrage und Indizierung.

Ich weiß, dass die meisten Elemente irgendwo implementiert sind (Apache Cassandra, SPARQL, Netezza, Exadata), aber ich kenne kein Produkt, das möglicherweise alle implementiert.

performance graph

— Razvan Popovici
quelle

Ich denke, viele dieser Dinge stehen sehr am Horizont (oder darüber hinaus).

SPARQL zum Beispiel ist etwas, das ich nicht in Kürze in Datenbanken sehen kann. Das nächste, das ich gesehen habe, ist SDB , eine Schnittstelle, die SPARQL verarbeitet und an eine Standarddatenbank sendet.

Auch die Verwendung von GPUs als generische Prozessoren ist immer noch eine revolutionäre Sache. Es hat sich in der Datenbankwelt nicht ganz durchgesetzt. Zu diesem Zeitpunkt befindet es sich noch in der Welt der Wissenschaft und Theorie.

Es gibt nur eine Gruppe (die ich finden konnte), die eine Datenbank entwickelt, um die GPU zu nutzen. Alenka ist ein Open-Source-Projekt, aber es befindet sich noch in der Entwicklung.

Außerdem gibt es einen neuen Sortieralgorithmus namens GPUTeraSort am Horizont. Aber (als Algorithmus) kenne ich derzeit keine spezifischen Datenbanken, die ihn verwenden.

Schließlich gibt es eine Site, GPGPU , für die allgemeine Datenverarbeitung auf GPUs, die Sie möglicherweise im Auge behalten möchten. Wenn Datenbanken entstehen, die die GPU verwenden, ist dies die Site, die sie meldet.

Trotzdem ist die Verwendung mehrerer Kerne oder mehrerer Prozessoren fast der Status Quo. SQL Server, MySQL, Oracle - Alle wichtigen Datenbanken verwenden Multithreading.

Letztendlich sind die Elemente, nach denen Sie fragen, etwas, das derzeit weit über die Datenbankwelt hinausgeht.

Sie können auch versuchen, dies auf StackOverflow zu veröffentlichen, da sie möglicherweise einige Ideen zum Umgang mit Daten auf Terabyte-Ebene mithilfe von Diagrammen, SPARQL, GPU-Verbesserungen usw. haben. Ihre Antwort lautet jedoch wahrscheinlich "Ja" Sie können es tun, aber es wäre ein riesiges maßgeschneidertes System. "

— Richard
quelle

Vielen Dank für die GPU-Analyse, mir war Alenka nicht bekannt. Ich denke darüber nach, eine solche Speicher-Engine zu entwickeln. Der Grund, den ich gefragt habe, war, dass ich mich irgendwie vom Rest der Welt entfremdet fühlte. Die wichtigsten Datenbanken verwenden zwar Multithreading, können jedoch nicht mehr als einen Thread zum Erstellen eines Index oder zum Beantworten einer einzelnen Abfrage verwenden. Liege ich falsch? Ich stelle mir auch vor, Diagramme mit Tabellen in derselben Abfrage zu kombinieren, z. B. "Wählen Sie den Benutzer aus, der einen Server gekauft hat und einen Benutzer hat, der ein Tablet gekauft hat". Fof = Freund eines Freundes, auch mit mehreren Schleifen. Gekaufte Artikel befinden sich in einer Tabelle, während sich die Beziehung in einem Diagramm befindet.

— Razvan Popovici

Es ist möglich, mehrere Threads für dieselbe Abfrage zu verwenden, vorausgesetzt, die Abfrage ist ausreichend komplex. Ich kenne keine Datenbanken, die mehrere Threads für denselben Aspekt einer Abfrage verwenden. Es wäre beispielsweise möglich, einen Tabellenscan auseinanderzubrechen, dies jedoch nicht mit einer Nestschleife. Ob es Datenbanken gibt, die Abfragen in mehrere Threads aufteilen, ist eine andere Frage.

— Richard

Was das "Diagramm" betrifft, klingt das nach etwas, das in SQL ausgeführt werden könnte, obwohl es möglicherweise nicht so einfach ist wie in anderen Sprachen. (Ich konnte nicht sicher sagen.)

— Richard