कंप्यूटरों के बीच SQLite डेटाबेस को तेज़ी से कॉपी करने का तरीका

परिचय

• SQLite डेटाबेस को सीधे rsync से कॉपी करने पर, इंडेक्स आदि की वजह से फ़ाइल का आकार बड़ा हो जाता है, जिससे यह धीमा और अस्थिर हो सकता है।
• इसलिए .dump का उपयोग करके टेक्स्ट-आधारित compression और restore का तरीका सुझाया गया है।

मुख्य भाग

• .dump कमांड पूरे DB को SQL टेक्स्ट के रूप में आउटपुट करती है, और इंडेक्स एक कमांड लाइन से बदल दिए जाते हैं, जिससे फ़ाइल का आकार छोटा हो जाता है।

  sqlite3 my_database.db .dump > my_database.db.txt  
  

• टेक्स्ट फ़ाइल को gzip से compress करने पर आकार और कम किया जा सकता है:

  sqlite3 my_database.db .dump | gzip -c > my_database.db.txt.gz  
  

• प्रक्रिया को इस तरह बदला जाता है कि सर्वर पर compressed फ़ाइल बनाई जाए, फिर उसे लोकल में कॉपी करके restore किया जाए:

  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  
  

• मूल DB फ़ाइल 3.4GB → dump टेक्स्ट 1.3GB → gzip compressed फ़ाइल 240MB, यानी लगभग 14 गुना कमी।

• मौजूदा rsync तरीके में, अगर ट्रांसफ़र के दौरान DB बदल जाए तो database disk image is malformed त्रुटि आ सकती है।

• टेक्स्ट dump तरीके में कॉपी शुरू होने के बाद कंटेंट बदलने का जोखिम नहीं रहता, इसलिए ज़्यादा consistent backup संभव होता है।

निष्कर्ष

• .dump + compression + restore तरीका बड़े SQLite ट्रांसफ़र में speed और reliability दोनों बेहतर करता है।
• यह खास तौर पर उन DB के लिए असरदार है जिनमें बहुत सारे इंडेक्स होते हैं, और ट्रांसफ़र फेल होने या corruption की संभावना कम कर सकता है।
• अगर आप बड़े SQLite डेटाबेस को अक्सर संभालते हैं, तो यह अपनाने लायक एक व्यावहारिक optimization तरीका है।

[ng0301]

मुझे यह जानने की उत्सुकता है कि इस काम की ज़रूरत क्यों है।

[winterjung]

मूल लेख में कहा गया है कि यह बैकअप और विश्लेषण के लिए है। शायद वे लोकल में duckdb जैसी किसी चीज़ से विश्लेषण करना चाहते थे।