वेब पर स्टोरेज की सभी ज़रूरतों को बेहतर तरीके से मैनेज करने के लिए, SQLite का इस्तेमाल करें.
SQLite एक लोकप्रिय, ओपन-सोर्स, लाइटवेट, और एम्बेड किया गया रिलेशनल डेटाबेस मैनेजमेंट सिस्टम है. कई डेवलपर इसका इस्तेमाल, डेटा को व्यवस्थित और आसानी से इस्तेमाल किए जा सकने वाले तरीके से सेव करने के लिए करते हैं. SQLite का साइज़ छोटा होता है और इसके लिए कम मेमोरी की ज़रूरत होती है. इसलिए, मोबाइल डिवाइसों, डेस्कटॉप ऐप्लिकेशन, और वेब ब्राउज़र में अक्सर इसे डेटाबेस इंजन के तौर पर इस्तेमाल किया जाता है.
SQLite की एक मुख्य सुविधा यह है कि यह सर्वरलेस डेटाबेस है. इसका मतलब है कि इसे काम करने के लिए, अलग से सर्वर प्रोसेस की ज़रूरत नहीं होती. इसके बजाय, डेटाबेस को उपयोगकर्ता के डिवाइस पर एक फ़ाइल में सेव किया जाता है. इससे, इसे ऐप्लिकेशन में इंटिग्रेट करना आसान हो जाता है.
वेब असेंबली पर आधारित SQLite
वेब असेंबली (Wasm) पर आधारित SQLite के कई अनऑफिशियल वर्शन हैं. इनकी मदद से, SQLite को वेब ब्राउज़र में इस्तेमाल किया जा सकता है. उदाहरण के लिए, sql.js. sqlite3 WASM/JS सब-प्रोजेक्ट, SQLite प्रोजेक्ट से आधिकारिक तौर पर जुड़ा पहला प्रोजेक्ट है. इस प्रोजेक्ट में, लाइब्रेरी के WASM बिल्ड बनाए जा रहे हैं. ये बिल्ड, SQLite के काम करने वाले डिलीवरबल के परिवार के सदस्य हैं. इस प्रोजेक्ट के खास लक्ष्यों में ये शामिल हैं:
- कम लेवल के sqlite3 API को बांधना, जो इस्तेमाल के लिहाज़ से C के जितने करीब हो सके.
- यह एक बेहतर लेवल का ऑब्जेक्ट-ओरिएंटेड एपीआई है. यह sql.js और Node.js-स्टाइल के लागू होने से मिलता-जुलता है. यह सीधे तौर पर लो-लेवल एपीआई से जुड़ा होता है. इस एपीआई का इस्तेमाल, उसी थ्रेड से किया जाना चाहिए जिससे लो-लेवल एपीआई का इस्तेमाल किया जाता है.
- Worker पर आधारित एपीआई, जो Worker मैसेज के ज़रिए पिछले एपीआई से बात करता है. इस एपीआई का इस्तेमाल मुख्य थ्रेड में किया जाता है. इसमें, Worker थ्रेड में इंस्टॉल किए गए निचले लेवल के एपीआई और Worker मैसेज के ज़रिए उनसे बातचीत की जाती है.
- Worker API का एक वादा-आधारित वैरिएंट, जो उपयोगकर्ता से क्रॉस-थ्रेड कम्यूनिकेशन के पहलुओं को पूरी तरह से छिपा देता है.
- उपलब्ध JavaScript API का इस्तेमाल करके, क्लाइंट-साइड पर स्टोरेज को हमेशा के लिए सेव रखने की सुविधा. इसमें ऑरिजिन प्राइवेट फ़ाइल सिस्टम (OPFS) भी शामिल है.
Origin के निजी फ़ाइल सिस्टम के पर्सिस्टेंस बैकएंड के साथ SQLite Wasm का इस्तेमाल करना
npm से लाइब्रेरी इंस्टॉल करना
इस कमांड का इस्तेमाल करके, npm से @sqlite.org/sqlite-wasm पैकेज इंस्टॉल करें:
npm install @sqlite.org/sqlite-wasm
Origin का निजी फ़ाइल सिस्टम
ऑरिजिन प्राइवेट फ़ाइल सिस्टम (ओपीएफ़एस, फ़ाइल सिस्टम ऐक्सेस एपीआई का हिस्सा) को एक खास प्लैटफ़ॉर्म के साथ जोड़ा गया है. इससे डेटा को तेज़ी से ऐक्सेस किया जा सकता है. यह नया प्लैटफ़ॉर्म, मौजूदा प्लैटफ़ॉर्म से अलग है. इसमें, फ़ाइल के कॉन्टेंट में बदलाव करने का ऐक्सेस, फ़ाइल के मौजूदा वर्शन में ही दिया जाता है. इस बदलाव के साथ-साथ, बिना फ़्लश किए गए बदलावों को लगातार पढ़ने की सुविधा और खास वर्कर्स पर सिंक्रोनस वैरिएंट की उपलब्धता, परफ़ॉर्मेंस को काफ़ी बेहतर बनाती है. साथ ही, नए इस्तेमाल के उदाहरणों को अनब्लॉक करती है.
जैसा कि आपने सोचा होगा, प्रोजेक्ट के लक्ष्यों में मौजूद आखिरी पॉइंट, उपलब्ध JavaScript एपीआई का इस्तेमाल करके, क्लाइंट-साइड के स्टोरेज को बनाए रखने की सुविधा के लिए, डेटाबेस फ़ाइल में डेटा को बनाए रखने से जुड़ी परफ़ॉर्मेंस की सख्त ज़रूरी शर्तें हैं.
यहां Origin का निजी फ़ाइल सिस्टम और खास तौर पर, FileSystemFileHandle ऑब्जेक्ट के createSyncAccessHandle() तरीके का इस्तेमाल किया जाता है. यह तरीका एक प्रॉमिस दिखाता है, जो FileSystemSyncAccessHandle ऑब्जेक्ट में बदल जाता है. इसका इस्तेमाल, फ़ाइल को सिंक्रोनस तरीके से पढ़ने और उसमें लिखने के लिए किया जा सकता है. इस तरीके के सिंक होने की वजह से परफ़ॉर्मेंस में फ़ायदे मिलते हैं. हालांकि, इसलिए इसका इस्तेमाल सिर्फ़ ऑरिजिन प्राइवेट फ़ाइल सिस्टम में मौजूद फ़ाइलों के लिए, खास वेब वर्कर्स में किया जा सकता है, ताकि मुख्य थ्रेड को ब्लॉक न किया जा सके.
ज़रूरी हेडर सेट करना
डाउनलोड किए गए SQLite Wasm संग्रह में, अन्य फ़ाइलों के साथ-साथ sqlite3.js और sqlite3.wasm फ़ाइलें भी शामिल होती हैं. इनसे sqlite3 WASM/JS बिल्ड बनता है. jswasm डायरेक्ट्री में, sqlite3 की मुख्य डिलीवरबल शामिल होती हैं. साथ ही, टॉप-लेवल डायरेक्ट्री में, डेमो और टेस्ट ऐप्लिकेशन शामिल होते हैं. ब्राउज़र, file:// यूआरएल से Wasm फ़ाइलें नहीं दिखाएंगे. इसलिए, इसकी मदद से बनाए गए किसी भी ऐप्लिकेशन के लिए वेब सर्वर की ज़रूरत होती है. साथ ही, उस सर्वर को फ़ाइलें दिखाते समय, अपने रिस्पॉन्स में ये हेडर शामिल करने होंगे:
Cross-Origin-Opener-Policyकोsame-originनिर्देश पर सेट किया गया है, जो ब्राउज़िंग कॉन्टेक्स्ट को सिर्फ़ एक ही ऑरिजिन के दस्तावेज़ों के लिए अलग करता है. क्रॉस-ऑरिजिन दस्तावेज़, एक ही ब्राउज़िंग कॉन्टेक्स्ट में लोड नहीं होते.Cross-Origin-Embedder-Policyकोrequire-corpडायरेक्टिव पर सेट किया गया हो, ताकि दस्तावेज़ सिर्फ़ उसी ऑरिजिन से रिसॉर्स लोड कर सके या ऐसे रिसॉर्स लोड कर सके जिन्हें साफ़ तौर पर किसी दूसरे ऑरिजिन से लोड किए जाने के तौर पर मार्क किया गया हो.
इन हेडर की वजह यह है कि SQLite Wasm, SharedArrayBuffer पर निर्भर करता है. साथ ही, इन हेडर को सेट करना, सुरक्षा से जुड़ी ज़रूरी शर्तों का हिस्सा है.
DevTools की मदद से ट्रैफ़िक की जांच करने पर, आपको यह जानकारी दिखेगी:
Speedtest
SQLite टीम ने वेब एसक्यूएल की तुलना में, वेबअसेम्बली को लागू करने के लिए कुछ मानदंड तय किए हैं. इन बेंचमार्क से पता चलता है कि SQLite Wasm, आम तौर पर वेब एसक्यूएल के बराबर ही तेज़ है. कभी-कभी यह थोड़ा धीमा होता है, कभी-कभी थोड़ा तेज़. नतीजों के पेज पर पूरी जानकारी देखें.
शुरू करने के लिए कोड का सैंपल
जैसा कि हमने पहले बताया था, Origin Private File System के साथ काम करने वाले SQLite Wasm के डेटा को सेव करने वाले बैकएंड को Worker कॉन्टेक्स्ट से चलाना ज़रूरी है. अच्छी बात यह है कि लाइब्रेरी, इन सभी कामों को अपने-आप मैनेज करती है. साथ ही, इसका इस्तेमाल मुख्य थ्रेड से किया जा सकता है.
import { sqlite3Worker1Promiser } from '@sqlite.org/sqlite-wasm';
(async () => {
try {
console.log('Loading and initializing SQLite3 module...');
const promiser = await new Promise((resolve) => {
const _promiser = sqlite3Worker1Promiser({
onready: () => {
resolve(_promiser);
},
});
});
console.log('Done initializing. Running demo...');
let response;
response = await promiser('config-get', {});
console.log('Running SQLite3 version', response.result.version.libVersion);
response = await promiser('open', {
filename: 'file:worker-promiser.sqlite3?vfs=opfs',
});
const { dbId } = response;
console.log(
'OPFS is available, created persisted database at',
response.result.filename.replace(/^file:(.*?)\?vfs=opfs$/, '$1'),
);
await promiser('exec', { dbId, sql: 'CREATE TABLE IF NOT EXISTS t(a,b)' });
console.log('Creating a table...');
console.log('Insert some data using exec()...');
for (let i = 20; i <= 25; ++i) {
await promiser('exec', {
dbId,
sql: 'INSERT INTO t(a,b) VALUES (?,?)',
bind: [i, i * 2],
});
}
console.log('Query data with exec()');
await promiser('exec', {
dbId,
sql: 'SELECT a FROM t ORDER BY a LIMIT 3',
callback: (result) => {
if (!result.row) {
return;
}
console.log(result.row);
},
});
await promiser('close', { dbId });
} catch (err) {
if (!(err instanceof Error)) {
err = new Error(err.result.message);
}
console.error(err.name, err.message);
}
})();
डेमो
ऊपर दिए गए कोड को डेमो में काम करते हुए देखें. Glitch पर, सोर्स कोड को ज़रूर देखें. ध्यान दें कि यहां एम्बेड किया गया वर्शन, OPFS बैकएंड का इस्तेमाल नहीं करता है. हालांकि, जब डेमो को अलग टैब में खोला जाता है, तो यह बैकएंड का इस्तेमाल करता है.
ऑरिजिन प्राइवेट फ़ाइल सिस्टम को डीबग करना
SQLite Wasm के ऑरिजिन प्राइवेट फ़ाइल सिस्टम के आउटपुट को डीबग करने के लिए, OPFS एक्सप्लोरर Chrome एक्सटेंशन का इस्तेमाल करें.
एक्सटेंशन इंस्टॉल करने के बाद, Chrome DevTools खोलें और OPFS Explorer टैब चुनें. इसके बाद, यह जांचा जा सकता है कि SQLite Wasm, Origin Private File System में क्या लिखता है.
DevTools में OPFS एक्सप्लोरर विंडो में से कोई भी फ़ाइल चुनने पर, उसे लोकल डिस्क में सेव किया जा सकता है. इसके बाद, डेटाबेस की जांच करने के लिए, SQLite व्यूअर जैसे ऐप्लिकेशन का इस्तेमाल किया जा सकता है. इससे आपको यह पक्का करने में मदद मिलेगी कि SQLite Wasm वाकई में, बताए गए तरीके से काम करता है.
सहायता पाना और सुझाव/राय देना या शिकायत करना
SQLite Wasm को SQLite कम्यूनिटी ने डेवलप किया है और इसका रखरखाव भी करती है. सहायता फ़ोरम में खोजकर और पोस्ट करके, मदद पाएं और सुझाव/राय दें या शिकायत करें. SQLite की साइट पर, दस्तावेज़ की पूरी जानकारी उपलब्ध है.