des expériences db4o ?

Question

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

Answer 1

Nous exécutons la version DB40 .NET dans un grand projet client/serveur.

Notre expérience montre que vous pouvez potentiellement obtenir de bien meilleures performances que les bases de données relationnelles classiques.

Cependant, vous devez vraiment peaufiner vos objets pour obtenir ce genre de performances.Par exemple, si vous disposez d'une liste contenant de nombreux objets, l'activation DB4O de ces listes est lente.Il existe plusieurs façons 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, cela activera par défaut toute l'arborescence des objets.Par exemple, charger un Foo chargera Foo.Bar.Baz.Bat, etc. jusqu'à ce qu'il n'y ait plus rien à charger.Bien que cela soit agréable du point de vue de la programmation, les performances ralentiront à mesure que l'imbrication dans vos objets sera importante.Pour améliorer les performances, vous pouvez indiquer à DB4O le nombre de niveaux à activer.Cela prend du temps si vous avez beaucoup d’objets.

Un autre domaine problématique était la recherche de texte.La recherche de texte dans DB4O est bien plus lente que l'indexation de texte intégral SQL.(Ils vous le diront directement sur leur site.) La bonne nouvelle est qu'il est facile de configurer un moteur de recherche de texte au-dessus de DB4O.Sur notre projet, nous avons connecté Lucene.NET pour indexer les champs de texte souhaités.

Certaines API ne semblent pas fonctionner, comme les API GetField utiles pour appliquer les mises à niveau de bases 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 rechercher des objets dans la base de données.D'autres API, telles que l'attribut [Index], ne fonctionnent pas dans la version stable 6.4 et vous devez à la place spécifier des index à l'aide de Configure().Index("someField"), qui n'est pas fortement typé.

Nous avons constaté que les performances se dégradent à mesure que votre base de données est grande.Nous avons actuellement une base de données de 1 Go et les choses sont toujours rapides, mais pas aussi rapides que lorsque nous avons commencé avec une petite base de données.

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

Nous avons constaté que la syntaxe Native Query (la syntaxe la plus naturelle et intégrée au langage pour les requêtes) est bien plus lente que les requêtes SODA moins conviviales.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 ce joli code de requête, vous devez utiliser une vilaine requête SODA basée sur une chaîne et non fortement typée.

Pour les utilisateurs de .NET, ils ont récemment introduit un fournisseur LINQ-to-DB4O, qui offre la meilleure syntaxe à ce jour.Cependant, il reste à voir si les performances seront à la hauteur des vilaines requêtes SODA.

Le support de DB4O a été correct :nous leur avons parlé au téléphone à plusieurs reprises et avons reçu des informations utiles.Leurs forums d’utilisateurs sont pratiquement sans valeur, cependant, presque toutes les questions restent sans réponse.Leur outil de suivi des bogues JIRA reçoit beaucoup d'attention, donc si vous avez un bogue persistant, déposez-le sur JIRA et il sera souvent corrigé.(Nous avons eu 2 bugs qui ont été corrigés et un autre qui a été corrigé de manière médiocre.)

Si tout cela ne vous a pas effrayé, laissez-moi vous dire que nous sommes très satisfaits de DB4O, malgré les problèmes rencontrés.Les performances dont nous disposons ont époustouflé certains frameworks O/RM que nous avons essayés.Je le recommande.

mise à jour juillet 2015 Gardez à l’esprit que cette réponse a été écrite en 2008.Même si j'apprécie les votes positifs, le monde a changé depuis et ces informations ne sont peut-être pas aussi fiables qu'elles l'étaient au moment de leur rédaction.

Answer 2

La plupart des requêtes natives peuvent et sont efficacement converties en requêtes SODA en coulisse, cela ne devrait donc pas faire de différence.L'utilisation de NQ est bien sûr préférable car on reste dans le domaine du langage à forte typologie.Si vous rencontrez des difficultés pour que NQ utilise les index, n'hésitez pas à poster votre problème sur le forum db4o et nous essaierons de vous aider.

Goran

Answer 3

Le principal problème que j'ai rencontré est le reporting.Il ne semble tout simplement pas y avoir de moyen d'exécuter des rapports efficaces sur une source de données db4o.

Answer 4

Judah, il semble que vous n'utilisiez pas l'activation transparente, qui est une fonctionnalité de la dernière version de production (7.4) ?Peut-être que si vous spécifiiez la version que vous utilisez, car il pourrait y avoir d'autres problèmes qui sont maintenant résolus dans la dernière version ?