NoSQL Datenbank gesucht

[darton]

Hallo!
Ich benötige für ein Projekt etwas Hilfe beim Suchen einer geeigneten Datenbank. Die Datenbank muss wirklich sehr viele Datensätze aufnehmen können. Jede Sekunde erhält sie etwa 100 neue Einträge und in etwa dieselbe Menge muss auch pro Sekunde ausgelesen werden. Außerdem müssen die Daten der letzten 20 Jahre übernommen werden (sekündlich!), d.h. das sind so 63 Milliarden Einträge. Ein Eintrag hat in etwa die Form (Name, Wert, Uhrzeit). Es müssen nur ganz simple Abfragen möglich sein, z.B. sowas wie "Gib mir den Eintrag zu dem Namen X zur Uhrzeit Y" und es wäre ganz gut, wenn man die Datenbank auf mehreren Servern verteilen kann. Außerdem sollte sie jederzeit konsistent sein.
Aufgrund dieses riesen Datenvolumens dachte ich mir, dass eine NoSQL Datenbank dafür ganz gut geeignet wäre. Ich konnte leider im Netz nicht so viel dazu rausfinden, zu welchen Abfragen die ganzen NoSQL Datenbank fähig sind. Hat jemand vielleicht schon Erfahrungen gemacht mit Datenbanken wie HBase, Redis, Cassandra etc. und kann mir für mein Vorhaben eine empfehlen?

 

[sasdensas]

Naja, wenn es konsistent sein soll, bringt Dir eine NoSQL leider wenig. Dafür brauchste ein klassisches RDMS, wie Oracle, MS SQL oder MySQL. Je nach Maschine dürften die 100, bzw. 200 Querys wenig Probleme bereiten. Wenns als Batch eingelesen wird, umso besser.

 

[darton]

Also HBase arbeitet z.B. konsistent und ich meine HyperTable auch.

 

[ice-breaker]

Das mag stimmen aber du hast keine Anforderung, die ein RDBMS nicht erfüllt. Und vergiss nicht, die aktuellen RDBMS werden seit Jahrzehnten gepflegt, erweitert und optimiert. Du wirst also in Punkto Performance (was scheinbar dein Anliegen ist) mit einem RDBMS das Produkt mit der längsten Reife haben.

Redis mit einem SortedSet auf einem Key würde sich auch anbieten, ich bezweifle aber dass du genügend Ram dafür haben wirst, einfach die Daten auf Server verteilen geht da auch (noch) nicht.


Also mal Tacheles: NoSQL-Datenbanken erfüllen natürlich einen Zweck, sind auch teilweise ein sinnvollerer Ersatz für ein RDBMs aber es so über das Knie zu brechen, wie du es tust ist absolut sinnlos. Keine NoSQL-Datenbank hat für deinen Anwendungszweck einen wirklichen Vorteil.

 

[BuzzGo]

Redis als Key-Value NoSQL oder CouchDB. Damit das ganze auf Hightraffic-Seiten optimal läuft, empfehle ich entsprechend noch node.js als I/O Framework. Wenn es Dir wirklich auf Konsistenz ankommt, dann nützen dir AP-Systeme wie CouchDB wenig, dann solltest du auf HBase (CP-System) setzen.

 

[darton]

Haben eigentlich SQL-Datenbanken sowas wie eine Versionierung? Sowas gibt es ja bei manchen NoSQL Datenbanken, also dass die Tabelle quasi dreidimensional ist und die Dimension in die Tiefe speichert die ganzen Versionen von den Einträgen.

 

[ice-breaker]

Eine NoSQL-Datenbank kann das auch nicht automatisch durch schwarze Magie sondern hat dies modelliert, und das Gleiche kannst du bei einem RDBMs auch.

 

[darton]

@ice-breaker
Du meinst dann also, wenn die Daten, die man speichern möchte, eigentlich gut in ein relationales Schema passen, sollte man lieber bei MySQL bleiben? Egal wie groß die Datenmenge ist? Weil NoSQL Datenbanken ja angeblich immer genau mit hoher Performance bei sehr großen Datenmengen punkten.

 

[ice-breaker]

Nein das habe ich nicht gesagt
Ich habe nur gesagt, du solltest dir überlegen, ob es wirklich eine NoSQL-Datenbank sein muss, ich sehe da keine Anforderung die es zwingend notwendig macht. Zumal mit jeder weiteren Software natürlich noch Aufwand verbunden ist, du musst die Software konfigurieren, updaten und und. Und natürlich musst du dich auch noch sehr genau mit der Funktionsweise beschäftigen, denn auf magische Weise haben diese nicht die hohe Performance von Benchmarks, sondern weil das Problem perfekt darauf modelliert wurde.

Und wenn es dir einfach nur darum geht mit Performance-Zahlen um dich zu werfen, dann schau dir HandlerSocket an, ein Plugin für MySQL. Hat ohne Probleme die gleiche Performance wie NoSQL-Datenbanken und bietet dir zugleich alle Vorteile einer relationalen Datenbank, da es auf InnoDB basiert.
"HandlerSocket" ist so gesehen eine NoSQL-"Datenbank", da du damit die ganze SQL-Geschichte von MySQL umgehst und genauso limitierend auf die Daten zugreifst wie NoSQL-Datenbanken (keine Gruppierungen, keine Joins usw.) mit aber dem entscheidenden Vorteil, dass du auf 2 Produkte setzt die Jahre lang reiften und optimiert wurden: MySQL und die InnoDB-Engine.

 

[Daaron]

MySQL hat ein monströses Manko: Die doch recht eng limitierte Spaltenzahl.
Wenn man davon ausgehen muss, dass die breiteste Tabelle wirklich ein Monster wird, dann ist MySQL (oder MariaDB, der modernere MySQL-Ableger) einfach überfordert. Dann wäre z.B. PostgreSQL die bessere Wahl.

 

[sasdensas]

Was hat denn die Spaltenlimitierung mit dem Problem des TE zu tun? Da ist die Rede von 3 Spalten!

@TE: Programmier doch einfach mal ne Anwendung quick & dirty z.B. in Java inkl. Hibernate, und benche mit der Applikation alle DBMS, die für Dich in Frage kommen. Dann nimmste einfach das, was am besten läuft.

Quasi 2-3 Applikationen:
1x DB-Writer, was in ner Endlos-Schleife, bzw. auf z.B. 500 Queries beschränkt, Daten (Random) in DB reinschaufelt
1x DB-Reader, was dann parallel die Daten aus der DB zieht
1x Stichprobentest, also die Abfragen, die Du in etwa brauchst.

Machste dann mit Oracle XE, MySQL, irgendwelchen NoSQL-Engines, etc..

 

[thometal]

http://www.orientechnologies.com/orient-db.htm

probiers mal damit ist eine documenten store sowie eine graphdb, sql like abfragen möglich sowie transaktionen, sollte alles bieten was du brauchst.

 

[ice-breaker]

@sasdenas: Das Problem dabei ist aber das er einige Datenbanken nutzen wird ohne sie genauer zu kennen und dabei ggf. auch typische Fehler macht, oder er die Datenbanken verschieden konfiguriert ( Persistence-Modi) und dadurch komplett falsche Ergebnisse erzielt und seine Entscheidung auf falsche Benchmarks stützt: Es gibt im Netz mehr als genug Beispiele für absolut misslungene Benchmarks.

 

[darton]

Die Anforderungen haben sie mittlerweile ein wenig geändert.
Ich sagte ja im Anfangsposting, dass ein Eintrag die Form (Name, Wert, Uhrzeit) hat. In Wert steht immer eine Zahl. Die Datenbank müsste zusätzlich sowas können wie den Durchschnitt der letzten zehn Jahre von diesen Zahlen zu berechnen. Da die Einträge ja sekündlich abgelegt werden, sind das schon einige 100 Millionen Werte, von denen der Durchschnitt berechnet werden sollte. In diesem Fall bietet es sich ja an, eine spaltenorientierte NoSQL Datenbank zu benutzen, die die Last auch auf mehrere Server verteilen kann. Oder meint ihr etwa nicht?

 

[ice-breaker]

In diesem Fall bietet es sich ja an, eine spaltenorientierte NoSQL Datenbank zu benutzen, die die Last auch auf mehrere Server verteilen kann. Oder meint ihr etwa nicht?

Oder gar ein Hadoop-Cluster.
Oder man stellst sich beim Modellieren nicht so dämlich an und speichert voraggregierte Werte für einen Zeitraum (Summe und Anzahl) für Tage, Monate, Jahre usw.



Ich bleibe trotzdem bei meiner Aussage, du hast gar keine Ahnung was du wirklich brauchst und scheinst einfach so auf dem Bauch heraus nach irgendwelchen Buzzwords zu entscheiden. Das nennt man dann auch Bullshit-Bingo...