Cách sao chép cơ sở dữ liệu SQLite giữa các máy tính nhanh hơn
(alexwlchan.net)Mở đầu
- Nếu sao chép trực tiếp cơ sở dữ liệu SQLite bằng rsync, kích thước tệp có thể lớn do chỉ mục và các thành phần khác, khiến quá trình chậm và kém ổn định.
- Vì vậy, một phương pháp dùng
.dumpđể nén và khôi phục dưới dạng văn bản được đề xuất.
Nội dung chính
-
Lệnh
.dumpxuất toàn bộ DB thành văn bản SQL, còn chỉ mục được thay thế bằng một dòng lệnh, giúp kích thước tệp nhỏ hơn.sqlite3 my_database.db .dump > my_database.db.txt -
Tệp văn bản có thể giảm dung lượng thêm khi nén bằng gzip:
sqlite3 my_database.db .dump | gzip -c > my_database.db.txt.gz -
Quy trình được chuyển thành tạo bản nén trên máy chủ, sao chép về máy cục bộ rồi khôi phục:
ssh username@server "sqlite3 db.db .dump | gzip -c > db.txt.gz" rsync --progress username@server:db.txt.gz . gunzip db.txt.gz cat db.txt | sqlite3 restored.db -
Tệp DB gốc 3.4GB → văn bản dump 1.3GB → bản gzip 240MB, giảm khoảng 14 lần.
-
Cách dùng rsync truyền thống có thể phát sinh lỗi
database disk image is malformednếu DB thay đổi trong lúc truyền. -
Cách dump ra văn bản không có rủi ro nội dung thay đổi sau khi bắt đầu sao chép, nên có thể tạo bản sao lưu nhất quán.
Kết luận
- Cách dùng
.dump+ nén + khôi phục giúp cải thiện cả tốc độ lẫn độ ổn định khi truyền SQLite dung lượng lớn. - Đặc biệt hiệu quả với các DB có nhiều chỉ mục và có thể giảm khả năng truyền lỗi hoặc hỏng dữ liệu.
- Đây là một cách tối ưu thực tế đáng áp dụng nếu bạn thường xuyên xử lý SQLite dung lượng lớn.
2 bình luận
Mình tò mò về bối cảnh vì sao lại cần làm công việc này.
Trong bài gốc có nói là để sao lưu và phân tích. Có lẽ họ muốn phân tích cục bộ bằng thứ như duckdb chăng.