dg:Convenções/Armazenamento de dados

De Documentação

Modelo de dados

Modelo original de 2019.

Ver (trazer para cá) https://github.com/AddressForAll/WS/blob/master/docs/preserv-endpoints.md

Situação atual das tabelas de doação, schema optim:

  • Descritores de dados filtrados e make_conf:
    • optim.codec_type. Sem descritores. Fornece extension e variant dos arquivos, com tradução precisa para MIME type e encode. PK=...
    • optim.donated_packcomponent. Sem descritores. Fornece linhagem do pacote. PK=...
    • optim.donated_packcomponent_cloudcontrol. Sem desc. Fornece "de-para" do SHA256 do arquivo original (hashedfname) para sua atual URL de preseração digital (hashedfnameuri). Também fornece o MD5 do arquivo explodido, usado na linhagem (tabela donated_packcomponent). PK=packvers_id.
    • donated_packcomponent_not_approved. Pacotes não aprovados.
    • optim.donated_packfilevers. Controle de IDs e de versões do pacote, com relacionamento do SHA256, seus itens e seu versionamento (por item). Traz a pack_item_accepted_date e a info básica.
    • optim.donated_packtpl. Traz toda info e make_conf_tpl. PK: id.
    • optim.donor, descreve o doador.
  • Dados consolodados:
    • optim.consolidated_data (resgate de donor apenas via afa_id do ponto)
    • optim.consolidated_data2 mais completa, tem coluna packvers_id (no futuro será array).
    • optim.consolidated_data_dups fornece duplicados, não-publicados.
      optim.consolidated_data_pre a investigar, talvez dados brutos.
  • ...

Lembretes:

select count(*) from  optim.donated_packtpl where make_conf_tpl?'license_evidences';

Link eterno

O projeto Digital-guard disponibiliza os dados preservados por meio de links eternos no formato default:

https://dl.digital-guard.org/<sha256>.<extensão>


Por exemplo, os dados sobre lotes doados pela prefeitura de São Paulo possuem o link eterno:

https://dl.digital-guard.org/bae2054448855305db0fc855d2852cd5a7b369481cc03aeb809a0c3c162a2c04.zip


Sem perda de unicidade, o mesmo arquivo pode ser obtido usando pelo menos os 6 primeiros caracteres do sha256:

https://dl.digital-guard.org/bae205

Nuvem e redirecionamento

O projeto utiliza serviços de armazenamento em nuvem para hospedar arquivos.

Tabela de-para

A tabela de-para continua válida. É uma alternativa para não lidar com fromDL_toFileServer.csv diretamente no git.

No entanto:

fromDL_toFileServer.csv

Foi convencionado que a correspondência entre sha256 e link do arquivo no armazenamento seja feita oficialmente em

https://git.digital-guard.org/preserv/blob/main/data/redirs/fromDL_toFileServer.csv

e que novas entradas no arquivo sejam sempre adicionadas ao final do arquivo (não adicione linha em branco ao final do arquivo).


Tal arquivo possui os seguintes campos:

campo descrição exemplo
donor_id Id do doador, formado por ISO 3166 numérico * 1000000 + local_id de donor.csv 76000026 (local_id em donor.csv)
filename_original Nome original do arquivo. address_for_all.zip
package_path Caminho do pacote na estrutura do repositório. BR/data/SP/Limeira/_pk0026.01
de_sha256 Arquivo renomeado com o sha256 e extensão. 529f86b71a936bfdbca3d633b80912f496b9c94a2505ef816e406e2362b631c4.zip
para_url Url do arquivo no serviço de armazenamento. https://addressforall-my.sharepoint.com/personal/operacao_addressforall_org/_layouts/15/download.aspx?share=EYWIOsxWFpJFsa0X4zKalS8BbEaKtHVuyezvIbN2CdJljw

O exemplo citado na tabela se encontra na linha 601 fromDL_toFileServer.csv.

Para entender como gerar sha256 de um arquivo e como enviá-lo para a armazenagem em nuvem, ver dg:Guia_do_sha256.

O que fazer após atualizar fromDL_toFileServer.csv

Importante: o target redirects_update consome o conteúdo de fromDL_toFileServer.csv. Ele não consome o conteúdo da tabela de-para.

Atualizar fromDL_toFileServer.csv não atualiza automaticamente o datalake em produção. Para atualizá-lo, executar os comandos:

cd /var/gits/_dg/preserv
git pull
cd /var/gits/_dg/preserv/src
make redirects_update pg_datalake=dl05s_main