Welche NoSQL-Datenbank hauptsächlich zum Schreiben

Question

Ich arbeite an einem System, das große Mengen von Daten auf der Festplatte generieren und speichern wird. Ein früher entwickeltes System im Unternehmen verwendete gewöhnliche Dateien, um seine Daten zu speichern, aber aus verschiedenen Gründen wurde es sehr schwer zu verwalten.

Ich glaube, NoSQL-Datenbanken sind gute Lösungen für uns. Was wir speichern werden, sind in der Regel Dokumente (in der Regel um 100K, aber gelegentlich können viel größer oder kleiner sein) mit einigen Metadaten kommentiert. Die Abfrageleistung hat nicht die höchste Priorität. Die Priorität besteht darin, auf eine Art und Weise zu schreiben, dass E/A so klein wie möglich wird. Die Rate der Datengenerierung beträgt etwa 1 Gbit/s, aber in Zukunft könnten wir 10 Gbit/s (oder sogar mehr) erreichen.

Meine andere Voraussetzung ist die Verfügbarkeit einer (vorzugsweise gut dokumentierten) C-API. Ich teste gerade MongoDB. Ist das eine gute Wahl? Wenn nicht, welches andere Datenbanksystem kann ich verwenden?

Answer 1

Die Rate der Datengenerierung beträgt etwa 1 Gbps, ... Ich teste gerade MongoDB. Ist das eine gute Wahl?

OK, um nur zu verdeutlichen, ist Ihre Datenrate ~ 1 Gigabyte pro 10 Sekunden. Sie füllen also alle 20 Minuten eine 1-TB-Festplatte?

MongoDB hat ziemlich solide Schreibraten, aber es wird idealerweise in Situationen mit einem relativ niedrigen RAM-zu-Data-Verhältnis verwendet. Sie möchten mindestens primäre Indizes im Speicher zusammen mit einigen Daten beibehalten.

Meiner Erfahrung nach wollen Sie etwa 1 GB RAM für jede 5-10 GB Daten. Darüber hinaus sinkt die Leseleistung dramatisch. Sobald Sie 1 GB RAM für 100 GB Daten erhalten, kann das Hinzufügen neuer Daten langsam sein, da der Index nicht mehr in den Arbeitsspeicher passt.

Der große Schlüssel hier ist:

Welche Anfragen planen Sie laufen und wie MongoDB machen diese Abfragen ausgeführt wird einfacher?

Ihre Daten werden sehr schnell genug Platz einnehmen, dass im Grunde jede Anfrage nur auf die Festplatte gehen wird. Wenn Sie nicht eine sehr spezielle Indexierungs- und Sharding-Strategie haben, werden Sie am Ende nur Disk-Scans durchführen.

Darüber hinaus unterstützt MongoDB keine Komprimierung. Sie werden also viel Speicherplatz belegen.

Wenn nicht, welches andere Datenbanksystem kann ich verwenden?

Haben Sie komprimierte Flat Files berücksichtigt? Oder vielleicht ein großes Daten Map/Reduce-System wie Hadoop (Ich weiß Hadoop in Java geschrieben ist)

Wenn C wesentliche Voraussetzung ist, vielleicht wollen Sie bei Tokyo/Kyoto Cabinet aussehen?

---

EDIT: mehr Details

MongoDB nicht Unterstützung Volltextsuche. Für solche Dinge müssen Sie nach anderen Tools (Sphinx/Solr) suchen.

Große Indizes besiegen den Zweck der Verwendung eines Index.

Entsprechend Ihrer Zahlen schreiben Sie 10M Dokumente/20 Minuten oder ungefähr 30M/hour. Jedes Dokument benötigt etwa 16 Bytes für einen Indexeintrag. 12 Bytes für ObjectID + 4 Bytes für den Zeiger in die 2GB-Datei + 1 Byte für den Zeiger auf die Datei + etwas Polsterung.

Angenommen, jeder Indexeintrag benötigt etwa 20 Byte, dann wächst der Index um 600 MB/Stunde oder 14,4 GB/Tag. Und das ist nur der Standard _id Index.

Nach 4 Tagen wird Ihr Hauptindex nicht mehr in den Arbeitsspeicher passen und Ihre Leistung wird dramatisch abfallen. (ist dies gut dokumentiert unter MongoDB)

So wird es wirklich wichtig sein, herauszufinden, welche Abfragen Sie ausführen möchten.

Answer 2

Werfen Sie einen Blick auf Cassandra. Es führt Schreibvorgänge sind viel schneller als liest. Wahrscheinlich suchst du das.