BerkeleyDB schreibt Leistungsprobleme

Ich brauche einen plattenbasierten Schlüsselwertspeicher, der hohe Schreib- und Leseleistung für große Datenmengen aufrechterhalten kann. Großartige Bestellung, ich weiß.

Ich probiere die C BerkeleyDB (5.1.25) -Bibliothek von Java und sehe ernsthafte Leistungsprobleme.

Ich bekomme für kurze Zeit solide 14K Dokumente / s, aber sobald ich ein paar hunderttausend Dokumente erreiche, fällt die Leistung wie ein Stein, dann erholt sie sich für eine Weile, fällt dann wieder ab usw. Das passiert mehr und häufiger, bis zu dem Punkt, an dem ich nicht mehr als 60 Dokumente / s mit vereinzelten Spitzen von 12 KByte / s nach 10 Mio. Dokumenten erreichen kann. Mein DB-Typ der Wahl ist HASH, aber ich habe auch BTREE versucht und es ist das gleiche.

Ich habe versucht, einen Pool von 10 db's zu verwenden und die Dokumente unter ihnen zu hashen, um die Leistungseinbrüche auszugleichen; dies erhöhte den Schreibdurchsatz auf 50 KByte / s, half aber nicht bei den Leistungseinbrüchen: alle 10 Datenbänke verlangsamten sich gleichzeitig auf einen Crawl.

Ich nehme an, dass die Dateien reorganisiert werden, und ich habe versucht, einen config-Parameter zu finden, der beeinflusst, wann diese Reorganisation stattfindet, so dass jede der gepoolten dbs zu einem anderen Zeitpunkt reorganisiert, aber ich konnte nichts finden, was funktionierte . Ich probierte verschiedene Cachegrößen aus und reservierte Speicherplatz mit der Konfigurationsoption setHashNumElements, so dass es keine Zeit brauchte, die Datei zu vergrößern, aber jede Optimierung machte es viel schlimmer.

Ich gebe Berkeleydb auf und versuche viel komplexere Lösungen wie Cassandra, aber ich möchte sicherstellen, dass ich in Berkeleydb nichts falsch mache, bevor ich es absetze.

Jemand hier mit Erfahrung erreicht nachhaltige Schreibleistung mit berkeleydb?

Bearbeiten 1 :

Ich habe schon mehrere Dinge ausprobiert:

1. Drosselung der Schreibvorgänge auf 500 / s (weniger als der Durchschnitt, den ich nach dem Schreiben von 30 Millionen Dokumenten in 15 Stunden erreicht habe, was darauf hindeutet, dass die Hardware 550 Dokumente / s schreiben kann). Hat nicht funktioniert: Sobald eine bestimmte Anzahl von Dokumenten geschrieben wurde, sinkt die Leistung.
2. Schreiben Sie eingehende Nachrichten in eine Warteschlange. Dies hat zwei Probleme: A) Es vereitelt den Zweck, RAM zu befreien. B) Die Warteschlange blockiert möglicherweise, da die Zeiten, in denen BerkeleyDB einfriert, länger und häufiger werden.

Mit anderen Worten, selbst wenn ich die eingehenden Daten drossle, um unter der Hardwarefähigkeit zu bleiben und ram zum Halten von Objekten zu verwenden, während BerkeleyDB einige Zeit benötigt, um sich an das Wachstum anzupassen, nähert sich die Leistung langsam an, da sich die Performance 0 nähert. p>

Das überrascht mich, weil ich behauptet habe, dass es Terabytes an Daten verarbeiten kann, aber meine Tests zeigen etwas anderes. Ich hoffe immer noch, dass ich etwas falsch mache ...

Bearbeiten 2 :

Nach einigem Nachdenken und mit Peters Input verstehe ich jetzt, dass, wenn die Datei größer wird, ein Stapel Schreibvorgänge weiter auseinander breitet und die Wahrscheinlichkeit, dass sie in den gleichen Plattenzylinder fallen, sinkt, bis sie schließlich erreicht die Suche / zweite Begrenzung der Festplatte.

Aber die periodischen Dateireorganisationen von BerkeleyDB bringen die Performance viel früher zum Erliegen, und auf eine noch viel schlimmere Art und Weise: Sie reagiert einfach nicht mehr für immer längere Zeit, während sie Dinge herumschiebt. Die Verwendung schnellerer Datenträger oder die Verteilung der Datenbankdateien auf verschiedene Datenträger hilft nicht. Ich muss einen Weg finden, diese Durchsatzlöcher zu umgehen.