Les fichiers HDF5 conviennent-ils au contrôle de révision git?

13

Je ne connais pas le format de fichier utilisé dans HDF5, mais je me demande si les fichiers HDF5 conviennent au contrôle de révision avec git (ou par exemple Mercurial ou Subversion)? Je suppose que ce que je veux dire est: les fichiers HDF5 sont-ils adaptés à la diff-line en ligne ou git devra-t-il traiter un HDF5 comme un gros binaire et stocker une copie entière pour chaque révision?

data-management data-storage Thomas Arildsen
la source
1
HDF5 est conçu pour les données binaires. Ils ne sont pas vraiment appropriés pour la différence de ligne. Cela étant dit, si vous ne leur écrivez que des chaînes ASCII, vous vous en sortirez probablement le plus souvent. Quel est ton but?
Bill Barth
Je me demandais simplement s'ils seraient adaptés au contrôle des révisions. Cela devient gênant si le suivi des révisions doit stocker une nouvelle copie entière de l'ensemble de données à chaque fois qu'une modification relativement petite lui a été apportée.
Thomas Arildsen
1
Quels types de données envisagiez-vous de mettre dans vos fichiers HDF5? Les fichiers HDF5 sont généralement utilisés pour les grandes entrées et sorties binaires des codes de simulation. Souvent, les premiers ne changent pas fréquemment, et il n'est pas clair que les seconds appartiennent au contrôle de révision. Quel est ton but?
Bill Barth
Je pense à des situations telles que l'élimination des entrées de données de votre ensemble de données en raison du contrôle de la qualité ou l'ajout de données supplémentaires à des ensembles de données déjà existantes.
Thomas Arildsen
2
HDF5 ne diffère probablement pas bien, mais vous devez vous demander ce qui est le plus important pour vous: la taille de votre repo ou les fonctionnalités que HDF5 vous offre. Une meilleure question serait peut-être "Quelle est la meilleure façon de stocker des données brutes qui fournissent l'historique des versions et les fonctionnalités de provenance?"
Bill Barth

Réponses:

9

Vous obtiendrez une bien meilleure réponse si vous fournissez quelques détails techniques supplémentaires sur le type de données que vous essayez de mettre sous contrôle de version, comment vous souhaitez stocker différentes versions des données, quels composants sont susceptibles de changer et quels composants ne le sont pas, et si vous allez vraiment avoir un historique arborescent (branches, fusions).

Les fichiers HDF5 ne conviennent pas pour le contrôle de version basé sur diff sous git.

git utilise une base de données basée sur le hachage sous le capot, il est donc possible de stocker le hachage de votre fichier de données HDF5 sans réellement stocker le fichier lui-même. Trois projets, git-fat , git-annex et git-media , simplifient grandement ce processus pour vous. Je suggérerais d'utiliser cette approche si vous avez de gros morceaux de données complètement indépendants que vous souhaitez mettre à jour explicitement.

Si vous pouvez séparer votre stockage de données en régions non volatiles et volatiles, cela améliorera considérablement l'efficacité de votre interaction avec la base de données de contrôle de version. Vous pouvez également envisager d'utiliser explicitement une base de données pour vos données si vous n'avez pas besoin des fonctionnalités git de DVCS.

Aron Ahmadia
la source
Il est également possible de contrôler les versions des bases de données, si c'est ce que vous voulez faire, en contrôlant la version du schéma, en vidant la base de données dans un fichier texte et en contrôlant la version du résultat (par exemple, en utilisant git). Voir stackoverflow.com/questions/846659/… pour plus de détails.
Geoff Oxberry
il y a aussi git-annex
Memming
3

Je suppose que ce que je veux dire est: les fichiers HDF5 sont-ils adaptés à la diff-line en ligne ou git devra-t-il traiter un HDF5 comme un gros binaire et stocker une copie entière pour chaque révision?

La réponse littérale à cette question est que git ne traitera pas efficacement les fichiers HDF5.

Pour des réponses plus utiles sur le contrôle de version pour les projets qui ont des fichiers binaires, voir cette question stackoverflow: /programming/540535/managing-large-binary-files-with-git

k20
la source
3

Comme d'autres l'ont dit, il serait plus facile de faire des suggestions utiles si vous décriviez votre objectif global plutôt qu'un point technique précis. Voici une autre suggestion qui pourrait vous aider, selon votre objectif.

Le projet ActivePapers ( http://www.activepapers.org/ ) fournit un système de gestion de code et de données en plus de HDF5. Un ActivePaper est un fichier HDF5 qui contient des ensembles de données ET le code qui fonctionne sur eux, avec des métadonnées gardant la trace de quel morceau de code calculé quel ensemble de données et en utilisant quelles données d'entrée. En combinaison avec le contrôle de version sur le code source et / ou le contrôle de version sur l'ensemble du fichier HDF5 (en utilisant des outils tels que git-annex, mentionné dans une autre réponse), ActivePapers peut être utilisé pour versionner des calculs plutôt que des fichiers ou des ensembles de données isolés.

Avertissement: je suis l'auteur d'ActivePapers.

Khinsen
la source
1
Je ne travaille pas actuellement sur un problème spécifique, mais j'imaginais un ensemble de données auquel vous pourriez ajouter de nouvelles données de temps en temps. Avec chaque ajout, vous devrez peut-être stocker une copie entière de l'ensemble de données, ce qui pourrait être très volumineux, alors qu'en principe, il ne serait nécessaire que de stocker un "diff" contenant les données ajoutées.
Thomas Arildsen
1
Je ne connais aucun outil pour effectuer des opérations de style diff / fusion sur des données binaires, HDF5 ou autre. Une idée intrigante pour ce faire avec ActivePapers consiste à appliquer la modification en incluant un "script de correctif" dans le fichier avec les données d'origine. Vous pouvez ensuite suivre l'évolution des données sous la forme d'une séquence de patchs appliqués. Un avantage du framework ActivePapers est que vous pouvez faire les correctifs dans un fichier séparé les références à l'original. Cela signifie que vous pouvez publier des données et publier des modifications (à vos propres données et à celles de quelqu'un d'autre) plus tard, en tant qu'œuvre distincte.
khinsen