▲

컴퓨터 간 SQLite 데이터베이스를 더 빠르게 복사하는 방법

 (alexwlchan.net)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • SQLite 데이터베이스를 컴퓨터 간에 복사하는 더 빠른 방법에 대한 설명임
  • 데이터베이스의 인덱스가 복사 속도를 느리게 하는 주요 원인임
  • SQLite의 .dump 명령어를 사용하여 데이터베이스를 텍스트 파일로 덤프할 수 있음
  • 텍스트 파일은 원본 데이터베이스보다 작으며, 압축하면 더욱 작아짐
  • 이 방법은 대용량 데이터베이스를 더 빠르고 안정적으로 복사할 수 있게 해줌

SQLite 데이터베이스를 컴퓨터 간에 더 빠르게 복사하는 방법

  • 원격 서버에 저장된 SQLite 데이터베이스를 로컬 컴퓨터로 복사하는 방법에 대한 설명임
  • 초기 프로젝트에서는 rsync 명령어를 사용하여 간단히 복사할 수 있음
  • 데이터베이스가 커지면 복사 속도가 느려지고 신뢰성이 떨어짐

데이터베이스 덤프를 텍스트 파일로 만들기

  • SQLite는 .dump 명령어를 사용하여 데이터베이스를 텍스트 파일로 덤프할 수 있음
  • 이 텍스트 파일은 SQL 문으로 구성되어 있으며, 원본 데이터베이스보다 작을 수 있음
  • 인덱스는 텍스트 파일에서 단일 라인으로 줄어들어 저장 공간을 절약할 수 있음

압축을 통한 저장 공간 절약

  • 텍스트 파일은 압축하면 더 작아짐
  • 예를 들어, 원본 SQLite 데이터베이스가 3.4GB인 경우, gzip으로 압축한 텍스트 파일은 240MB로 줄어듦
  • 압축된 텍스트 파일을 다운로드하면 데이터베이스 복사가 훨씬 빨라짐

새로운 ssh+rsync 명령어

  • 서버에서 gzip으로 압축된 텍스트 파일을 생성하고 로컬 컴퓨터로 복사한 후 데이터베이스를 재구성함
  • 서버에서 압축된 텍스트 파일을 생성: ssh username@server "sqlite3 my_remote_database.db .dump | gzip -c > my_remote_database.db.txt.gz"
  • 로컬 컴퓨터로 파일 복사: rsync --progress username@server:my_remote_database.db.txt.gz my_local_database.db.txt.gz
  • 압축 해제 및 데이터베이스 재구성 후 로컬 파일 삭제

데이터베이스 덤프는 안정적인 복사 소스임

  • 데이터베이스 복사 중 업데이트가 발생하면 rsync가 잘못된 데이터베이스 파일을 생성할 수 있음
  • 텍스트 덤프를 생성하여 안정적인 복사 소스를 제공함으로써 이러한 문제를 해결할 수 있음
  • 이 방법은 대용량 데이터베이스 작업 시 시간을 절약하고 다운로드를 더 빠르고 신뢰성 있게 만들어 줌
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • SQLite는 공식 도구를 제공함. 페이지 수준에서 작동하며, 복제본이 각 페이지의 암호화 해시를 원본 측에 보내고, 해시가 일치하지 않는 페이지의 전체 내용을 원본이 다시 보냄
  • 실행 중인 데이터베이스 파일을 복사하면 손상될 수 있음. 안전한 복제를 위해 Litestream을 사용할 수 있음
  • 데이터베이스를 컴퓨터 간에 복사하는 방법으로는 원을 보내고 나머지 부분은 무시하는 방법이 있음
    • 증분 rsync가 더 빠르지만, SQL 문을 보내는 것이 데이터베이스를 보내는 것보다 빠르다는 주장에 동의하지 않음. SQL 문을 실행하고 최적화 및 진공 작업을 수행해야 함
    • CSV 파일에서 데이터베이스를 "증분적으로 재구축"해야 하는 시나리오가 있음. 데이터베이스를 처음부터 다시 만드는 것이 더 최적이지만, 메모리 내 빈 데이터베이스에 배치 삽입을 실행하는 데만 30분이 걸림
  • 최근에 출시된 sqlite_rsync 유틸리티는 SQLite 데이터베이스의 내부 구조에 최적화된 rsync 알고리즘 버전을 사용함. 내부 데이터 페이지를 효율적으로 비교하고 변경되거나 누락된 페이지만 동기화함
  • 텍스트 파일로 저장하는 것은 비효율적임. VACUUM INTO를 사용하여 sqlite 데이터베이스를 저장함
    • VACUUM 명령어는 백업 API의 대안으로, 결과 백업 데이터베이스가 최소 크기여서 파일 시스템 I/O가 줄어듦
  • rsync가 제공하는 압축 기능을 사용하지 않은 것이 놀라움. gzip으로 압축한 후 전송하는 것이 더 빠를 수 있음
  • DuckDB에서는 Parquet로 내보내어 데이터 크기를 줄일 수 있음. 전송 및 로드 속도가 더 빠름
  • SQLite는 세션 확장을 제공하여 테이블의 변경 사항을 추적하고 이전 버전의 SQLite 데이터베이스를 패치할 수 있는 변경 집합/패치 집합을 생성함
  • gzip의 "--rsyncable" 옵션을 사용하여 최적화할 수 있음. 압축을 약간 줄이지만 차이점을 국지화하여 전체 압축 출력에 영향을 주지 않음
    • 덤프 출력의 압축을 건너뛰고 rsync가 이전 비압축 덤프와 현재 덤프의 차이점을 계산하도록 한 후, rsync가 네트워크를 통해 전송하는 변경 집합을 압축하도록 할 수 있음
  • 2008년에 Postgres를 사용하여 여러 기계에 백업을 전송해야 했던 경험이 있음. 네트워크가 포화 상태가 되어 udpcast를 사용하여 백업을 한 번에 모든 목적지로 전송함
답변달기