Os arquivos HDF5 são adequados para o controle de revisão do git?

Não estou familiarizado com o formato de arquivo usado no HDF5, mas gostaria de saber se os arquivos HDF5 são adequados para o controle de revisão com o git (ou, por exemplo, Mercurial ou Subversion)? Acho que o que quero dizer é: os arquivos HDF5 são adequados para diferenças baseadas em linhas ou o git terá que tratar um HDF5 como um grande binário e armazenar uma cópia inteira para cada revisão?

data-management data-storage

— Thomas Arildsen
fonte

O HDF5 foi projetado para dados binários. Eles não são realmente apropriados para diferenças de linha. Dito isto, se tudo o que você escreve para eles são seqüências ASCII, provavelmente você se safará. Qual é o seu propósito?

— Bill Barth

Eu só estava me perguntando se eles seriam adequados para o controle de revisão. Fica inconveniente se o rastreamento de revisão precisar armazenar uma cópia nova inteira de todo o conjunto de dados toda vez que uma alteração relativamente pequena for feita nele.

— Thomas Arildsen

Que tipo de dados você estava pensando em colocar em seus arquivos HDF5? Os arquivos HDF5 são normalmente usados para grandes entradas e saídas binárias de códigos de simulação. Os primeiros geralmente não mudam com frequência e não está claro se os últimos pertencem ao controle de revisão. Qual é o seu objetivo?

— Bill Barth

Estou pensando em situações como descartar entradas de dados do seu conjunto de dados devido ao controle de qualidade ou adicionar dados adicionais a conjuntos de dados já existentes.

— Thomas Arildsen

O HDF5 provavelmente não será muito bom, mas você deve se perguntar o que é mais importante para você: o tamanho do seu repo ou os recursos que o HDF5 oferece. Talvez uma pergunta melhor seria "Qual é a melhor maneira de armazenar dados brutos que fornecem histórico de versões e recursos de proveniência?"

— Bill Barth

Respostas:

Você obterá uma resposta muito melhor se fornecer mais alguns detalhes técnicos sobre que tipo de dados você está tentando colocar sob controle de versão, como deseja armazenar versões diferentes dos dados, quais componentes provavelmente serão alterados e quais componentes não são e se você realmente terá um histórico semelhante a uma árvore (ramificações, mesclagens).

Os arquivos HDF5 não são adequados para o controle de versão baseado em diff no git.

O git usa um banco de dados baseado em hash sob o capô, portanto, é possível armazenar o hash do seu arquivo de dados HDF5 sem realmente armazenar o próprio arquivo. Três projetos, git-fat , git-anexo e git-media , simplificam bastante esse processo para você. Eu sugeriria usar essa abordagem se você tiver grandes e completamente independentes pedaços de dados que gostaria de versão explicitamente.

Se você pode separar seu armazenamento de dados em regiões não voláteis e voláteis, isso melhorará bastante a eficiência de sua interação com o banco de dados de controle de versão. Você também pode considerar o uso explícito de um banco de dados para seus dados, se não precisar dos recursos DVCS que o git oferece.

— Aron Ahmadia
fonte

Também é possível controlar os bancos de dados de versão, se é isso que você deseja fazer, controlando o esquema, lançando o banco de dados em um arquivo de texto e controlando o resultado (por exemplo, usando git). Consulte stackoverflow.com/questions/846659/… para obter detalhes.

— precisa saber é o seguinte

há também git-annex

— Memming

Acho que o que quero dizer é: os arquivos HDF5 são adequados para diferenças baseadas em linhas ou o git terá que tratar um HDF5 como um grande binário e armazenar uma cópia inteira para cada revisão?

A resposta literal a esta pergunta é que o git não tratará os arquivos HDF5 com eficiência.

Para obter respostas mais úteis sobre o controle de versão para projetos que possuem alguns arquivos binários, consulte esta pergunta do stackoverflow: /programming/540535/managing-large-binary-files-with-git

— k20
fonte

Como outros disseram, seria mais fácil fazer sugestões úteis se você descrevesse seu objetivo geral em vez de um ponto técnico preciso. Aqui está mais uma sugestão que pode ajudá-lo, dependendo do seu objetivo.

O projeto ActivePapers ( http://www.activepapers.org/ ) fornece um sistema de gerenciamento de código e dados sobre o HDF5. Um ActivePaper é um arquivo HDF5 que contém conjuntos de dados E o código que funciona neles, com metadados que controlam qual trecho de código calculou qual conjunto de dados e usando quais dados de entrada. Em combinação com o controle de versão no código fonte e / ou controle de versão em todo o arquivo HDF5 (usando ferramentas como o anexo git, mencionado em outra resposta), o ActivePapers pode ser usado para cálculos de versão em vez de arquivos ou conjuntos de dados isolados.

Isenção de responsabilidade: sou o autor do ActivePapers.

— Khinsen
fonte

No momento, não estou trabalhando em um problema específico, mas estava imaginando alguns conjuntos de dados aos quais você pode adicionar novos dados periodicamente. Com cada adição, você pode ter que armazenar uma cópia inteira de todo o conjunto de dados, que pode ser muito grande, enquanto, em princípio, seria necessário armazenar apenas um "diff" contendo os dados adicionados.

— Thomas Arildsen

Não conheço nenhuma ferramenta para executar operações no estilo diff / merge em dados binários, HDF5 ou outros. Uma idéia interessante para fazer isso com o ActivePapers é aplicar a alteração incluindo um "script de patch" no arquivo junto com os dados originais. Você pode acompanhar a evolução dos dados como uma sequência de patches aplicados. Uma vantagem da estrutura do ActivePapers é que você pode fazer as correções em um arquivo separado e referenciar o original. Isso significa que você pode publicar dados e publicar modificações (nos seus e nos de outras pessoas) posteriormente, como um trabalho separado.

— khinsen