वेब पर स्टोरेज की सभी ज़रूरतों को बेहतर तरीके से मैनेज करने के लिए, SQLite का इस्तेमाल करें.
SQLite एक लोकप्रिय, ओपन-सोर्स, लाइटवेट, और एम्बेड किया गया रिलेशनल डेटाबेस मैनेजमेंट सिस्टम है. कई डेवलपर इसका इस्तेमाल, डेटा को व्यवस्थित और आसानी से इस्तेमाल किए जा सकने वाले तरीके से सेव करने के लिए करते हैं. SQLite का साइज़ छोटा होता है और इसके लिए कम मेमोरी की ज़रूरत होती है. इसलिए, मोबाइल डिवाइसों, डेस्कटॉप ऐप्लिकेशन, और वेब ब्राउज़र में अक्सर इसका इस्तेमाल डेटाबेस इंजन के तौर पर किया जाता है.
SQLite की सबसे अहम सुविधाओं में से एक यह है कि यह बिना सर्वर वाला डेटाबेस है. इसका मतलब है कि इसे ऑपरेट करने के लिए, अलग से किसी सर्वर प्रोसेस की ज़रूरत नहीं होती. इसके बजाय, डेटाबेस को उपयोगकर्ता के डिवाइस पर एक ही फ़ाइल में सेव किया जाता है. इससे ऐप्लिकेशन में आसानी से इंटिग्रेट हो जाता है.
वेब असेंबली पर आधारित SQLite
वेब असेंबली (Wasm) पर आधारित SQLite के कई गैर-आधिकारिक वर्शन हैं. इनकी वजह से इसे वेब ब्राउज़र में इस्तेमाल किया जा सकता है, उदाहरण के लिए, sql.js. sqlite3 WASM/JS सबप्रोजेक्ट पहली कोशिश है, जो आधिकारिक तौर पर SQLite प्रोजेक्ट से जुड़ा है. इसकी मदद से, Wasm ऐसी लाइब्रेरी का बिल्ड बनाता है जो इस्तेमाल किए जा सकने वाले SQLite पर काम करने वाले फ़ैमिली ग्रुप के जाने-माने सदस्यों के लिए बनाई जाती है. इस प्रोजेक्ट के ठोस लक्ष्यों में ये शामिल हैं:
- एक लो-लेवल sqlite3 API को बाइंड करना, जो C वाले एपीआई के जितना हो सकता है उतना ही इस्तेमाल करना आसान होता है.
- यह एक बेहतर लेवल का ऑब्जेक्ट-ओरिएंटेड एपीआई है. यह sql.js और Node.js-स्टाइल के लागू होने से मिलता-जुलता है. यह सीधे तौर पर लो-लेवल एपीआई से जुड़ा होता है. इस एपीआई का इस्तेमाल, उसी थ्रेड से किया जाना चाहिए जिससे लो-लेवल एपीआई का इस्तेमाल किया जाता है.
- Worker पर आधारित एपीआई, जो Worker मैसेज के ज़रिए पिछले एपीआई से बात करता है. इसे इन्हें मुख्य थ्रेड में इस्तेमाल करने के लिए बनाया गया है, ताकि निचले लेवल के एपीआई को वर्कर थ्रेड में इंस्टॉल किया जा सके. साथ ही, इससे वर्कर मैसेज के ज़रिए बातचीत की जा सके.
- Worker API का एक वादा-आधारित वैरिएंट, जो उपयोगकर्ता से क्रॉस-थ्रेड कम्यूनिकेशन के पहलुओं को पूरी तरह से छिपा देता है.
- उपलब्ध JavaScript API का इस्तेमाल करके, क्लाइंट-साइड पर स्टोरेज को हमेशा के लिए सेव रखने की सुविधा. इसमें ऑरिजिन प्राइवेट फ़ाइल सिस्टम (OPFS) भी शामिल है.
Origin के निजी फ़ाइल सिस्टम के पर्सिस्टेंस बैकएंड के साथ SQLite Wasm का इस्तेमाल करना
npm से लाइब्रेरी इंस्टॉल करना
इस कमांड का इस्तेमाल करके, npm से @sqlite.org/sqlite-wasm पैकेज इंस्टॉल करें:
npm install @sqlite.org/sqlite-wasm
ऑरिजिन प्राइवेट फ़ाइल सिस्टम
ऑरिजिन प्राइवेट फ़ाइल सिस्टम (ओपीएफ़एस, फ़ाइल सिस्टम ऐक्सेस एपीआई का हिस्सा) को एक खास प्लैटफ़ॉर्म के साथ जोड़ा गया है. इससे डेटा को तेज़ी से ऐक्सेस किया जा सकता है. यह नया प्लैटफ़ॉर्म, मौजूदा प्लैटफ़ॉर्म से अलग है. इसमें, फ़ाइल के कॉन्टेंट में बदलाव करने का ऐक्सेस, फ़ाइल के मौजूदा वर्शन में ही दिया जाता है. इस बदलाव के साथ-साथ, बिना पब्लिश किए गए बदलावों को लगातार पढ़ने और खास तौर पर काम करने वाले कर्मचारियों के लिए सिंक्रोनस वैरिएंट उपलब्ध कराने से, परफ़ॉर्मेंस बेहतर होती है और इस्तेमाल के नए उदाहरणों को अनब्लॉक किया जाता है.
जैसा कि आप कल्पना कर सकते हैं, प्रोजेक्ट के लक्ष्यों का आखिरी बिंदु, उपलब्ध JavaScript API का इस्तेमाल करके स्थायी क्लाइंट-साइड स्टोरेज के लिए सहायता देना है. इस सहायता की मदद से, डेटा को डेटाबेस फ़ाइल में बनाए रखना मुश्किल हो जाता है.
यहां 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, आम तौर पर वेब एसक्यूएल के बराबर ही तेज़ है. कभी-कभी यह थोड़ा धीमा होता है, कभी-कभी थोड़ा तेज़. नतीजों के पेज पर पूरी जानकारी देखें.
शुरू करने के लिए कोड का सैंपल
जैसा कि पहले बताया गया है, ऑरिजिन प्राइवेट फ़ाइल सिस्टम के साथ SQLite Wasm के लिए परसिस्टेंस बैकएंड को वर्कर कॉन्टेक्स्ट से चलाना ज़रूरी होता है. अच्छी बात यह है कि लाइब्रेरी, इन सभी कामों को अपने-आप मैनेज कर लेती है. साथ ही, इसका इस्तेमाल मुख्य थ्रेड से किया जा सकता है.
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 Explorer विंडो में से कोई भी फ़ाइल चुनने पर, उसे लोकल डिस्क में सेव किया जा सकता है. इसके बाद, डेटाबेस की जांच करने के लिए, SQLite व्यूअर जैसे ऐप्लिकेशन का इस्तेमाल किया जा सकता है. इससे आपको यह पक्का करने में मदद मिलेगी कि SQLite Wasm वाकई में, बताए गए तरीके से काम करता है.
सहायता पाना और सुझाव/राय देना या शिकायत करना
SQLite Wasm को SQLite कम्यूनिटी ने डेवलप किया है और इसका रखरखाव भी करती है. सहायता फ़ोरम में खोजकर और पोस्ट करके, मदद पाएं और सुझाव/राय दें या शिकायत करें. SQLite की साइट पर, दस्तावेज़ का पूरा वर्शन उपलब्ध है.