10GB의 텍스트 파일이 매일 다운로드되며 약 2억 줄이 있으며 그 중 약 1%가 다음날 변경됩니다. 매일 파일을 백업으로 보관하고 싶지만 CPU를 사용하여 디스크 공간을 절약하려고 합니다.
편집하다
지금까지 내가 찾은 가장 좋은 방법은 diff 파일을 유지하고 patch(@Simon이 제안한 대로) 1월 1일에 큰 파일을 다운로드한 다음 한 달 내내 diff 01jan.txt 02jan.txt > 02jan.diff; rm 02jan.txt매달 매일 diff를 수행하여 다시 작성하는 것입니다. 등.
더 좋은 방법이 있나요?
답변1
이것이 바로 Git, Bazaar 또는 Subversion과 같은 버전 제어 소프트웨어가 수행하는 작업입니다(몇 가지 추가 기능 포함). 따라서 작업 흐름은 다음과 같을 수 있습니다.
- 매월 초에 새 저장소를 만듭니다.
- 새 파일을 저장소에 복사하고 매일 변경 사항을 커밋합니다.
- (선택사항) 지난 달 저장소를 삭제합니다.
내 파일은 매달 크게 변경되지 않으며 매달 하나의 저장소만 사용합니다.
답변2
diff당신 이 프로그램에 대해 언급했듯이 , 나는 당신이 텍스트 파일에 대해 이야기하고 있다고 안전하게 추측할 수 있습니다...
2억 행 중 10GB라고 말씀하셨듯이 평균 행 길이가 50개인 단일 파일인 것 같은데 괜찮아 보입니다.
- 이 경우 버전 관리 시스템이 올바른 선택입니다.
문제에 적합한 버전 제어 시스템을 찾아야 합니다. 귀하의 정보를 가정해 보겠습니다.
- 매일 새로운 파일 버전이 있으며, 콘텐츠의 1%가 매일 변경됩니다.
파일 델타를 유지하지 않고 대신 gzip -4 압축된 전체 파일을 저장한다는 점 git을 고려하면 aprox. 2~3주 후에 git은 예상보다 더 많은 디스크 공간을 소비합니다. 따라서 git은 귀하의 상황에 적합한 도구가 아닙니다.
기록을 처리하기 위해 diff를 사용하는 다른 버전 제어 시스템이 있습니다.
RCS는 역방향 diff를 저장하며 해결책이 될 수 있지만 256KBytes를 초과하는 파일의 경우 RCS가 느립니다. 최신 버전이 필요하지 않고 이전 버전이 필요한 경우 RCS는 더 많은 시간이 걸립니다.
SCCS는 diff를 기반으로 하지만 저장 형식을 소위
weave format모든 버전을 동시에 효율적으로 저장하고 동일한 고정 시간에 모든 버전을 검색할 수 있도록 합니다.
SCCS는 초기 10GB 기록 파일을 생성합니다. 귀하의 경우 새 버전마다 1%씩 증가하므로 기록 파일에 aprox를 사용하고 싶습니다. 1년 후 36.5GB. GIT의 경우 1년 후 디스크 공간 요구 사항이 100~400GB가 될 것으로 예상합니다.
SCCS는 오픈 소스이며 다음에서 검색할 수 있습니다.
SCCS는 1972년(43년)부터 유지 관리되었으므로 성숙한 것으로 간주할 수 있습니다. ;-) 참고: 더 빠른 버전 제어 시스템은 모르겠습니다.
답변3
"패치"를 살펴보면 이는 커널 소스 코드를 다운로드할 때 거의 매일 직면하는 것과 동일한 문제입니다. 이는 원본 파일을 차등 파일로 업데이트하거나 이전 버전으로 되돌리는 데 사용할 수 있습니다.