expériences db4o?

Question

J'essaie actuellement db4o (la version java) et j'aime à peu près ce que je vois. Mais je ne peux pas m'empêcher de me demander comment cela fonctionne dans un environnement réel (web-). Est-ce que quelqu'un a des expériences (bonnes ou mauvaises) à partager sur le fonctionnement de db4o?

Answer 1

Nous exécutons la version DB40 .NET dans un grand projet client/serveur. D'après nos expériences, vous pouvez obtenir de bien meilleures performances que les bases de données relationnelles classiques.

Cependant, vous devez vraiment modifier vos objets pour obtenir ce type de performance. Par exemple, si vous avez une liste contenant beaucoup d'objets, l'activation de ces listes par DB4O est lente. Il existe plusieurs moyens de contourner ce problème, par exemple en inversant la relation.

Une autre douleur est l'activation. Lorsque vous récupérez ou supprimez un objet de DB4O, il active par défaut l'arborescence entière de l'objet. Par exemple, charger un Foo chargera Foo.Bar.Baz.Bat, etc. jusqu'à ce qu'il ne reste plus rien à charger. Bien que cela soit agréable du point de vue de la programmation, les performances ralentiront l'imbrication de vos objets. Pour améliorer les performances, vous pouvez indiquer à DB4O le niveau de profondeur à activer. Cela prend du temps à faire si vous avez beaucoup d'objets.

Une autre zone de douleur était la recherche de texte. La recherche de texte de DB4O est loin, beaucoup plus lente que l'indexation de texte intégral de SQL. (Ils vous le diront tout de suite sur leur site.) La bonne nouvelle, c'est qu'il est facile d'installer un moteur de recherche de texte sur DB4O. Sur notre projet, nous avons connecté Lucene.NET pour indexer les champs de texte que nous voulons.

Certaines API ne semblent pas fonctionner, comme les API GetField utiles dans l'application des mises à niveau de base de données. (Par exemple, vous avez renommé une propriété et vous souhaitez mettre à niveau vos objets existants dans la base de données, vous devez utiliser ces API de "réflexion" pour trouver des objets dans la base de données.Autres API, telles que l'attribut [Index] t fonctionne dans la version stable 6.4, et vous devez spécifier les index à l'aide de Configure(). Index ("someField"), qui n'est pas fortement typé

Nous avons constaté que les performances se dégradent au fur et à mesure que la base de données est plus importante. une base de données de 1 Go en ce moment et les choses sont encore rapides, mais pas aussi rapide que lorsque nous avons commencé avec une base de données minuscule

Nous avons trouvé un autre problème où Db4O.GetByID fermera la base de données si l'ID n'existe pas plus dans la base de données

Nous avons trouvé la syntaxe Native Query (la syntaxe la plus naturelle, intégrée à la langue pour les requêtes) est beaucoup plus lente que les requêtes SODA moins conviviales. Ainsi, au lieu de taper:

// C# syntax for "Find all MyFoos with Bar == 23". 
// (Note the Java syntax is more verbose using the Predicate class.) 
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23); 

Au lieu de ce beau code de requête, vous devez une requête SODA laide qui est basée sur une chaîne et non fortement typé.

Pour les utilisateurs .NET, ils ont récemment introduit un fournisseur LINQ-to-DB4O, qui fournit la meilleure syntaxe pour le moment. Cependant, il reste encore à voir si les performances seront à la hauteur des requêtes SODA laides.

Le support de DB4O a été décent: nous leur avons parlé plusieurs fois au téléphone et nous avons reçu des informations utiles. Leurs forums d'utilisateurs sont presque sans valeur, cependant, presque toutes les questions restent sans réponse. Leur bug tracker JIRA reçoit beaucoup d'attention, donc si vous avez un bug lancinant, le fichier sur JIRA dessus sera souvent corrigé. (Nous avons eu 2 bugs qui ont été corrigés, et un autre qui a été corrigé à moitié.

Si tout cela ne vous a pas effrayé, permettez-moi de dire que nous sommes très heureux avec DB4O, malgré les problèmes que nous avons rencontrés. La performance que nous avons a époustouflé certains frameworks O/RM que nous avons essayés. Je le recommande. Gardez à l'esprit, cette réponse a été écrite en 2008. Bien que j'apprécie les upvotes, le monde a changé depuis, et cette information peut ne pas être aussi fiable qu'elle l'était quand elle a été écrite.

Answer 2

Le principal problème que j'ai rencontré avec elle est la génération de rapports. Il ne semble tout simplement pas possible d'exécuter des rapports efficaces sur une source de données db4o.

Answer 3

La plupart des requêtes natives peuvent être et sont efficacement converties en requêtes SODA en arrière-plan, ce qui ne devrait pas faire de différence. L'utilisation de NQ est bien sûr préférable car vous restez dans les domaines du langage typé fort. Si vous avez des problèmes pour que NQ utilise des index, n'hésitez pas à poster votre problème au db4o forums et nous essaierons de vous aider.

Goran

Answer 4

Juda, il semble que vous n'utilisez pas l'activation transparente, ce qui est une caractéristique de la dernière version de production (7.4)? Peut-être que si vous spécifiez la version que vous utilisez, il peut y avoir d'autres problèmes résolus dans la dernière version?