Derby vs PostgreSql Leistungsvergleich

Ich weiß, dass ich zu spät bin, um hier eine Antwort zu schreiben, aber ich möchte sicherstellen, dass niemand den Fehler macht, Derby in Zukunft in einer Datenbank mit Produktionsqualität einzusetzen. Ich entschuldige mich im Voraus dafür, wie negativ diese Antwort ist - ich versuche, die schlechten Gefühle eines ganzen Entwicklerteams in einer kurzen Frage & Antwort zu erfassen.

Unsere Erfahrung mit der Verwendung von Derby in vielen kleinen Kundeninstallationen hat uns dazu gebracht, ernsthaft zu bezweifeln, wie nützlich es für alles außer Testumgebungen ist. Einige Probleme, die wir hatten:

• Deadlocks, die durch Lock-Eskalationen verursacht werden - dies ist der größte und passiert einem Kunden ungefähr einmal pro Woche oder zwei
• Unterbrochene I / Os führen dazu, dass Derby direkt unter Solaris ausfällt (möglicherweise kein Problem auf anderen Plattformen) - wir mussten ein Shim bauen, um es vor diesen Fehlern zu schützen
• Kann nicht mit komplizierten Abfragen umgehen, die MySQL / PostgreSQL mit Leichtigkeit handhaben würde
• Buggy-Transaktionsprotokollimplementierung verursachte eine Tabellenbeschädigung, die uns dazu zwang, die Datenbank zu exportieren und sie dann erneut zu importieren (konnte nicht einfach die beschädigte Tabelle fallen lassen), und dabei verloren wir die Tabelle - glücklicherweise hatten wir eine Backup
• Nein LIMIT Syntax
• Geringe Leistung für komplizierte Abfragen
• Geringe Leistung für große Datensätze

Aufgrund der Tatsache, dass es eingebettet ist, ist Derby eher ein Konkurrent für SQLite als für PostgreSQL, eine extrem ausgereifte Datenbank in Produktionsqualität, die für die Speicherung von mehreren Petabyte-Datensätzen auf einigen der größten Websites in die Welt. Wenn Sie bereit für das Wachstum sein wollen und nicht erwischt werden wollen, wenn Sie den Datenbankcode einer anderen Person austesten, würde ich empfehlen, Derby nicht zu verwenden. Ich habe keine Erfahrung mit SQLite, aber ich kann mir nicht vorstellen, dass es viel weniger zuverlässig ist, als Derby für uns war und immer noch so beliebt ist.

Tatsächlich sind wir gerade dabei, PostgreSQL zu portieren.

Derby ist immer noch relativ langsam in der Leistung, aber ... wo auch immer Ihre Java-Anwendung Ihren Datenbankserver ablaufen lässt, völlig plattformunabhängig. Sie müssen nicht einmal darüber nachdenken, einen DB-Server zu installieren, auf den Ihre Java-Anwendung kopiert wird.

Ich habe MySQL mit Java verwendet, aber eine eingebettete Implementierung Ihres Datenbankservers direkt in meiner Java-App zu haben, ist einfach atemberaubend und beispiellose Produktivität, Freiheit und Flexibilität.

Immer einen DB-Server immer und überall auf jeder Plattform für mich zu haben, ist einfach himmlisch !!!

Habe Postgresql nicht direkt mit Derby verglichen. Nachdem ich beide unter verschiedenen Umständen verwendet habe, habe ich Derby als sehr zuverlässig empfunden. Sie müssen jedoch auf die Derby-Konfiguration achten, um sicherzustellen, dass sie den Anforderungen Ihrer Anwendung entspricht.

Wenn man sich die Stats-Seite der H2-Datenbanken ansieht, lohnt es sich, die Nachfolgediskussion zu lesen, die zugunsten von Derby im Vergleich zu den H2-Schlussfolgerungen spricht. Ссылка

Einige Statistiken von der H2-Datenbank-Seite hier: Ссылка

Es gibt eine Reihe von Leistungstest-Suites, die als Teil der Derby-Quellcode-Distribution selbst enthalten sind; Sie werden von Derby-Entwicklern verwendet, um ihre eigenen Performancetests von Derby durchzuführen. Wenn Sie also Beispiele für Leistungstests benötigen oder zusätzliche Tests benötigen, können Sie diese verwenden. Suchen Sie im Unterverzeichnis java / testing / org / apache / derbyTesting / perf in der Derby-Quellenverteilung.