Rebuild el file original de files diff para ahorrar espacio en el disco

Cada día se descarga un file de text de 10 GB, el file es ~ 200 millones de líneas y ~ 1% de las líneas se cambian al día siguiente. Quiero mantener files diarios como respaldo, pero estoy tratando de ahorrar espacio en disco usando la CPU.

EDITAR Actualmente, la mejor forma que encontré es mantener los files diff y rebuildlos con patch (cómo sugirió @Simon), por ejemplo, el 01 de enero descargue el file grande y luego durante todo un mes, siga haciendo solo diff diff 01jan.txt 02jan.txt > 02jan.diff; rm 02jan.txt diff 01jan.txt 02jan.txt > 02jan.diff; rm 02jan.txt y así sucesivamente para todos los días del mes.

¿Hay una mejor manera de hacer esto?

Este es exactamente el software de control de versiones de trabajo como Git, Bazaar o Subversion (más un poco más). Por lo tanto, su flujo de trabajo podría ser el siguiente:

  • Al comienzo de un mes, crea un nuevo repository.
  • Cada día copie nuevos files en el repository y comprometa los cambios
  • Opcionalmente, elimine el repository del mes pasado.

Los files no cambian mucho de mes a mes, solo funcionan con un repository por cada mes.

Como mencionó el progtwig diff , puedo suponer con security que está hablando de files de text …

Como mencionas 10 GB en 200 millones de líneas, este parece ser un file único con una longitud de línea promedio de 50 que se ve bien.

  • En tal situación, un sistema de control de versiones es el path correcto a seguir.

Necesita encontrar el sistema de control de versión correcto para su problema. Déjame así asumir tu información:

  • Una nueva versión de file todos los días y el 1% del contenido cambia día a día.

Dado que git no mantiene los deltas de files sino que almacena los files completos comprimidos de gzip -4, espero que después de aprox. 2-3 semanas, git consumirá más espacio de disco de lo esperado. Entonces, git no es la herramienta adecuada para tu caso.

Existen otros sistemas de control de versiones que usan diferencias para su método de event handling historial.

  • Las tiendas RCS revirtieron diffs y podrían ser una solución, pero RCS es lento para files> 256KBytes y RCS tarda más time si no necesita la última versión, sino algo más antiguo.

  • SCCS se basa en diffs, pero el formatting de almacenamiento es el llamado weave format que almacena de manera efectiva todas las versiones al mismo time y le permite recuperar cualquier versión en el mismo time fijo.

SCCS creará un file de historial inicial de 10 GB y este file de historial crecerá un 1% por cada nueva versión en su caso, por lo que espero que el file de historial use aprox. 36.5GB después de un año. Para GIT, espero un requisito de espacio en disco de 100-400 GB después de un año.

SCCS es OpenSource y se puede recuperar desde:

http://sccs.sourceforge.net

SCCS se mantiene desde 1972 (43 años) y por lo tanto se puede ver como maduro 😉 y por cierto: no conozco un sistema de control de versiones más rápido.

Eche un vistazo al 'parche', ya que era el mismo problema que teníamos al download el código fuente del núcleo casi a diario. Esto se puede utilizar para actualizar el file original o volver a las versiones anteriores con los files diff.