rqlite 9.0 का विकास जारी - डिस्क उपयोग आधा करने की दिशा में

• rqlite, Go में लिखा गया एक हल्का open source distributed relational database है
• यह Raft consensus protocol पर आधारित है और SQLite को storage engine के रूप में उपयोग करता है
• 9.0 का विकास शुरू हो चुका है और इसका लक्ष्य डिस्क उपयोग को लगभग 50% तक कम करना है
• यह लक्ष्य rqlite के डिस्क खपत के मुख्य कारणों को हटाने वाले high-level design बदलाव के जरिए हासिल किया जाएगा

अभी डिस्क उपयोग का सबसे बड़ा हिस्सा किसमें जाता है?

• Raft log:
  • सिस्टम में हुए बदलावों का log
  • यह log Raft consensus system का core है
• working SQLite database:
  • live database, जिसका उपयोग rqlite read और write उपलब्ध कराने के लिए करता है
  • जब SQLite statement सफलतापूर्वक Raft log में commit हो जाता है, तो वह statement working SQLite database पर apply किया जाता है
• working SQLite database का snapshot:
  • Raft log को अनंत तक बढ़ने से रोकने के लिए rqlite के भीतर का Raft subsystem समय-समय पर working SQLite database की point-in-time copy बनाकर स्टोर करता है
  • इस copy को snapshot कहा जाता है
  • snapshot बन जाने के बाद rqlite, Raft log को truncate कर सकता है
  • यह snapshotted copy node restart होने पर rqlite द्वारा node restore करने में उपयोग होती है, या तब उस node को भेजी जाती है जब कोई दूसरा node मौजूदा rqlite cluster की state को "catch up" करना चाहता है
  • snapshot creation और log truncation, Raft-आधारित systems की core concepts हैं

rqlite 9.0 के लिए high-level design

• डिस्क उपयोग कम करने की मुख्य रणनीति यह है कि Raft system में working SQLite database की snapshotted copy को स्टोर करने की जरूरत ही खत्म कर दी जाए
• snapshot creation के कारण Raft log समय-समय पर truncate हो जाता है और एक बिंदु के बाद बढ़ना बंद कर देता है, लेकिन working SQLite database, अधिक data लिखे जाने के साथ बढ़ता रहता है
• और SQLite database की snapshot copy लगभग working SQLite database जितनी ही बड़ी होती है, इसलिए उसका आकार भी बढ़ता है
• इसलिए यदि snapshot copy हटाई जा सके, तो rqlite 50% कम डिस्क उपयोग करेगा
• लेकिन rqlite node को किसी न किसी समय snapshotted copy की जरूरत पड़ती है। इससे बचा नहीं जा सकता।
• तो फिर copy को छोड़े बिना snapshot creation और restore की जरूरत कैसे पूरी की जाए?
• यह समझने के लिए कि snapshot process में अतिरिक्त copy स्टोर किए बिना इससे कैसे बचा जा सकता है, यह जानना महत्वपूर्ण है कि rqlite underlying SQLite database को Write-Ahead Log(WAL) mode में चलाता है
• प्रस्तावित 9.0 design में working SQLite database file (संबंधित WAL file को छोड़कर) और Raft system की snapshotted copy तार्किक रूप से समान हैं
• इसी तथ्य का उपयोग करके Raft system में अलग से snapshotted copy स्टोर करने की आवश्यकता खत्म की जा सकती है

snapshot creation के लिए नया approach

• snapshot creation और WAL checkpointing:
  • snapshot creation के समय rqlite, working SQLite database के Write-Ahead Log(WAL) को checkpoint करता है
  • इसके बाद के सभी write एक नई WAL file में जाते हैं, जिससे मुख्य SQLite file snapshot बनने के समय से अपरिवर्तित बनी रहती है
  • नतीजतन, अगला snapshot होने तक मुख्य SQLite file वही point-in-time state दर्शाती है जिसकी Raft snapshot store को जरूरत होती है
  • इस approach से सामान्य read और write operations के लिए संयुक्त SQLite file और WAL file का उपयोग होता है, जबकि अपरिवर्तित मुख्य SQLite file, Raft snapshot store के data set की भूमिका निभाती है
  • अब किसी अतिरिक्त copy की जरूरत नहीं रहती!
• snapshot store में reference लिखना:
  • पूरी SQLite file कॉपी करने के बजाय rqlite, checksum जैसे reference को snapshot store में लिखता है
  • जब भी snapshot data की जरूरत पड़े, यह reference यह सत्यापित करने के लिए उपयोग किया जा सकता है कि मुख्य SQLite file, snapshot store द्वारा referenced data से मेल खाती है
    • (यह verification bug, operational mistake, या disk corruption से बचाव करता है, हालांकि यह सख्ती से आवश्यक नहीं है)
• snapshot से restore:
  • जैसा पहले बताया गया, snapshot process के बाद के सभी write WAL file में जाते हैं, इसलिए मुख्य SQLite file node restart के समय या snapshot को दूसरे node पर भेजते समय snapshot restore process के लिए तैयार रहती है
  • यानी मुख्य SQLite file (संबंधित WAL file को नजरअंदाज करते हुए) तार्किक रूप से वैसी ही बनी रहती है जैसी वह तब होती यदि rqlite वास्तव में duplicate copy बनाकर Raft snapshot store में लिखता
• इस नए design को "reference snapshot" कहा जाता है

bonus improvements

• reference snapshot कुछ और महत्वपूर्ण सुधार भी लाएगा
• तेज snapshot creation: Raft snapshot store में बहुत कम data लिखा जाएगा, इसलिए snapshot process काफी तेज होगा
  • इसमें SQLite WAL checkpoint time (जो सामान्यतः बहुत कम होता है) और checksum calculate करने का समय शामिल होगा
  • हर snapshot creation पर बड़ी मात्रा में SQLite data को snapshot store में कॉपी करने की जरूरत नहीं होगी
  • जब यह पता हो कि snapshot process के दौरान rqlite पर write block हो जाते हैं, तब तेज snapshot का लाभ और स्पष्ट हो जाता है
• तेज restart: कई gigabyte SQLite data वाले node भी काफी तेजी से restart होंगे
  • अभी restart के समय rqlite को Raft snapshot store की copy से working SQLite database file restore करनी पड़ती है
  • लेकिन इस नए design में startup के समय working SQLite database file पहले से ही सही स्थान पर होगी
  • अधिकतम स्थिति में rqlite को सिर्फ snapshot store के checksum की तुलना working SQLite database के checksum से करनी होगी
  • multi-GB systems कुछ ही सेकंड में restart हो जाने चाहिए

अगले कदम

• rqlite 9.0 की ओर यह बदलाव, rqlite की efficiency को optimize करने की दिशा में एक महत्वपूर्ण कदम होगा
• reference snapshot को लागू करके डिस्क उपयोग में बड़ी कमी, snapshot creation की अधिक गति, और node restart time में सुधार की उम्मीद है
• SQLite WAL management, पुराने release से seamless upgrade, checksum selection जैसी कई details हैं जिन्हें सही तरीके से संभालना होगा
• इसलिए इस बड़े release की दिशा में आगे बढ़ते हुए आगे के updates पर नजर बनाए रखें

[xguru]

rqlite - SQLite पर आधारित हल्का distributed database