1 puntos por GN⁺ 2025-05-02 | 1 comentarios | Compartir por WhatsApp
  • Explica una forma más rápida de copiar una base de datos SQLite entre computadoras
  • Los índices de la base de datos son la causa principal de que la copia sea lenta
  • Puedes volcar la base de datos a un archivo de texto usando el comando .dump de SQLite
  • El archivo de texto es más pequeño que la base de datos original, y al comprimirlo se reduce aún más
  • Este método permite copiar bases de datos grandes de forma más rápida y confiable

Cómo copiar una base de datos SQLite entre computadoras más rápido

  • Explica cómo copiar una base de datos SQLite almacenada en un servidor remoto a una computadora local
  • En proyectos iniciales, se puede copiar fácilmente usando el comando rsync
  • A medida que la base de datos crece, la velocidad de copia disminuye y la confiabilidad empeora

Crear un volcado de la base de datos como archivo de texto

  • SQLite permite volcar una base de datos a un archivo de texto usando el comando .dump
  • Este archivo de texto está compuesto por sentencias SQL y puede ser más pequeño que la base de datos original
  • Los índices se reducen a una sola línea en el archivo de texto, lo que puede ahorrar espacio de almacenamiento

Ahorrar espacio con compresión

  • El archivo de texto se hace aún más pequeño al comprimirlo
  • Por ejemplo, si la base de datos SQLite original mide 3.4GB, el archivo de texto comprimido con gzip se reduce a 240MB
  • Descargar el archivo de texto comprimido hace que copiar la base de datos sea mucho más rápido

Nuevo comando ssh+rsync

  • En el servidor, se genera un archivo de texto comprimido con gzip, se copia a la computadora local y luego se reconstruye la base de datos
  • Crear el archivo de texto comprimido en el servidor: ssh username@server "sqlite3 my_remote_database.db .dump | gzip -c > my_remote_database.db.txt.gz"
  • Copiar el archivo a la computadora local: rsync --progress username@server:my_remote_database.db.txt.gz my_local_database.db.txt.gz
  • Descomprimir y reconstruir la base de datos, luego eliminar el archivo local

El volcado de la base de datos es una fuente de copia confiable

  • Si ocurren actualizaciones mientras se copia la base de datos, rsync puede generar un archivo de base de datos incorrecto
  • Crear un volcado de texto resuelve este problema al proporcionar una fuente de copia estable
  • Este método ahorra tiempo al trabajar con bases de datos grandes y hace que las descargas sean más rápidas y confiables

1 comentarios

 
GN⁺ 2025-05-02
Comentarios de Hacker News
  • SQLite ofrece una herramienta oficial. Funciona a nivel de página: la réplica envía al origen un hash criptográfico de cada página, y el origen vuelve a enviar el contenido completo de las páginas cuyo hash no coincide
  • Copiar un archivo de base de datos mientras está en ejecución puede corromperlo. Para una replicación segura, se puede usar Litestream
  • Una forma de copiar una base de datos entre computadoras es enviar el círculo y omitir el resto
    • El rsync incremental es más rápido, pero no están de acuerdo con la afirmación de que enviar sentencias SQL sea más rápido que enviar la base de datos. Hay que ejecutar las sentencias SQL y realizar tareas de optimización y vacuum
    • Hay escenarios en los que se debe "reconstruir incrementalmente" una base de datos a partir de un archivo CSV. Recrear la base de datos desde cero es más óptimo, pero solo ejecutar inserciones por lotes en una base de datos vacía en memoria ya toma 30 minutos
  • La utilidad sqlite_rsync, lanzada recientemente, usa una versión del algoritmo de rsync optimizada para la estructura interna de las bases de datos SQLite. Compara eficientemente las páginas de datos internas y sincroniza solo las páginas modificadas o faltantes
  • Guardarlo como archivo de texto es ineficiente. Se usa VACUUM INTO para guardar la base de datos sqlite
    • El comando VACUUM es una alternativa a la API de respaldo, y la base de datos de respaldo resultante queda con el tamaño mínimo, lo que reduce el I/O del sistema de archivos
  • Sorprende que no se haya usado la función de compresión que ofrece rsync. Comprimir con gzip antes de transferir podría ser más rápido
  • En DuckDB, se puede exportar a Parquet para reducir el tamaño de los datos. La transferencia y la carga son más rápidas
  • SQLite ofrece la extensión de sesiones para rastrear cambios en tablas y generar conjuntos de cambios/parches que permiten aplicar parches a versiones anteriores de una base de datos SQLite
  • Se puede optimizar usando la opción --rsyncable de gzip. Reduce un poco la compresión, pero localiza las diferencias para que no afecten toda la salida comprimida
    • Se puede omitir la compresión de la salida del dump y dejar que rsync calcule las diferencias entre el dump sin comprimir anterior y el actual, y luego hacer que rsync comprima el conjunto de cambios que envía por la red
  • Hay experiencia de 2008 en la que se usó Postgres para enviar respaldos a varias máquinas. La red se saturaba, así que se usó udpcast para enviar el respaldo a todos los destinos de una sola vez