mes 2 pence valent. Un peu envie mais ...... j'avais une exigence similaire dans l'un de mes projets d'incubation. Semblable à la vôtre, mes principales exigences étaient une base de données de documents (xml dans mon cas), avec gestion des versions de documents. C'était pour un système multi-utilisateurs avec de nombreux cas d'utilisation de collaboration. Ma préférence était d'utiliser des solutions open source disponibles qui prennent en charge la plupart des exigences clés.
Pour aller droit au but, je n'ai trouvé aucun produit offrant les deux, d'une manière suffisamment évolutive (nombre d'utilisateurs, volumes d'utilisation, ressources de stockage et de calcul) .J'étais biaisé vers git pour toutes les capacités prometteuses, et des solutions (probables) que l'on pourrait en tirer. Au fur et à mesure que je jouais avec l'option git, passer d'une perspective mono-utilisateur à une perspective multi (milli) utilisateur est devenu un défi évident. Malheureusement, je n'ai pas pu faire une analyse de performance substantielle comme vous l'avez fait. (.. paresseux / quitter tôt .... pour la version 2, mantra) Power to you !. Quoi qu'il en soit, mon idée biaisée s'est depuis transformée en une alternative (toujours biaisée): un maillage d'outils qui sont les meilleurs dans leurs sphères distinctes, bases de données et contrôle de version.
Alors que le travail est encore en cours (... et légèrement négligé), la version transformée est simplement la suivante.
- sur le frontend: (userfacing) utilise une base de données pour le stockage de 1er niveau (interface avec les applications utilisateur)
- sur le backend, utilisez un système de contrôle de version (VCS) (comme git) pour effectuer le contrôle de version des objets de données dans la base de données
En substance, cela reviendrait à ajouter un plugin de contrôle de version à la base de données, avec un peu de colle d'intégration, que vous devrez peut-être développer, mais qui pourrait être beaucoup plus facile.
Comment cela fonctionnerait (censé), c'est que les échanges de données de l'interface multi-utilisateur primaire se font via la base de données. Le SGBD gérera tous les problèmes amusants et complexes tels que les opérations multi-utilisateurs, simultanées, atomiques, etc. Sur le backend, le VCS effectuerait le contrôle de version sur un seul ensemble d'objets de données (pas de concurrence ou des problèmes multi-utilisateurs). Pour chaque transaction effective sur la base de données, le contrôle de version n'est effectué que sur les enregistrements de données qui auraient effectivement changé.
Quant à la colle d'interfaçage, elle se présentera sous la forme d'une simple fonction d'interfonctionnement entre la base de données et le VCS. En termes de conception, une approche simple serait une interface événementielle, avec des mises à jour des données de la base de données déclenchant les procédures de contrôle de version (indice: supposer Mysql, utilisation de déclencheurs et sys_exec () bla bla ...). En termes de complexité d'implémentation, cela va du simple et efficace (scripting par exemple) au complexe et merveilleux (certaines interfaces de connecteurs programmées). Tout dépend de la façon dont vous voulez y aller et du capital de sueur que vous êtes prêt à dépenser. Je pense qu'un script simple devrait faire la magie. Et pour accéder au résultat final, aux différentes versions de données, une alternative simple est de peupler un clone de la base de données (plus un clone de la structure de la base de données) avec les données référencées par la balise de version / id / hachage dans le VCS. encore une fois, ce bit sera un simple travail de requête / traduction / carte d'une interface.
Il y a encore des défis et des inconnus à résoudre, mais je suppose que l'impact et la pertinence de la plupart d'entre eux dépendront en grande partie des exigences de votre application et de vos cas d'utilisation. Certains peuvent simplement ne pas être des problèmes. Certains des problèmes incluent la correspondance des performances entre les 2 modules clés, la base de données et le VCS, pour une application avec une activité de mise à jour de données à haute fréquence, la mise à l'échelle des ressources (stockage et puissance de traitement) au fil du temps du côté git comme les données et les utilisateurs grandir: stable, exponentiel ou éventuellement plateau
Du cocktail ci-dessus, voici ce que je prépare actuellement
- en utilisant Git pour le VCS (initialement considéré comme un bon vieux CVS pour le en raison de l'utilisation uniquement de changesets ou de deltas entre 2 versions)
- en utilisant mysql (en raison de la nature très structurée de mes données, xml avec des schémas xml stricts)
- jouer avec MongoDB (pour essayer une base de données NoSQl, qui correspond étroitement à la structure de base de données native utilisée dans git)
Quelques faits amusants - git fait en fait des choses claires pour optimiser le stockage, comme la compression et le stockage des seuls deltas entre les révisions d'objets - OUI, git ne stocke que les ensembles de modifications ou les deltas entre les révisions d'objets de données, où est-il applicable (il sait quand et comment) . Référence: packfiles, au plus profond des entrailles de Git
- L'examen du stockage d'objets de git (système de fichiers adressable par le contenu) montre des similitudes frappantes (du point de vue du concept) avec des bases de données noSQL telles que mongoDB. Encore une fois, au détriment du capital de sueur, cela peut offrir des possibilités plus intéressantes pour l'intégration du 2 et le réglage des performances.
Si vous êtes arrivé aussi loin, permettez-moi si ce qui précède peut s'appliquer à votre cas, et en supposant que ce soit le cas, comment cela correspondrait à certains des aspects de votre dernière analyse complète des performances.