2010-01-26 7 views
8

Nous sommes en train de faire des recherches pour savoir si notre db postgresql doit être remplacé par un db Derby intégré. Les deux utiliseraient Glassfish 3 pour notre couche de données. Quelqu'un at-il des opinions ou des connaissances qui pourraient nous aider à décider?Derby vs PostgreSql Comparaison des performances

Merci!

edit: nous écrivons des tests de performance nous-mêmes en ce moment. Vous cherchez des réponses plus basées sur l'expérience/connaissance de première main

+2

Ma prédiction: correctement réglé PostgreSQL va fumer Derby à toutes les requêtes, sauf les plus triviales. Pourquoi voulez-vous vous éloigner de PostgreSQL? Avez-vous passé le temps d'affiner correctement votre base de données? – intgr

Répondre

3

ai pas comparé Postgresql à Derby directement. Cependant, ayant utilisé les deux dans des circonstances différentes, j'ai trouvé que Derby était très fiable. Cependant, vous devrez faire attention à la configuration de Derby pour vous assurer qu'elle répond aux besoins de votre application.

+1

+1. La fiabilité à toute épreuve, l'empreinte mémoire faible et l'élasticité du déploiement (embarqué, serveur réseau, serveur réseau intégré +) sont en effet ses meilleurs atouts. –

+0

Je sais que Postgresql est plus mature db. Cependant, j'ai utilisé Derby pour une application de traitement db robuste et ne semble pas trouver de limites en termes de performances, de taille et de fiabilité. – donlys

1

Il existe un certain nombre de suites de tests de performance incluses dans la distribution de code source Derby elle-même; ils sont utilisés par les développeurs de Derby pour mener leurs propres tests de performance de Derby. Donc, si vous avez besoin d'exemples de tests de performance, ou si vous voulez des tests supplémentaires, vous pouvez envisager de les utiliser. Regardez dans le sous-répertoire java/testing/org/apache/derbyTesting/perf dans la distribution source de Derby.

6

Derby est encore relativement lent dans la performance, mais ... où que votre application Java va votre serveur de base de données va, complètement plate-forme indépendante. Vous n'avez même pas besoin d'installer un serveur de base de données sur lequel votre application Java est copiée.

j'utilisais MySQL avec Java, mais ayant une implémentation intégrée de votre serveur de base de données assis droit dans mon Java App est juste productivité étonnante et sans précédent, la liberté et la flexibilité.

ayant toujours un serveur DB inclus chaque fois et chaque fois que sur une plate-forme pour moi est juste le ciel !!!

13

Je sais que je suis en retard pour poster une réponse, mais je veux faire que personne ne fait l'erreur d'utiliser Derby sur une base de données de qualité de la production à l'avenir. Je m'excuse d'avance à quel point cette réponse est négative - j'essaie de capturer les mauvais sentiments d'une équipe d'ingénierie dans un bref Q & Une réponse.

Notre expérience en utilisant Derby dans de nombreux déploiements clients petite ish nous a permis de doute sérieusement combien il est utile pour tout sauf les environnements de test.Certains problèmes que nous avons:

  • interblocages causés par verrouillage escalades - c'est le plus grand et arrive à un client environ une fois par semaine ou deux
  • Interrompu E/S cause de Derby à l'échec pur et simple sur Solaris (ne peut pas être un problème sur d'autres plates-formes) - nous avons dû construire une cale pour le protéger de ces échecs
  • ne peut pas gérer les requêtes compliquées que MySQL/PostgreSQL manipulerais avec facilité
  • mise en œuvre du journal des transactions Buggy a provoqué une corruption de table ce qui nous a obligés à exporter la base de données, puis ré-importer (ne pouvait pas simplement laisser tomber la table corrompue), et nous avons encore perdu la table dans le processus - Dieu merci, nous avions une sauvegarde
  • Pas LIMIT syntaxe
  • faible performance pour les requêtes compliquées
  • Faible performance pour les grands ensembles de données

En raison du fait qu'il est intégré, Derby est plus un concurrent de SQLite que de PostgreSQL, qui est une base de données de qualité de production extrêmement mature qui est utilisée pour stocker des ensembles de données de plusieurs pétaoctets par certains des plus grands sites Web au monde. Si vous voulez être prêt pour la croissance et que vous ne voulez pas être surpris en train de déboguer le code de la base de données de quelqu'un d'autre, je vous recommande de ne pas utiliser Derby. Je n'ai aucune expérience avec SQLite, mais je ne peux pas imaginer qu'elle soit beaucoup moins fiable que celle de Derby et qu'elle soit toujours aussi populaire.

En fait, nous sommes en train de transférer vers PostgreSQL maintenant.

Questions connexes