SQLite es un formato de almacenamiento recomendado por la Biblioteca del Congreso de EE. UU.

 (sqlite.org)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • SQLite está incluido entre los formatos de almacenamiento recomendados por la Biblioteca del Congreso de EE. UU. para conjuntos de datos
  • La base correspondiente puede verificarse en la descripción del formato SQLite de la Biblioteca del Congreso y en la lista de formatos recomendados para datos: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
  • Al 29 de mayo de 2018, los únicos formatos de almacenamiento recomendados para conjuntos de datos, además de SQLite, eran XML, JSON y CSV
  • Los formatos de almacenamiento recomendados por la Biblioteca del Congreso son aquellos que los especialistas en preservación consideran que maximizan la viabilidad y el acceso continuo del contenido digital
  • Los criterios de evaluación incluyen apertura, adopción, transparencia, autodocumentación, dependencias externas, impacto de patentes y mecanismos de protección técnica como el cifrado

SQLite y los formatos de almacenamiento recomendados por la Biblioteca del Congreso

Criterios para los formatos de almacenamiento recomendados

  • Los formatos de almacenamiento recomendados son aquellos que los especialistas en preservación de la Biblioteca del Congreso consideran que maximizan la viabilidad y el acceso continuo del contenido digital
  • La Biblioteca del Congreso considera los siguientes criterios al elegir formatos de almacenamiento recomendados

  • Apertura

    • Evalúa en qué medida existen especificaciones completas y herramientas para verificar la integridad técnica, y qué tan accesibles son para quienes crean y mantienen contenido digital
    • La documentación completa es más importante que la aprobación de un organismo de estandarización reconocido

  • Adopción

    • Evalúa en qué medida los principales creadores, distribuidores y usuarios de recursos de información ya utilizan ese formato
    • Esto incluye casos en los que se usa como formato maestro, formato de entrega al usuario final o medio de intercambio entre sistemas

  • Transparencia

    • Evalúa en qué medida la representación digital puede analizarse directamente con herramientas básicas, como si puede ser leída por una persona en un editor de texto plano

  • Autodocumentación

    • Un objeto digital autodocumentado incluye metadatos descriptivos básicos, metadatos técnicos y otros metadatos administrativos

  • Dependencias externas

    • Evalúa el grado en que la visualización o el uso depende de hardware, sistema operativo o software específicos, y la complejidad de manejar esa dependencia en futuros entornos tecnológicos

  • Impacto de patentes

    • Evalúa en qué medida las patentes interfieren con la capacidad de una institución de preservación para mantener contenido en ese formato

  • Mecanismos de protección técnica

    • Evalúa si se implementan mecanismos como el cifrado que impiden la preservación del contenido en repositorios confiables

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Comentarios en Hacker News

  • SQLite siempre me inspira. En general me encanta, pero si no vas a escribir datos, también puede ser una opción bastante excesiva
    Por eso, sin pretender reemplazar a SQLite, hice un formato que es mucho más ligero y rápido, y funciona incluso sobre archivos comprimidos con zstd
    El índice es muy pequeño y, como SQLite, puede contener binarios o texto
    La parte en wasm que se encarga de descomprimir, leer y buscar pesa 38 KB sin compresión y quizá unos 16 KB con gzip. Comparado con el wasm de SQLite y su glue code de 1.2 MB, es un 3% del tamaño, y aun así la búsqueda y la carga son mucho más rápidas
    Mi programa no es columnar ni sirve para manejar hojas de cálculo, pero encaja bien para diccionarios y archivos de imágenes o audio
    También porté un decodificador de jbig2 como módulo wasm de 17 KB, así que puede leer escaneos en blanco y negro de 8 KB por página y siguen siendo legibles
    https://github.com/tnelsond/peakslab
    SQLite está muy bien diseñado, y PeakSlab es muy simple

    • Dijiste “1.2 MB del wasm de SQLite y su glue code”, pero la forma estándar sin minificar en trunk actualmente es en realidad 1.7 MB. Casi la mitad es documentación embebida tanto como código JS, así que el WASM y el JS están casi mitad y mitad. Eso sí, minificado sí quedan en 1.2 MB
      Por cierto, yo soy el mantenedor
      En trunk ahora mismo los números son sqlite3.wasm 896745, sqlite3.mjs 816270 (sin minificar, con documentación), sqlite3.mjs 431388 (sin minificar, sin documentación), sqlite3.mjs 310975 (minificado)
    • No conocía PeakSlab, pero de verdad se ve genial y novedoso. El rendimiento para diccionarios también parece excelente, y vale la pena guardarlo en marcadores para volver a usarlo después
    • Esto se ve más cercano a competir con el viejo Berkeley DB: https://en.wikipedia.org/wiki/Berkeley_DB
      Viéndolo ahora, ya ni siquiera tiene licencia BSD y, en cualquier caso, prácticamente desapareció por SQLite, pero se usaba como almacén básico de clave-valor en disco
    • SQLite también es bastante simple a su manera, y me gustan los principios de diseño de su dialecto SQL
      Algo como “un right join no es más que un left join en la dirección opuesta, así que no hace falta”
      Claro que siempre se puede hacer algo más simple o más especializado. Muchas apps que usan base de datos funcionarían perfectamente solo con SQLite, y algunas probablemente bastarían con archivos de texto en lugar de una BD como SQLite
    • La solución más estándar probablemente sería cdb. Aunque no soporta datos comprimidos
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • Siempre me ha gustado SQLite, pero he oído que algunas empresas prohíben su uso
    La razón es que vuelve demasiado fácil crear bases de datos para apps, así que un componente ultracrítico de la aplicación termina viéndose como si fuera solo un archivo. Ese archivo puede tener cualquier extensión y hasta copiarse a otro servidor. Incluso si contiene información de identificación personal
    Si imaginas esta situación multiplicada por la cantidad de apps dentro de una empresa, puede volverse un caos considerable
    Los equipos de DevOps y DBA prefieren que la base de datos sea una máquina grande y pesada que cualquiera reconozca como servidor de bases de datos. Que el acto mismo de conectarse también sea obvio, etc.
    Aun así, SQLite me sigue encantando

    • Entonces me pregunto si esas mismas empresas también prohíben Excel. Las hojas de cálculo de Excel muchas veces terminan siendo bases de datos en la sombra en los lugares menos esperados
    • En cualquier conversación sobre “cualquier cosa puede convertirse en una base de datos de misión crítica”, este post debería ser lectura obligatoria
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • Si es “un archivo que puede tener cualquier extensión”, basta con leer el magic number. De todos modos nunca deberías confiar en la extensión del archivo
      Y eso de que “puede copiarse a otro servidor” también aplica a una hoja de cálculo
      No niego que el acceso centralizado a los datos sea deseable, pero esa lógica no me parece lo bastante sólida
    • SQLite también tiene usos interesantes como este: https://sqlite.org/sqlar.html
    • Por eso esos archivos de configuración se ponen en AppData, en un directorio dotfile, o en la ubicación equivalente dentro de ~/Library en MacOS

  • Antes pensaba que “SQLite es un producto de juguete y no se puede confiar en él para datos reales”, pero ahora me fui casi por completo al lado de “usemos SQLite para casi todo”
    Si puedes ajustarte al patrón de un solo escritor y muchos lectores, SQLite es excelente. Con la configuración correcta no pierdes datos, y esa configuración se encuentra con un minuto de búsqueda
    Hoy en día, la mayoría de mis apps son simplemente una combinación de binario Go + SQLite + archivo de servicio de systemd
    Aún no he perdido datos, el rendimiento es excelente y para la mayoría de las apps es más que suficiente

    • En la práctica, un solo escritor no es un problema tan grande como suele decirse. Los discos NVMe de hoy son impresionantes, y con una configuración de WAL optimizada sacar 5 mil escrituras por segundo es fácil. Muchísimo más de lo que la mayoría de las apps siquiera soñaría
      Incluso en un VPS común llegué a 180 mil escrituras por segundo con un patrón de escritor por lotes
    • Me da curiosidad si usas varios nodos de backend. Y si es así, también me da curiosidad cómo acceden al archivo SQLite desde nodos distintos

  • Dice “al momento de escribir esto (2018-05-29)...”, así que es una noticia de hace casi 8 años. Igual no es una queja, porque yo no lo sabía hasta ahora; más bien gracias por compartirla
    Por un momento mi cerebro matemático se descompuso y pensé que eran 6 años

    • Ahora estamos en 2026, así que fue hace 8 años
    • Mientras lo leía sentí un déjà vu

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

    • Si vas a guardar datos pensando en 300 a 500 años en el futuro, y quieres que sobrevivan tanto a toda clase de innovación como al envejecimiento básico de la tecnología, de verdad hace falta pensar a largo plazo
      ¿Cuál será el medio en papel que más tiempo ha sobrevivido?
    • El criterio de recomendación se ve bastante laxo. XLS aparece como “preferido”

  • Para la preservación de datos del sector público, SQLite puede ser una de las mejores opciones
    La especificación es pública, está ampliamente adoptado y es muy probable que siga pudiéndose leer en el futuro
    Tiene poca dependencia de un sistema operativo o servicio específico, y también bajo riesgo de patentes
    Desde la perspectiva de la durabilidad a largo plazo, es muy importante no depender de una empresa o servicio en particular

    • A los archivistas también les gustan los formatos cercanos al original. SQLite permite conservar tal cual las relaciones relacionales que serían difíciles de expresar en CSV

  • Me gusta SQLite y qué bueno que lo compartieron, pero al final del título debería decir “(2018)”
    Dice: “Al momento de escribir esto (2018-05-29), los otros formatos de almacenamiento recomendados para datasets son solo XML, JSON y CSV”

    • Como referencia, después de eso se agregaron muchos formatos a la lista
      Entre los formatos preferidos, se priorizan los formatos de texto independientes de la plataforma antes que los formatos nativos o binarios, siempre que los datos estén completos y conserven el detalle y la precisión. Se incluyen estándares de facto del mercado que estén bien desarrollados y ampliamente adoptados
      Por ejemplo, formatos basados en esquemas bien conocidos con herramientas públicas de validación, formatos orientados a líneas como TSV, CSV y ancho fijo, y formatos abiertos e independientes de la plataforma como .db, .db3, .sqlite y .sqlite3
      También se incluyen formatos propietarios que sean estándar de facto en una profesión específica o que estén soportados por múltiples herramientas. Por ejemplo, Excel .xls/.xlsx o Shapefile
      En codificación de caracteres, se prefieren UTF-8, UTF-16 con BOM, US-ASCII o ISO 8859-1, y luego otros encodings nombrados
      Como formatos aceptables, para datos están los formatos abiertos, documentados y no propietarios aprobados como estándar por comunidades especializadas o agencias gubernamentales (CDF, HDF, etc.), así como formatos de datos basados en texto con esquemas disponibles
      Para empaquetado o transferencia se aceptan ZIP, RAR, tar y 7z sin cifrado, contraseña ni otros mecanismos de protección
      https://www.loc.gov/preservation/resources/rfs/data.html

  • Justo ayer pensé que ya había pasado un tiempo desde la última vez que vi un post sobre SQLite en lo más alto de HN
    Me encanta de verdad la simplicidad y velocidad de SQLite, y la he usado tanto en proyectos personales como en el trabajo
    Aun así, en el trabajo diario termino yendo a Excel. No porque me guste más Excel, sino porque, de tan extendido que está, es la forma con menos fricción de compartir y explorar datasets con stakeholders menos técnicos o con ejecutivos

    • No creo que esto vaya a romper tu cosmovisión de golpe, pero quizá te sirva tanto como a mí, así que vale la pena echarle un ojo a Metabase
      Puedes alojarlo tú mismo, y si lo único que quieres es mostrar datos a stakeholders en una forma fácil de digerir, de verdad es muy simple. Claro, si te clavas demasiado podrías terminar arrepintiéndote de todas las decisiones de tu vida, pero yo trato de contenerme para no llegar a eso
      https://www.metabase.com/
    • Siempre me ha molestado que SQLite dependa de parsear texto para funcionar. No entiendo por qué las consultas tienen que escribirse como texto y no expresarse como lógica del programa
      Por eso nunca he usado una base de datos relacional. Es porque no me gustan. Sé que pueden rendir mejor que los datos puramente estructurados, pero odio SQL y la idea misma de SQL, y no quiero escribirlo, aprenderlo ni usar sistemas que dependan de él
      Me parece un enfoque tan equivocado como PHP. ¿Hay alguna forma de suavizar eso? No quiero seguir descartando SQLite por culpa de SQL, pero simplemente no logro aceptarlo. No me gusta tener que construir strings ni tener parsing de strings en ninguna parte del stack; simplemente se siente mal

  • SQLite es sorprendentemente versátil. Hace apenas unas semanas salió una extensión que implementa colas entre procesos, streams y publish/subscribe sobre SQLite
    Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    Las notificaciones en tiempo real eran una de las grandes piezas que faltaban para construir una app completa sobre un backend de SQLite, y ahora ya hay una solución bastante decente

  • Me gusta ver que SQLite reciba este nivel de reconocimiento institucional. Su formato de archivo único vuelve muchísimo más simple el almacenamiento archivístico que los volcados tradicionales de bases de datos