expériences db4o?

Question

J'essaie actuellement db4o (la version java) et j'aime assez ce que je vois. Mais je ne peux pas m'empêcher de me demander comment cela fonctionne dans un environnement réel (Web). Quelqu'un a-t-il des expériences (bonnes ou mauvaises) à partager sur l'utilisation de db4o?

Answer 1

Nous courons DB40 .Version NET dans un grand projet client/serveur.

Nos expériences, c'est que vous pouvez potentiellement obtenir de bien meilleures performances que les bases de données relationnelles.

Cependant, vous avez vraiment de régler vos objets pour obtenir ce genre de performance. Par exemple, si vous avez une liste contenant beaucoup d'objets, DB4O l'activation de ces listes est lente. Il y a un certain nombre de façons de contourner ce problème, par exemple, en inversant la relation.

La douleur est d'activation. Lorsque vous récupérer ou de supprimer un objet de DB4O, par défaut, il activera l'ensemble de l'arborescence d'objets. Par exemple, le chargement d'une Foo charge Foo.Bar.Baz.Chauve-souris, etc jusqu'à ce qu'il n'y a rien à charger. Alors que c'est bien du point de vue programmation, la performance de ralentir le plus de nidification dans vos objets. Pour améliorer les performances, vous pouvez dire DB4O combien de niveaux de profondeur pour l'activer. C'est fastidieux à faire si vous avez beaucoup d'objets.

Une autre zone de la douleur a été la recherche de texte. DB4O de la recherche de texte est beaucoup, beaucoup plus lent que SQL indexation de texte intégral. (Ils vous diront ce carrément sur leur site.) Les bonnes nouvelles sont, il est facile pour l'installation d'un moteur de recherche en texte sur le dessus de DB4O. Sur notre projet, nous avons accroché Lucene.NET pour indexer les champs de texte que nous voulons.

Certaines Api ne semblent pas fonctionner, comme le GetField Api utile dans l'application de base de données mises à jour. (Par exemple, vous avez renommé un bien immobilier et vous souhaitez mettre à niveau vos objets existants dans la base de données, vous devez utiliser ces "réflexion" Api pour trouver des objets dans la base de données. D'autres Api, comme le [Index] attribut de ne pas travailler dans la stabilité de la version 6.4, et vous devez spécifier l'index de l'aide de la configuration().Index("someField"), ce qui n'est pas fortement typé.

Nous avons assisté à la performance de dégrader la plus grande de votre base de données. Nous avons une base de données de 1 go dès maintenant et les choses sont toujours rapide, mais pas aussi vite que lorsque nous avons commencé avec une petite base de données.

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

Nous avons trouvé la syntaxe de Requête Native (la plus naturelle, la langue intégrée de la syntaxe pour les requêtes) est beaucoup, beaucoup plus lent que le moins respectueux de SOUDE requêtes. Donc 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 cela nice code de requête, vous avez à un truand de la SOUDE requête qui est basée sur une chaîne et pas fortement typé.

Pour .NET les gens, ils ont récemment introduit un LINQ-to-DB4O fournisseur, qui fournit le meilleur encore la syntaxe. Cependant, c'est encore à voir si les performances seront à la hauteur avec la moche de SOUDE requêtes.

DB4O de soutien a été décent: nous avons parlé au téléphone, un certain nombre de fois et ont reçu des infos utiles. Leurs forums d'utilisateurs sont à côté de rien, cependant, presque toutes les questions restent sans réponse. Leur JIRA bug tracker reçoit beaucoup d'attention, donc si vous avez une lancinante bug, le déposer sur JIRA sur souvent, il sera corrigé. (Nous avons eu 2 bugs qui ont été corrigés, et un autre qui l'a corrigé dans une à moitié chemin.)

Si tout cela n'a pas peur de vous, permettez-moi de dire que nous sommes très heureux de DB4O, malgré les problèmes que nous avons rencontrés. Les performances que nous avons a soufflé quelques O/RM cadres que nous avons essayé. Je vous la recommande.

Answer 2

La plupart des requêtes natives peuvent et sont efficacement converties en requêtes SODA en coulisse, ce qui ne devrait pas faire de différence. L'utilisation de NQ est bien sûr préférable car vous restez dans le royaume du langage fort. Si vous ne parvenez pas à faire en sorte que NQ utilise les index, n'hésitez pas à poster votre problème sur les forums de db4o . Nous essaierons de vous aider.

Goran

Answer 3

Le principal problème que j'ai rencontré est le signalement. Il ne semble pas y avoir de moyen de générer des rapports efficaces sur une source de données db4o.

Answer 4

Judah, on dirait que vous n'utilisez pas l'activation transparente, qui est une fonctionnalité de la dernière version de production (7.4)? Peut-être que si vous avez spécifié la version que vous utilisez, d'autres problèmes pourraient-ils être résolus dans la dernière version?