SQLite के बारे में दिलचस्प तथ्य

• SQLite सबसे ज़्यादा वितरित और इस्तेमाल किया जाने वाला database है

  • 1 ट्रिलियन से अधिक SQLite databases उपयोग में हैं, और इन्हें तीन लोग maintain करते हैं
  • यह बाहरी योगदान स्वीकार नहीं करता

• SQLite का उपयोग बाकी सभी database engines को मिलाकर भी उससे अधिक होता है

  • SQLite की अरबों copies मौजूद हैं, और यह हर जगह है

• SQLite सबसे ज़्यादा वितरित software modules में से एक है

• Hwaci वह कंपनी है जिसने SQLite विकसित किया, और उसकी संगीत में भी रुचि है

• SQLite की शुरुआत एक अमेरिकी battleship पर हुई

  • D. Richard Hipp (DRH) USS Oscar Austin नामक नौसेना destroyer के लिए software विकसित कर रहे थे
  • हर बार server down होने पर मौजूदा software काम करना बंद कर देता था
  • DRH ने ऐसे database की कल्पना की जो server के बिना भी काम करे

• कानूनी अर्थ में SQLite open source नहीं है

  • open source के लिए एक विशेष परिभाषा और OSI द्वारा अनुमोदित license की आवश्यकता होती है
  • इसके बजाय SQLite public domain में है, और open source licenses की तुलना में उस पर कम प्रतिबंध हैं

• यह बाहरी योगदान स्वीकार नहीं करता

  • केवल आमंत्रित लोग ही योगदान दे सकते हैं, और योगदान public domain को समर्पित होना चाहिए

• SQLite का test code

  • SQLite के code की हर एक पंक्ति पर 600 से अधिक पंक्तियाँ test code की हैं
  • tests library की सभी branches को 100% cover करते हैं

• SQLite के कुछ tests proprietary हैं

  • TH3 नाम का test suite proprietary है, और उस तक पहुँचने के लिए SQLite Consortium का सदस्य बनना पड़ता है

• SQLite का business model

  • यह paid support, maintenance services, consortium membership, और commercial extensions के ज़रिए revenue कमाता है

• SQLite के पास code of conduct की जगह code of ethics है

• SQLite बहुत तेज़ है, और कुछ use cases में file system से 35% तेज़ है

• SQLite single-writer model का पालन करता है

  • यह एक साथ कई writers की अनुमति नहीं देता

• दूसरे databases से अंतर

  • डिफ़ॉल्ट रूप से यह rollback journal mode का उपयोग करता है, और foreign keys निष्क्रिय रहती हैं
  • यह weak typing का उपयोग करता है, जबकि strong typing वैकल्पिक है

• SQLite में type न होना असुविधाजनक हो सकता है

  • type constraints के बिना data insert किया जा सकता है

• SQLite compatibility को बहुत महत्व देता है

  • SQLite 3 के सभी versions शुरुआती versions की database files को पढ़ और लिख सकते हैं

• SQLite के लेखक DRH ने यह मानकर Fossil विकसित किया कि मौजूदा version control systems उपयुक्त नहीं हैं

• DRH ने हवाई जहाज़ में TAOCP किताब के algorithm के आधार पर B-Tree को code किया

• SQLite का उच्चारण "Ess-Cue-El-Lite" करने की सिफारिश की जाती है, लेकिन इस बारे में कोई आधिकारिक guide नहीं है

[dalinaum]

SQLite उतना तेज़ DB नहीं है जितना लोग सोचते हैं। अब बंद किए जा चुके MongoDB Realm की गति इससे कहीं अधिक थी। लगता है कि लोगों के लिए speed कोई इतना महत्वपूर्ण selection factor नहीं था।

[dalinaum]

यहां एक व्यक्ति ने पूछा था कि Realm तेज़ क्यों है और उसका आधार क्या है, लेकिन लगता है MongoDB ने सपोर्ट बंद करते समय वह पोस्ट हटा दी।

इसलिए, वहां कभी काम कर चुके व्यक्ति के तौर पर, मुझे याद रहने वाले तकनीकी कारण समझाने की कोशिश करता हूं। मुझे लगता है सबसे बड़ा फायदा यह था कि Realm, SQLite की तुलना में कम मेमोरी इस्तेमाल करता था और उसका cache hit rate अधिक था।

Realm मूल रूप से इस्तेमाल हो रहे size के आधार पर यह चुनता है कि मेमोरी में कितना डेटा रखा जाए। इसलिए, भले ही उपयोगकर्ता बड़ा size वाला data type चुने, कई बार वह कुछ bits के छोटे size में serialize कर देता है। वास्तव में, जब उपयोगकर्ता सच में बड़ा डेटा लिखता है, तभी conversion होता है।

Realm एक ही data type वाली चीज़ों को group करके पास-पास store करता है। उपयोगकर्ता अक्सर table के सभी डेटा तक पहुंचने के बजाय, कुछ डेटा को लगातार access करते हैं। ऊपर बताई गई छोटे size की encoding की वजह से, एक बार में cache से मिलने वाला डेटा कहीं ज़्यादा हो जाता है।

Realm, POJO object को hydrate नहीं करता, बल्कि getter और setter में ज़रूरत पड़ने पर डेटा देता है। इसके लिए Java के मामले में वह bytecode स्तर पर manipulation करता है। Protobuf जैसे data type उस समय Meta के Facebook app client में इस्तेमाल होने की एक वजह यह भी थी कि यह hydrate process performance के लिहाज़ से बड़ा नुकसान था, और केवल ज़रूरी डेटा तक पहुंचना फायदेमंद था।

Realm, SQLite की तुलना में ज़्यादातर scenarios में काफी तेज़ था, लेकिन मुझे नहीं लगता कि बाज़ार में यही सबसे बड़ा कारक था।

मुझे याद है कि Realm का सबसे बड़ा प्रतिद्वंद्वी Facebook का बनाया हुआ Parse था। उसके बाद Google का Firebase प्रतिद्वंद्वी बना। ये दोनों local mobile database नहीं थे, बल्कि remote पर डेटा आसानी से store करने वाली सेवाएं थीं। यह अजीब लग सकता है कि Realm के प्रतिस्पर्धी ये दोनों कैसे हो सकते थे, लेकिन असल उपयोगकर्ताओं के लिए शायद बस कहीं भी डेटा store कर पाना काफी था, और speed उतनी महत्वपूर्ण नहीं थी।

और बाद में Ericsson के निवेश के बाद Realm का दायरा छोटा हो गया। Ericsson यह नहीं समझ पाया कि Realm की iOS में कुछ हिस्सेदारी होने के बावजूद आगे और feature development क्यों किया जाए। और उसने इसे एक synchronization solution के रूप में ज़्यादा महत्व दिया। बाद में Realm का MongoDB में विलय हो गया।

[aer0700]

मुझे लगता है कि SQLite को चुनने की 80% वजह यह थी कि इसे संभालना आसान था।

[dalinaum]

मैं भी इसे महत्वपूर्ण कारणों में से एक मानता हूँ। Realm ने thread-local आधारित उपयोग का तरीका दिया, automatic updates प्रदान किए, और कहा कि अगर किसी दूसरे thread में दोबारा query की जाए तो बहुत कम लागत में वही data पहुँचाया जा सकता है, तथा दूसरे thread में data न भेजने की सिफारिश की, लेकिन इस तरह की बातों को समझाना आसान नहीं था।

[sanggi]

लगता है sqlite का इस्तेमाल सच में बहुत अलग-अलग जगहों पर होता है!

[xguru]

SQLite की अनजानी कहानियाँ

[GN⁺]

Hacker News राय

• कुछ लोगों का मत है कि OSI open source का मानक नहीं है। OSI की open source definition उपयोगी है, लेकिन उस पर आलोचना और विवाद भी हैं। यह कहना गलत है कि SQLite कानूनी रूप से open source नहीं है

  • OSI approval पर निर्भर रहना वांछनीय नहीं है। OSI-approved licenses की सूची केवल व्यावहारिक और राजनीतिक इतिहास को दर्शाती है
  • SQLite के open source होने पर विवाद है। Public domain dedication कोई license नहीं है, इसलिए यह OSD को पूरा नहीं करता, लेकिन यह उससे भी अधिक खुला है

• यह ब्लॉग लोकप्रिय विषय पर पुराने और दोहराए गए बिंदुओं का इस्तेमाल करके views और engagement बढ़ाने की कोशिश जैसा लगता है

  • ब्लॉग की पिछली पोस्टों में तकनीकी गहराई की कमी है और उनमें बढ़ा-चढ़ाकर कही गई बातें बहुत हैं

• SQLite के पास code of conduct (CoC) नहीं बल्कि code of ethics (CoE) है। CoC का इस्तेमाल बाहरी contributors के व्यवहार को नियंत्रित करने के लिए एक tool के रूप में किया जाता है, जबकि CoE वह घोषणा है कि SQLite developers दूसरों के प्रति कैसा व्यवहार करना चाहते हैं

• SQLite के उच्चारण को लेकर भ्रम है। कहा जाता है कि इसे "Ess-Cue-El-Lite" की तरह बोला जाता है, लेकिन कुछ लोग इसे "S-Q-L-ite" भी बोलते हैं

• SQLite वैकल्पिक रूप से strict tables को support करता है। CREATE TABLE name (stuff TEXT) STRICT का उपयोग करके type enforcement किया जा सकता है

• SQLite केवल एक SQL database नहीं है, इसे NoSQL database की तरह भी इस्तेमाल किया जा सकता है। JSON columns का उपयोग करके data store करने का तरीका उपयोगी है

• Richard Hipp के साथ project पर काम करने का अनुभव रहा है। वे support contracts के जरिए स्थिर revenue कमा रहे हैं

• SQLite की एक release में कई micro-optimizations के कारण performance 50% तक बेहतर हुई

• SQLite का उपयोग तेज prototyping और log dumps के लिए किया जाता है, लेकिन जब multi-writer की ज़रूरत होती है तो कठिनाई आती है। यह SQLite से आगे बढ़ने के मुख्य कारणों में से एक है

• SQLite single-writer model पर आधारित है। Redis भी single-threaded model है

• SQLite के बारे में एक मजेदार तथ्य यह है कि जब users ने रात में developers को फोन करना शुरू कर दिया, तो उन्हें default prefix को sqlite_ से etilqs_ में बदलना पड़ा