Nous travaillons actuellement sur l'amélioration du système de réplication et l'amélioration des performances est certainement un objectif.
Je pense qu'il est assez difficile de produire des chiffres comparables. Chaque objet devant être répliqué nécessite une recherche dans l'UUID BTree. Si vous savez ce que vous êtes en train de faire, vous pouvez déterminer ce que vous faites en mémoire. Ensuite, le débit dépendra beaucoup du nombre d'index que vous avez de chaque côté et de la taille des index. db4o et le serveur SQL de votre choix (et tout autre serveur SQL) peuvent évoluer différemment avec la taille et cela peut dépendre du matériel que vous utilisez (db4o aime les disques à semi-conducteurs avec des temps de recherche courts).
C'est comme avec n'importe quel autre benchmark: vous pouvez seulement découvrir comment les choses vont vraiment fonctionner pour vous si vous simulez le scénario dont vous pensez avoir besoin et l'exécutez sur votre matériel. En ce qui concerne la gestion des accès simultanés: Tout conflit sera rappelé dans votre code et vous devrez choisir comment vous le gérerez. Vous pouvez résoudre à la main en fusionnant les modifications de chaque côté et vous pouvez également ignorer les objets. C'est à votre code de trouver ce qu'il pense être bon.
En ce qui concerne la simultanéité si vous avez une session de réplication fonctionnant côte à côte avec une autre session en direct qui modifie constamment les objets: Le code dRS actuellement publié n'est pas encore fort pour ce cas. Alors que nous implémentons la réplication entre db4o et la base de données d'objets haut de gamme Versant VOD, nous essaierons également de couvrir ce type de cas de concurrence.
Vraiment, personne? –
Désolé, jamais eu profond dans la réplication db4o. Avez-vous essayé de demander cela sur les forums db4o sur www.db4o.com? – Goran