Wahl zwischen Berkeley DB Core und Berkeley DB JE

Question

Ich entwerfe eine Java-basierte Web-App und brauche einen Schlüsselwertgeschäft. Berkeley DB scheint für mich passend genug zu sein, aber es scheint zwei Berkeley DBS zu geben: Berkeley DB Core, der in C implementiert ist, und die Berkeley DB Java Edition, die in Pure Java implementiert ist.

Die Frage ist, wie Sie ausgewählt werden können, welches zu verwenden ist. Mit Web-Apps ist Skalierbarkeit und Leistung sehr wichtig (wer weiß, vielleicht wird meine Idee zum nächsten YouTube), und ich konnte keine sinnvollen Benchmarks zwischen den beiden leicht finden. Ich habe mich noch nicht mit der Java -API von Kernen vertraut gemacht, aber es fällt mir schwer zu glauben, dass es viel schlimmer sein könnte als Java -Editionen, was sehr nett zu sein scheint.

Wenn ein anderer Schlüsselwert viel besser wäre, empfehlen Sie dies auch. Ich speichere kleine Binärblobs und Schlüssel werden wahrscheinlich Hashes der Daten oder eine andere eindeutige ID sein.

Answer 1

Wenn Sie eine gemeinsame Schnittstelle zu diesen abgeben und über einen geeigneten Satz von Unit -Tests verfügen, sollten Sie in der Lage sein, zu einem späteren Zeitpunkt zwischen den beiden trivial zu tauschen im Augenblick)

Answer 2

Ich habe ziemlich viel Erfahrung mit BDB-JE und BDB-CORE mit Java. Die Entscheidung, welches zu verwenden ist, ist recht einfach: Wenn Sie die Parallelität wünschen, verwenden Sie BDB-JE. Wenn Sie Skalierbarkeit wünschen, verwenden Sie BDB-Core.

BDB-JE wird aufgrund seines Dateiformats und seiner Abhängigkeit von der Java-Müllsammlung mit großen Datenbanken mit großen Datenbanken aufgebaut, um die ausgefeilten Cache-Einträge zu beseitigen. Erwarten Sie eine lange Müllsammlung oder verbringen Sie viel Zeit damit, magische GC -Einstellungen abzustimmen. Das Dateiformat hat ebenfalls Probleme, da die Hintergrundreinigungsfäden viel Zeit damit verbringen müssen, Müll aufzuräumen, der durch frühe Cache -Räumungen erzeugt wird. Wenn Ihre Datenbank in RAM passt, funktioniert BDB-JE recht gut.

BDB-Core ist auf eine Seitenstarkenstrategie angewiesen, und hochrangige Anwendungen haben viele Sackgassen. Wenn Sie nach dem Zufallsprinzip die Operationen bestellen können, verringert es das Deadlockpotential, es wird jedoch nie eliminiert. Da BDB-Core Daten auf traditionellere Weise speichert, skaliert es auf super große Größen mit vorhersehbarer und erwarteter Leistungsverschlechterung. Da sein Cache nicht von einem Müllsammler verwaltet wird, kann er ziemlich groß sein und keine Pausen verursachen.

Answer 3

Ich war mit dem gleichen Problem konfrontiert und entschied mich für die Java -Ausgabe, hauptsächlich wegen seiner Portabilität (ich brauche etwas, das selbst auf mobilen Geräten gelaufen wäre). Es gibt auch die API der direkten Persistenzschicht (DPL) und die Tatsache, dass das gesamte DB ein einzelnes Glas ist, macht seinen Einsatz ziemlich einfach.

Die jüngste Version 4 brachte hohe Verfügbarkeit und Leistungsverbesserungen mit. Es gibt auch die Tatsache, dass lang laufende Java -Anwendungen eine solche Optimierung erreichen können und dass sie in einigen Szenarien die Leistung der nativen C -Anwendungen übertreffen würden.

Es passt natürliche für jede Java -Anwendung - Desktop oder Web.

Answer 4

Ich hatte vor meiner Zeit die gleiche Frage, nachdem ich einige Benchmarks gemacht hatte, fand ich, dass der Hash -Modus in der nativen Ausgabe viel schneller und lagerung effizient ist als alles, was die Java -Ausgabe zu bieten hat. Deshalb habe ich mich für die native Implementierung entschieden.

Ich schlage vor, Sie machen Ihre eigenen Benchmarks für die Speicherkapazitäten, die Sie erwarten, und entscheiden Sie, ob die Java -Ausgabe schnell genug ist.

Wenn es so ist oder wenn Leistung für Sie kein großes Problem ist (es ist für mich wichtig), gehen Sie einfach mit der Java -Ausgabe. Ansonsten gehen Sie mit dem nativen (vorausgesetzt, Sie sehen den gleichen Leistungsschub für Ihren eigenen Anwendungsfall).

Übrigens: Mein Benchmark war die Geschwindigkeit der Abfrage von zufälligen Schlüssel aus 20.000.000 Datensätzen, wobei der Schlüssel eine Zeichenfolge und der Wert ein Int (4 Bytes) ist. Ich sah, dass Einsätze (die Benchmark bevölkern) mit der nativen Version viel schneller waren und die Abfragen doppelt so schnell waren.

(Dies ist nicht auf das Java -Mangel zurückzuführen, sondern weil die Java -Version nicht die gleiche Version wie die native Version ist - 4.0 gegenüber 4.8 IIRC).

Answer 5

Ich habe mich für die Java -Ausgabe entschieden, einfach weil es möglich ist, die Datenbank -Laufzeit in denselben Bereitstellungsbetrieb einzubetten. Dies war ein wichtiges Merkmal für mein Setup. Ich habe mich nicht zwischen Core und JE bewertet, aber ich habe im Vergleich zu anderen Schlüsselwertspeichern, die ich bei der ersten Bewertung der Datenbankspeicher getestet habe, eine großartige Leistung gesehen.

Wenn Sie jedoch eine Webanwendung erstellen, ist die Parallelität auf lange Sicht möglicherweise sehr wichtig für Sie.