SQLite é um formato de armazenamento recomendado pela Biblioteca do Congresso dos EUA

 (sqlite.org)
1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp

SQLite e os formatos de armazenamento recomendados pela LoC

Critérios para formatos de armazenamento recomendados

  • Formatos de armazenamento recomendados são aqueles que os especialistas em preservação da Library of Congress consideram capazes de maximizar a capacidade de sobrevivência e o acesso contínuo ao conteúdo digital
  • Ao escolher formatos de armazenamento recomendados, a Library of Congress considera os seguintes critérios

  • Abertura

    • Avalia em que medida existem especificações completas e ferramentas para verificar a integridade técnica, e o quanto essas informações estão acessíveis a quem cria e mantém conteúdo digital
    • Documentação completa é mais importante do que a aprovação por uma organização de padronização reconhecida

  • Adoção

    • Avalia em que medida os principais criadores, distribuidores e usuários de recursos informacionais já utilizam o formato
    • Isso inclui casos em que ele é usado como formato mestre, formato de entrega ao usuário final ou meio de intercâmbio entre sistemas

  • Transparência

    • Avalia em que medida a representação digital pode ser analisada diretamente com ferramentas básicas, como quando pode ser lida por pessoas em um editor de texto simples

  • Autodocumentação

    • Objetos digitais autodocumentados incluem metadados descritivos básicos, metadados técnicos e outros metadados administrativos

  • Dependências externas

    • Avalia o grau de dependência de hardware, sistema operacional ou software específicos para renderização ou uso, e a complexidade de lidar com essas dependências em ambientes tecnológicos futuros

  • Impacto de patentes

    • Avalia em que medida patentes podem dificultar a capacidade de instituições de preservação manterem conteúdo nesse formato

  • Mecanismos de proteção técnica

    • Avalia se há implementação de mecanismos como criptografia que impeçam a preservação de conteúdo em repositórios confiáveis

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários do Hacker News

  • Sempre me inspiro no SQLite. Gosto dele no geral, mas, se você não vai fazer escritas, ele também pode ser uma escolha exagerada
    Então, sem dizer que supera o SQLite, fiz um formato que é bem mais leve e rápido, e funciona até em arquivos compactados com zstd. O índice é muito pequeno e, como o SQLite, consegue armazenar binários ou texto
    A parte em wasm responsável por descompactar, ler e buscar tem 38 KB sem compressão e, provavelmente, uns 16 KB com gzip. Comparado ao wasm do SQLite com 1,2 MB e o glue code, isso dá 3% do tamanho, e a busca e o carregamento são bem mais rápidos
    Meu programa não é colunar nem serve para gerenciar planilhas, mas funciona bem para dicionários e arquivos de imagens e áudio
    Também portei um decodificador jbig2 para um módulo wasm de 17 KB, então ele consegue ler scans em preto e branco de 8 KB por página e ainda assim continuar legível
    https://github.com/tnelsond/peakslab
    O SQLite é muito bem projetado, e o PeakSlab é muito simples

    • Você disse “1,2 MB do wasm do SQLite com o glue code”, mas a forma padrão atual, sem minificação, no trunk, na verdade é 1,7 MB. A documentação ocupa quase tanto quanto o código JS, então o WASM e o JS ficam quase meio a meio. Mas, minificado, 1,2 MB está correto
      Aliás, eu sou o mantenedor disso
      Os números atuais no trunk são sqlite3.wasm 896745, sqlite3.mjs 816270 (sem minificação, com documentação), sqlite3.mjs 431388 (sem minificação, sem documentação), sqlite3.mjs 310975 (minificado)
    • Eu não conhecia o PeakSlab, mas isso é realmente muito legal e novo. O desempenho com dicionários também parece excelente, e vale a pena favoritar para usar depois
    • Isso parece estar mais perto de competir com o antigo Berkeley DB: https://en.wikipedia.org/wiki/Berkeley_DB
      Fui ver agora e ele nem é mais licença BSD; de todo modo, praticamente desapareceu por causa do SQLite, mas era usado como armazenamento básico de chave-valor em disco
    • O SQLite também é simples à sua maneira, e gosto dos princípios de projeto do dialeto SQL dele
      Algo como “right join é só um left join na direção contrária, então não precisamos disso”
      Claro, sempre dá para fazer algo mais simples ou mais especializado. Muitos apps que usam banco de dados vão funcionar muito bem só com SQLite, e alguns talvez já fiquem plenamente atendidos apenas com arquivos de texto em vez de um banco como o SQLite
    • Acho que a solução mais padrão seria o cdb. Só que ele não oferece suporte a dados compactados
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • Sempre gostei do SQLite, mas ouvi dizer que algumas empresas proíbem seu uso
    O motivo é que ele torna fácil demais criar um banco de dados para o app, fazendo um componente ultracrítico da aplicação parecer apenas um arquivo. Esse arquivo pode ter qualquer extensão e ainda pode ser copiado para outro servidor. Isso continua valendo mesmo se ele contiver informações de identificação pessoal
    Se você imaginar isso se multiplicando pelo número de apps dentro de uma empresa, pode virar uma bela bagunça
    Equipes de DevOps e DBA preferem que bancos de dados sejam equipamentos grandes e pesados que claramente sejam servidores de banco de dados. O simples ato de se conectar já fica óbvio, etc.
    Ainda assim, continuo gostando de SQLite

    • Então fico curioso se essas mesmas empresas também proíbem Excel. Planilhas do Excel muitas vezes acabam virando bancos de dados paralelos em lugares inesperados
    • Para qualquer conversa sobre “qualquer coisa pode virar um banco de dados de missão crítica”, este post deveria ser leitura obrigatória
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • Se é “um arquivo que pode ter qualquer extensão”, então basta ler o magic number. Não dá para confiar em extensão de arquivo de qualquer jeito
      E “pode ser copiado para outro servidor” também vale para planilhas
      Não estou negando que acesso centralizado aos dados seja desejável, mas essa lógica não parece sofisticada o suficiente
    • O SQLite também tem este uso interessante: https://sqlite.org/sqlar.html
    • É por isso que esses arquivos de configuração vão para o AppData, para o diretório de dotfiles ou para o local equivalente dentro de ~/Library no MacOS

  • Eu costumava achar que “SQLite é um produto de brinquedo e não dá para confiar nele para dados reais”, mas agora mudei para a linha de “vamos usar SQLite para quase tudo”
    Se você consegue se encaixar no padrão de um único escritor e vários leitores, o SQLite é excelente. Com a configuração certa, ele não perde dados, e dá para descobrir essa configuração com 1 minuto de busca
    Hoje em dia, a maioria dos meus apps é simplesmente uma combinação de binário Go + SQLite + arquivo de serviço systemd
    Ainda não perdi dados, o desempenho é excelente e, para a maioria dos apps, isso basta

    • Escritor único, na prática, não é um problema tão grande quanto se costuma dizer. Hoje em dia, drives NVMe são incríveis, e com uma configuração otimizada de WAL dá para chegar fácil a 5 mil escritas por segundo. A maioria dos apps nem sonha com isso
      Já cheguei até a 180 mil escritas por segundo num VPS comum usando um padrão de escritor em lote
    • Fiquei curioso se você usa vários nós de backend. Se usa, também queria saber como acessa o arquivo SQLite a partir de nós diferentes

  • Está escrito “No momento em que escrevo isto (2018-05-29)...”, então isso é uma notícia de quase 8 anos atrás. Mesmo assim, eu não sabia disso até agora, então não é reclamação; estou mais para agradecer por terem postado
    Meu cérebro matemático travou por um instante e achei que fossem 6 anos

    • Agora estamos em 2026, então é 8 anos atrás
    • Senti um déjà vu enquanto lia

  • Formatos de armazenamento recomendados em 2026: https://www.loc.gov/preservation/resources/rfs/data.html

    • Quando você precisa armazenar dados planejando 300 a 500 anos no futuro, e fazer isso resistir a todo tipo de inovação e ao envelhecimento básico da tecnologia, pensar no longo prazo realmente importa
      Qual será o meio em papel que sobreviveu por mais tempo?
    • O critério de recomendação parece bem frouxo. XLS entra como “preferido”

  • Para preservação de dados no setor público, o SQLite pode ser uma das melhores escolhas
    A especificação é aberta, ele é amplamente adotado e há grande chance de continuar legível no futuro
    Tem pouca dependência de sistema operacional ou de serviço específico, e também baixo risco de patente
    Do ponto de vista de longevidade, é muito importante não depender de uma empresa ou serviço específico

    • Arquivistas também gostam de formatos mais próximos do original. O SQLite permite preservar relações relacionais que seriam difíceis de expressar em CSV

  • Gosto do SQLite e fico feliz que tenham compartilhado isso, mas parece que o título deveria terminar com “(2018)”
    Está escrito: “No momento em que escrevo isto (2018-05-29), os únicos outros formatos de armazenamento recomendados para conjuntos de dados são XML, JSON e CSV”

    • Só para constar, muitos formatos foram adicionados à lista depois disso
      Entre os formatos preferidos, têm prioridade os formatos baseados em texto e independentes de plataforma em vez de formatos nativos ou binários, desde que os dados estejam completos e mantenham detalhes e precisão. Isso inclui padrões de mercado de fato, bem desenvolvidos e amplamente adotados
      Por exemplo, formatos baseados em esquema conhecidos e com ferramentas públicas de validação, formatos orientados a linhas como TSV, CSV e largura fixa, e formatos abertos independentes de plataforma como .db, .db3, .sqlite e .sqlite3
      Também entram formatos proprietários que são padrão de fato em certas profissões ou que têm suporte de várias ferramentas. Por exemplo, Excel .xls/.xlsx e Shapefile
      Quanto à codificação de caracteres, a preferência é UTF-8, UTF-16 com BOM, US-ASCII ou ISO 8859-1, e depois outras codificações nomeadas
      Entre os formatos aceitáveis, para dados há formatos abertos, não proprietários e documentados publicamente, aprovados como padrão por comunidades especializadas ou órgãos governamentais, como CDF e HDF, além de formatos de dados baseados em texto com esquemas disponíveis
      Para empacotamento ou transferência, são aceitos ZIP, RAR, tar e 7z sem criptografia, senha ou outros mecanismos de proteção
      https://www.loc.gov/preservation/resources/rfs/data.html

  • Ontem mesmo eu estava pensando que já fazia um tempo desde a última vez que vi um post sobre SQLite no topo do HN
    Gosto muito da simplicidade e da velocidade do SQLite, e já usei tanto em projetos pessoais quanto no trabalho
    Ainda assim, no trabalho do dia a dia, acabo indo para o Excel. Não porque eu goste mais dele, mas porque ele é tão amplamente usado que acaba sendo a forma de menor atrito para compartilhar e explorar datasets com stakeholders menos técnicos ou executivos

    • Não acho que isso vá abalar seu universo de repente, mas talvez valha a pena dar uma olhada no Metabase, porque foi útil para mim e pode ser para você também
      Você pode hospedar por conta própria, e ele é realmente simples se o que você quer é só mostrar os dados aos stakeholders de uma forma fácil de consumir. Claro, se você se aprofundar demais, pode acabar se arrependendo de todas as decisões da sua vida, mas eu tento me conter para não chegar nesse ponto
      https://www.metabase.com/
    • Sempre me incomodou o fato de o SQLite depender de parsing de texto para funcionar. Não entendo por que as consultas precisam ser escritas em texto em vez de serem expressas como lógica do programa
      Por causa disso, nunca usei um banco relacional. É porque eu odeio isso. Sei que pode ter desempenho melhor do que dados puramente estruturados, mas odeio SQL e a própria ideia de SQL, e não quero escrever, aprender nem usar sistemas que dependam disso
      Parece uma abordagem errada no nível do PHP. Existe alguma forma de amenizar isso? Não quero continuar descartando o SQLite por causa do SQL, mas simplesmente não consigo aceitar. Não gosto da ideia de montar strings nem de ter parsing de string em nenhum ponto da stack, simplesmente parece errado

  • O SQLite é surpreendentemente versátil. Só algumas semanas atrás foi lançada uma extensão que implementa filas entre processos, streams e publicação/assinatura em SQLite
    Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    Notificações em tempo real eram uma das grandes peças que faltavam para implementar um app inteiro sobre um backend SQLite, e agora existe uma solução bem razoável

  • É bom ver o SQLite recebendo esse nível de reconhecimento institucional. O formato de arquivo único torna o armazenamento em arquivo muito mais simples do que dumps tradicionais de banco de dados