¿Los archivos HDF5 son adecuados para el control de revisión git?

No estoy familiarizado con el formato de archivo utilizado en HDF5, pero me pregunto si los archivos HDF5 son adecuados para el control de revisión con git (o, por ejemplo, Mercurial o Subversion). Supongo que lo que quiero decir es: ¿los archivos HDF5 son adecuados para la diferenciación basada en líneas o git tendrá que tratar un HDF5 como un gran binario y almacenar una copia completa para cada revisión?

data-management data-storage

— Thomas Arildsen
fuente

HDF5 está diseñado para datos binarios. No son realmente apropiados para la diferencia de línea. Dicho esto, si todo lo que les escribes son cadenas ASCII, probablemente te saldrás con la tuya. ¿Cuál es tu propósito?

— Bill Barth

Me preguntaba si serían adecuados para el control de revisión. Se vuelve inconveniente si el seguimiento de la revisión tiene que almacenar una copia nueva completa de todo el conjunto de datos cada vez que se realiza un cambio relativamente pequeño.

— Thomas Arildsen

¿Qué tipo de datos planeabas poner en tus archivos HDF5? Los archivos HDF5 se usan típicamente para entradas y salidas binarias grandes de códigos de simulación. Los primeros a menudo no cambian con frecuencia, y no está claro que los últimos pertenezcan al control de revisión. ¿Cual es tu meta?

— Bill Barth

Estoy pensando en situaciones como descartar entradas de datos de su conjunto de datos debido al control de calidad o agregar datos adicionales a conjuntos de datos ya existentes.

— Thomas Arildsen

HDF5 probablemente no diferirá bien, pero debe preguntarse qué es más importante para usted: el tamaño de su repositorio o las características que le ofrece HDF5. Quizás una mejor pregunta sería "¿Cuál es la mejor manera de almacenar datos sin procesar que brindan características de historial y procedencia de versiones?"

— Bill Barth

Respuestas:

Obtendrá una respuesta mucho mejor si proporciona algunos detalles técnicos más sobre qué tipo de datos está tratando de poner bajo control de versión, cómo desea almacenar diferentes versiones de los datos, qué componentes es probable que cambien y qué componentes no son, y si realmente va a tener un historial similar a un árbol (ramas, fusiones).

Los archivos HDF5 no son adecuados para el control de versiones basado en diff bajo git.

git usa una base de datos basada en hash debajo del capó, por lo que es posible almacenar el hash de su archivo de datos HDF5 sin almacenar el archivo en sí. Tres proyectos, git-fat , git-annex y git-media , simplifican enormemente este proceso para usted. Sugeriría usar este enfoque si tiene grandes cantidades de datos completamente independientes que le gustaría versionar explícitamente.

Si puede separar su almacenamiento de datos en regiones no volátiles y volátiles, esto mejorará en gran medida la eficiencia de su interacción con la base de datos de control de versiones. También es posible que desee considerar explícitamente el uso de una base de datos para sus datos si no necesita las funciones de DVCS que ofrece git.

— Aron Ahmadia
fuente

También es posible controlar las bases de datos, si eso es lo que quiere hacer, controlando la versión del esquema, volcando la base de datos a un archivo de texto y controlando la versión del resultado (por ejemplo, usando git). Consulte stackoverflow.com/questions/846659/… para más detalles.

— Geoff Oxberry

también hay git-annex

— Memming

Supongo que lo que quiero decir es: ¿los archivos HDF5 son adecuados para la diferenciación basada en líneas o git tendrá que tratar un HDF5 como un gran binario y almacenar una copia completa para cada revisión?

La respuesta literal a esta pregunta es que git no tratará los archivos HDF5 de manera eficiente.

Para obtener respuestas más útiles sobre el control de versiones para proyectos que tienen algunos archivos binarios, consulte esta pregunta de stackoverflow: /programming/540535/managing-large-binary-files-with-git

— k20
fuente

Como dijeron otros, sería más fácil hacer sugerencias útiles si describiera su objetivo general en lugar de un punto técnico preciso. Aquí hay una sugerencia más que podría ayudarlo, dependiendo de cuál sea su objetivo.

El proyecto ActivePapers ( http://www.activepapers.org/ ) proporciona un código y un sistema de gestión de datos además de HDF5. Un ActivePaper es un archivo HDF5 que contiene conjuntos de datos Y el código que funciona en ellos, con metadatos que realizan un seguimiento de qué código calculó qué conjunto de datos y qué datos de entrada utilizaron. En combinación con el control de versiones en el código fuente y / o el control de versiones en todo el archivo HDF5 (usando herramientas como git-annex, mencionado en otra respuesta), ActivePapers puede usarse para versionar cálculos en lugar de archivos o conjuntos de datos aislados.

Descargo de responsabilidad: soy el autor de ActivePapers.

— Khinsen
fuente

Actualmente no estoy trabajando en un problema específico, pero estaba imaginando algún conjunto de datos al que podría estar agregando nuevos datos de vez en cuando. Con cada adición, es posible que deba almacenar una copia completa del conjunto de datos completo, que podría ser muy grande, mientras que, en principio, solo sería necesario almacenar un "diff" que contenga los datos agregados.

— Thomas Arildsen

No conozco ninguna herramienta para realizar operaciones de estilo diff / merge en datos binarios, HDF5 u otros. Una idea intrigante para hacer esto con ActivePapers es aplicar el cambio al incluir un "script de parche" en el archivo junto con los datos originales. Luego puede seguir la evolución de los datos como una secuencia de parches aplicados. Una ventaja del marco de ActivePapers es que puede hacer los parches en un archivo separado que hace referencia al original. Eso significa que puede publicar datos y publicar modificaciones (a los suyos y los de otra persona) más adelante, como un trabajo separado.

— Khinsen