SQLite की अनकही कहानी

xguru · 2021-07-05T10:21:01+09:00

SQLite डेवलपर Richard Hipp के इंटरव्यू पॉडकास्ट का सारांश (38 मिनट, स्क्रिप्ट उपलब्ध) उनका मुख्य काम अमेरिकी नौसेना के destroyer जहाज़ों में जाने वाले software के डेवलपर के रूप में था → जहाज़ के अंदर इस्तेमाल होने वाला Informix अक्सर error देता था, server crash हो जाता था और connection टूट जाता था → क्योंकि वह युद्धपोत था, इसलिए लड़ाई के दौरान नुकसान होने पर भी “DB से कनेक्ट नहीं हो सका” जैसे popup नहीं दिखने चाहिए थे और सिस्टम को मज़बूती से चलना चाहिए था। transaction की भी ज़रूरत नहीं थी, और किसी भी स्थिति में data को RAM में पढ़ पाना ज़रूरी था → server के बिना चलने वाला SQL DB engine खोजा, लेकिन ऐसा कुछ मिला नहीं, इसलिए खुद बनाने का फैसला किया SQLite V1 (2000) SQL statements को program की तरह मानकर query को compile और execute करने वाला bytecode engine लिखा वास्तव में यह project में इस्तेमाल नहीं हुआ (ग्राहक Informix ही इस्तेमाल करना चाहता था) इसे development purpose के लिए इस्तेमाल करते हुए इंटरनेट पर सार्वजनिक किया, और लोगों ने इसका उपयोग शुरू कर दिया “मैंने Palm Pilot पर SQL DB चलाया” जैसी बातें सुनने को मिलीं और लोगों का ध्यान इस पर गया। इससे आगे काम जारी रखने का उत्साह मिला। Motorola 2001~2002 के बीच Motorola से फोन आया कि वे अपने नए phone OS में SQLite डालना चाहते हैं ज़रूरी features support कर दिए जाएँ तो वे पैसे देने को तैयार थे तभी पहली बार पता चला कि open source से भी पैसे कमाए जा सकते हैं लगभग $80,000 मिले; आज के हिसाब से बहुत बड़ी रकम न सही, लेकिन उनके लिए यह बेहद चौंकाने वाली रकम थी। अपने साथ काम कर रहे तीन लोगों के साथ project शुरू किया, और वहीं से यह यात्रा शुरू हुई America Online Phones इसके बाद संपर्क करने वाली अगली कंपनी AOL थी वह CD डाक से भेजने का दौर था, और उन CDs के अंदर database की ज़रूरत थी यानी वे CD के भीतर SQLite शामिल करना चाहते थे और कुछ नए features भी चाहिए थे Symbian OS और Nokia Thanksgiving पर London जाकर meeting की (क्योंकि UK में Thanksgiving नहीं होता) उन्हें Symbian OS के लिए DB चाहिए था, और SQLite ने दूसरे DBs के साथ प्रतिस्पर्धा की (2 open source, 7 commercial) बाकी 9 DBs को tuning का मौका दिया गया, लेकिन अंत में SQLite जीता Bus Factor [1] और consortium bus factor वह metric है जो बताता है कि कितने लोगों के बस से टकराने पर development रुक जाएगा Richard full-time कई लोगों के साथ काम कर रहे थे, लेकिन Symbian की तरफ़ से कहा गया कि bus factor बढ़ना चाहिए SQLite consortium शुरू करने का विचार आया ताकि project को funding मिले और लंबे समय तक अधिक लोग इसमें जुड़ें शुरुआत में उन्होंने यह अजीब-सा विचार रखा कि consortium के हर member को voting rights दिए जाएँ Mozilla Foundation की Mitchell Baker ने यह बात कहीं सुनी और फोन किया → “Richard, आप यह पूरी तरह गलत कर रहे हैं। मैं आपको consortium बनाना सिखाती हूँ।” → फिर उन्होंने नियम बनाने शुरू किए → “control developers के पास होना चाहिए। उनका फैसला अंतिम होना चाहिए। सिर्फ़ शामिल होने भर से voting rights नहीं मिल जाने चाहिए।” → “जो कंपनियाँ इसका इस्तेमाल करती हैं, उन्हें धन देने का सम्मान मिलेगा, लेकिन अंतिम निर्णय आपको लेना होगा।” → वह बहुत दृढ़ थीं और उन्होंने सब कुछ व्यवस्थित कर दिया। वह वकील हैं। Richard ने पूछा, “लोग इसमें क्यों जुड़ेंगे? incentive क्या होगा?” → “चिंता मत कीजिए। वे जुड़ेंगे। और अगर आप ऐसा करते हैं, तो Mozilla founding member बनेगा।” Mozilla, Symbian और Adobe के समर्थन से consortium की शुरुआत हुई → जब Symbian ने पहली बार कहा कि consortium की ज़रूरत है, तब उन्हें समझ नहीं आया कि क्या करना चाहिए। Mitchell Baker को यह कैसे पता चला और उन्होंने फोन कैसे किया, यह उन्हें आज भी नहीं पता, लेकिन यह पूरा सफ़र अद्भुत रहा। Enter Android : Android की शुरुआत क्योंकि सभी smartphones SQLite का उपयोग कर रहे थे, Richard शुरुआती smartphone development को लगभग हर कोण से देख पा रहे थे 2005 में Android के साथ meeting हुई। तब तक न Android आया था, न iPhone एक BlackBerry जैसे phone से connect करके SQLite debug किया गया, जिसमें ऊपर छोटा display और पूरा QWERTY keyboard था असली working phone network से जुड़े device पर GDB से debugging करना अद्भुत अनुभव था उस समय Motorola, Symbian और Nokia में से कोई भी ऐसा नहीं कर रहा था, और तभी उन्हें लगा कि Android बहुत बड़ा बनने वाला है Guy, This Is Important : दोस्तों, यह सच में बहुत महत्वपूर्ण है उस दौर में दूसरी कंपनियों के hardware और software update cycles लगभग 30 दिन के होते थे, लेकिन Android असली network से जुड़े phones में दिन में कई बार नया OS डाल रहा था। NDA के तहत मिला prototype Android phone ऐसा लगता था जैसे उसका case 3D print किया गया हो, लेकिन फिर भी उसे साथ लेकर चला जा सकता था। → दूसरी कंपनियों के prototypes बड़े breadboard जैसे थे और network से भी जुड़े नहीं थे, इसलिए उन्हें phone की तरह इस्तेमाल ही नहीं किया जा सकता था वे Motorola और Symbian के लोगों से कहना चाहते थे, “यह बहुत महत्वपूर्ण है, तुम्हें यह solve करना होगा,” लेकिन NDA की वजह से कह नहीं सकते थे। और इसी ने अंतर पैदा किया। Testing and Aviation Standards : testing और aviation standards Adam (interviewer): “आज Richard का DB बहुत सक्रिय स्थिति में है। टीम प्रतिभाशाली है, लेकिन यह 1~4 लोगों की एक software consulting company है जो हर Android phone में जाने वाले DB को support करती है। डेवलपर्स DB को लेकर बहुत गंभीर हैं और data में समस्या आना उन्हें पसंद नहीं।” हम भोलेपन में सबको बताते थे कि SQLite में कोई bug नहीं है, लेकिन Android ने साफ़ दिखा दिया कि हम गलत थे। हमें लगा था कि bug-free software बन सकता है, लेकिन जब software लाखों devices पर install होता है, तब कितने bugs निकल सकते हैं, यह चौंकाने वाला था। लगभग उसी समय वे avionics company Rockwell Collins के साथ काम कर रहे थे, और वहीं उन्होंने DO-178B [2] की अवधारणा से परिचय कराया। → DO-178B safety-critical aviation products के quality standard से जुड़ा है, और दूसरे quality standards के विपरीत यह “पढ़ने लायक (readable)” है → इसकी कीमत कुछ सौ डॉलर है, लेकिन यह पतला है, इसलिए इसे ज़रूर पढ़ने की सलाह दी गई उन्होंने वास्तव में DO-178B की process follow करनी शुरू की, जिनमें से एक थी 100% MCDC test coverage MCDC (Modified Condition / Decision Coverage) [3] का मतलब है कि testing में हर individual branch कम-से-कम एक बार तो cover हो SQLite को 100% MCDC तक पहुँचाने में, हफ़्ते के 60 घंटे के हिसाब से, एक साल लगा। यह बेहद कठिन था। रोज़ 12 घंटे काम करना पड़ता था और वे बुरी तरह थक जाते थे। 90~95% test coverage आसान है, लेकिन आख़िरी 5% बहुत कठिन। लेकिन एक साल की मेहनत के बाद जब 100% तक पहुँचे, तो Android से bug reports आना बंद हो गया वहीं से चीज़ें सही चलने लगीं और बड़ा फ़र्क पड़ा। उसके बाद 8~9 साल तक कोई bug नहीं आया। अरबों tests पहला test TCL (Tool Command Language) में लिखा गया था, और वह सामान्य developer testing के लिए था पहला TCL test आज भी maintain किया जा रहा है और सार्वजनिक है। 100% नहीं है, लेकिन SQLite की लगभग सारी functionality को विस्तार से test करता है। 100% MCDC coverage वाले suite को TH3 कहा जाता है और वह सार्वजनिक नहीं है (proprietary) इसे aviation companies को बेचकर पैसा कमाने की कोशिश की गई, लेकिन एक भी copy नहीं बिकी, इसलिए उस लिहाज़ से यह सफल नहीं रहा.. लेकिन इसने हमारे product को बेहद मज़बूत बनाए रखने और नए features व bug fixes जल्दी करने में बहुत मदद की tests की संख्या गिनना मुश्किल है, लेकिन 100,000 individual tests parameterize होकर अरबों test runs बनाते हैं एक checklist है, और release से पहले कम-से-कम 3 दिन तक testing की जाती है जानबूझकर कई OSes पर testing की जाती है → आजकल लगभग सारे devices little-endian हैं, लेकिन पहले big-endian systems भी बहुत थे। इसलिए PowerPC iBook पर big-endian tests किए जाते थे → 32-bit platforms, ARM और Intel, 64-bit platforms, Windows, Linux, Mac, OpenBSD आदि—जितने platforms और OSes पर संभव हो, सब पर test किया जाता है → कई अलग-अलग test suites हैं; मूल TCL suite भी है, TH3 भी है। लगातार चलने वाला fuzzer (fuzz testing) भी है। SQL Logic test भी है → 10 साल पहले Shane Harrelson ने SQL statements का एक विशाल संग्रह बनाया था → इसे हर उस DB पर चलाया गया जिसे हाथ लगाया जा सकता था, और लगभग हर DB engine सही answer देने में विफल रहा या segmentation fault दे बैठा। SQLite भी उनमें था। सिर्फ़ Postgres अपवाद था। → केवल Postgres ही लगातार result देता रहा और उसमें कोई कमी नहीं मिली। Postgres developers ने कहा कि शायद हमने पर्याप्त कोशिश नहीं की.. Postgres में error निकालना शायद संभव रहा हो, लेकिन हम बहुत प्रभावित हुए → commercial Oracle version भी crash हुआ, और DB2 भी crash हुआ → महत्वपूर्ण बात यह थी कि SQLite को इन सभी queries पर एक जैसा उत्तर देने लायक बनाया गया Building From First Principles जब उन्होंने शुरुआत की, तो यह देखने की कोशिश की कि SQL DB engine कैसे बनाया जाता है, इस पर कोई reference मिलता है या नहीं, लेकिन कुछ नहीं मिला। इसलिए सब कुछ खुद बनाना पड़ा; यह पूरी तरह स्वतंत्र मिशन था। MIT, Harvard और Berkeley में बहुत-सा theory work हो रहा था, लेकिन अगर आप उन संस्थानों में न हों तो आपको यह भी पता नहीं चलता कि ऐसा theory work मौजूद है, न ही उसे ढूँढने का तरीका पता चलता Postgres का Volcano model और SQLite का bytecode model देखने पर अंततः एक ही तरह के विचारों पर पहुँचते दिखते हैं ऊपर से देखें तो शुरुआती बिंदु बहुत अलग लगते हैं, लेकिन performance बढ़ाने की कोशिश में दोनों एक ही दिशा में converge करते हैं उन्हें लगता है कि सिद्धांत के स्तर पर यह एक तरह का validation है: दो स्वतंत्र development lines का एक ही उत्तर तक पहुँचना उदाहरण के लिए, उन्हें covering index के बारे में बिल्कुल पता नहीं था। फिर Germany में हुई एक PHP conference में गए, जहाँ MySQL के David Axmark ने भी talk दी → उस talk में बताया गया कि MySQL ने covering index कैसे बनाया → जब DB index में कई columns हों, और query index के शुरुआती columns पर ही हो तथा answer बाकी columns में ही मिल जाए, तो DB मूल table को पढ़े बिना सिर्फ़ index से काम कर सकता है, जिससे speed बढ़ती है → फिर घर लौटते समय flight में, जब आस-पास कम लोग थे, उन्होंने laptop खोला और Atlantic के ऊपर उड़ान के दौरान SQLite में covering index implement कर दिया B-Trees and The Art of Computer Programming बहुत-सी चीज़ें खुद बनानी पड़ीं। किसी ने उन्हें B-tree नहीं सिखाया था; उन्होंने बस उसका नाम सुन रखा था। जब खुद B-tree develop करने की कोशिश कर रहे थे, तो bookshelf में Don Knuth की TAOCP मिली। उसमें B-tree देखा और उन्होंने algorithm समझाया था मज़ेदार बात यह थी कि किताब में B-tree search और insertion algorithm विस्तार से समझाए गए हैं, लेकिन deletion algorithm नहीं दिया गया। वह chapter के अंत में exercise के रूप में था, इसलिए अपना B-tree बनाने से पहले उन्हें वह सवाल खुद हल करना पड़ा। “धन्यवाद Don, बहुत-बहुत धन्यवाद।” आज के लोगों को कम-से-कम TAOCP पढ़नी या कम-से-कम पलटकर देखनी तो चाहिए Freedom to Build It Yourself : खुद बनाने की आज़ादी SQLite, Richard द्वारा खुद बनाए गए हिस्सों के अलावा, किसी और dependency पर निर्भर नहीं है (C compiler और libc को छोड़कर)। उन्होंने अपना version control system भी बनाया और bug tracker भी। इससे Richard को स्वतंत्रता मिली freedom का मतलब है अपनी देखभाल खुद करना backpacking करने वाले लोग जब अपनी ज़रूरत का सब kuch पीठ पर लेकर चलते हैं, तो वे खुद को स्वतंत्र कहते हैं क्योंकि वे अपना ख़याल खुद रख रहे होते हैं अगर आप सब कुछ खुद बनाते हैं, तो आप किसी और से बंधे नहीं रहते; और इसी में स्वतंत्रता है मान लीजिए SQLite 2 के storage engine के लिए Berkeley DB चुना गया होता → उस समय Berkeley DB open source था, लेकिन बाद में Oracle ने उसे खरीद लिया और वह dual-source proprietary model में चला गया, जिससे license fee दिए बिना latest source code नहीं मिल पाता आज SQLite का parser generator Yak या Bison नहीं, बल्कि खुद लिखा गया Lemon है; इसलिए जब नए language features की ज़रूरत हुई, तो वे उन tools पर निर्भर हुए बिना इसे बदल सके 2000 के शुरुआती वर्षों में लगभग हर project CVS इस्तेमाल करता था, इसलिए उन्होंने भी वही इस्तेमाल किया। लेकिन 2000 के मध्य तक distributed version control का विचार उभरने लगा Fossil बनाना Git और Mercurial को देखने के बाद requirements व्यवस्थित कीं और फिर खुद version control system बनाने का फैसला किया अब Fossil अच्छी तरह काम करता है और अपने आप में एक project बन चुका है Linus Torvalds ने Linux Kernel development को support करने के लिए Git बनाया था, इसलिए अगर आपका काम Linux Kernel से जुड़ा है तो Git एकदम सही version control system है Fossil, SQLite पर काम करने के लिए बिल्कुल उपयुक्त version control system है। क्योंकि इसे मैंने खुद बनाया, यह मेरी requirements को ठीक-ठीक पूरा करता है खुद develop करके आप अपने भाग्य पर नियंत्रण रखते हैं, अधिक स्वतंत्रता पाते हैं, और third party पर निर्भर नहीं रहते आत्मनिर्भर बनना शहर छोड़कर अपना खाना खुद उगाकर जीने वाले लोगों को क्या कहते हैं? Survivalist (जीवित रहने की तैयारी करने वाला)? या Prepper (पूर्वतैयारी करने वाला)? “जैसा कि आपने मुझसे संपर्क करते समय भी देखा, मेरा Gmail थोड़ा अजीब व्यवहार कर रहा है। mails बार-बार वापस लौट रही हैं। इसलिए मैं अपना mail server बनाना चाहता हूँ। जब हम यह meeting setup कर रहे थे, तब भी मैं उससे जुड़े notes लिख रहा था। यह DB engine लिखने से कठिन तो नहीं होगा, लेकिन मैं Gmail पर निर्भर नहीं रहना चाहता। मैं नहीं चाहता कि वे मेरा भाग्य नियंत्रित करें। मैं नहीं चाहता कि वे मेरी सारी बातचीत का रिकॉर्ड नियंत्रित करें। मैं खुद नियंत्रण चाहता हूँ, इसलिए भले ही यह कष्टदायक हो और इसमें बहुत काम हो, फिर भी मैं ऐसा समाधान खोजने की कोशिश करूँगा जिसे मैं खुद नियंत्रित कर सकूँ। cloud में virtual machine किराए पर लेकर चलाया जा सकता है, ताकि किसी third party पर निर्भर न रहना पड़े।” अगर कोई आकर कहे कि वह आपकी समस्या हल कर देगा, तो आपको समझना चाहिए कि वह आपकी स्वतंत्रता छीन भी सकता है। “अगर स्वतंत्र रहना है, तो खुद करना होगा।” दूसरों के लिए सलाह मैंने एक पागल-से विचार से शुरुआत की थी कि ऐसा DB engine बनाऊँगा जिसे server की ज़रूरत न हो और जो सीधे disk से पढ़े-लिखे। अगर आप experts से पूछेंगे, तो वे कहेंगे, “यह असंभव है। यह कभी काम नहीं करेगा। यह बेवकूफ़ी भरा विचार है।” सौभाग्य से मैं ऐसे experts को जानता नहीं था, इसलिए मैंने बस काम शुरू कर दिया, और फिर यह सब हुआ। experts की बात बहुत ज़्यादा मत सुनिए। जो समझ में आता है, वह कीजिए। अपनी समस्या हल कीजिए -- [1] Bus Factor : वह जोखिम स्तर जिसमें किसी team member के अचानक अनुपलब्ध हो जाने पर टीम संकट में पड़ सकती है। यह उस जोखिम का संकेतक है जो तब पैदा होता है जब team members के बीच जानकारी और functions साझा नहीं होते। इस संख्या को बढ़ाना ज़रूरी है ताकि जानकारी साझा हो और काम किसी एक व्यक्ति पर केंद्रित न रह जाए। [2] DO-178B : aircraft systems और equipment certification के लिए software considerations (Software Considerations in Airborne Systems and Equipment Certification) इसे FAA ने aviation software certification के लिए compliance साबित करने के एक तरीके के रूप में अपनाया है [3] MCDC : Modified Condition / Decision Coverage जब कई conditions हों, तब test cases इस तरह डिज़ाइन करने की विधि कि हर individual condition, बाकी conditions से स्वतंत्र रूप से, पूरे condition expression के परिणाम को प्रभावित करे

(corecursive.com)

47 पॉइंट द्वारा xguru 2021-07-05 | 16 टिप्पणियां | WhatsApp पर शेयर करें

SQLite डेवलपर Richard Hipp के इंटरव्यू पॉडकास्ट का सारांश (38 मिनट, स्क्रिप्ट उपलब्ध)
उनका मुख्य काम अमेरिकी नौसेना के destroyer जहाज़ों में जाने वाले software के डेवलपर के रूप में था
→ जहाज़ के अंदर इस्तेमाल होने वाला Informix अक्सर error देता था, server crash हो जाता था और connection टूट जाता था
→ क्योंकि वह युद्धपोत था, इसलिए लड़ाई के दौरान नुकसान होने पर भी “DB से कनेक्ट नहीं हो सका” जैसे popup नहीं दिखने चाहिए थे और सिस्टम को मज़बूती से चलना चाहिए था।
transaction की भी ज़रूरत नहीं थी, और किसी भी स्थिति में data को RAM में पढ़ पाना ज़रूरी था
→ server के बिना चलने वाला SQL DB engine खोजा, लेकिन ऐसा कुछ मिला नहीं, इसलिए खुद बनाने का फैसला किया

SQLite V1 (2000)

SQL statements को program की तरह मानकर query को compile और execute करने वाला bytecode engine लिखा
वास्तव में यह project में इस्तेमाल नहीं हुआ (ग्राहक Informix ही इस्तेमाल करना चाहता था)
इसे development purpose के लिए इस्तेमाल करते हुए इंटरनेट पर सार्वजनिक किया, और लोगों ने इसका उपयोग शुरू कर दिया
“मैंने Palm Pilot पर SQL DB चलाया” जैसी बातें सुनने को मिलीं और लोगों का ध्यान इस पर गया। इससे आगे काम जारी रखने का उत्साह मिला।

Motorola

2001~2002 के बीच Motorola से फोन आया कि वे अपने नए phone OS में SQLite डालना चाहते हैं
ज़रूरी features support कर दिए जाएँ तो वे पैसे देने को तैयार थे
तभी पहली बार पता चला कि open source से भी पैसे कमाए जा सकते हैं
लगभग $80,000 मिले; आज के हिसाब से बहुत बड़ी रकम न सही, लेकिन उनके लिए यह बेहद चौंकाने वाली रकम थी।
अपने साथ काम कर रहे तीन लोगों के साथ project शुरू किया, और वहीं से यह यात्रा शुरू हुई

America Online Phones

इसके बाद संपर्क करने वाली अगली कंपनी AOL थी
वह CD डाक से भेजने का दौर था, और उन CDs के अंदर database की ज़रूरत थी
यानी वे CD के भीतर SQLite शामिल करना चाहते थे और कुछ नए features भी चाहिए थे

Symbian OS और Nokia

Thanksgiving पर London जाकर meeting की (क्योंकि UK में Thanksgiving नहीं होता)
उन्हें Symbian OS के लिए DB चाहिए था, और SQLite ने दूसरे DBs के साथ प्रतिस्पर्धा की (2 open source, 7 commercial)
बाकी 9 DBs को tuning का मौका दिया गया, लेकिन अंत में SQLite जीता

Bus Factor [1] और consortium

bus factor वह metric है जो बताता है कि कितने लोगों के बस से टकराने पर development रुक जाएगा
Richard full-time कई लोगों के साथ काम कर रहे थे, लेकिन Symbian की तरफ़ से कहा गया कि bus factor बढ़ना चाहिए
SQLite consortium शुरू करने का विचार आया ताकि project को funding मिले और लंबे समय तक अधिक लोग इसमें जुड़ें
शुरुआत में उन्होंने यह अजीब-सा विचार रखा कि consortium के हर member को voting rights दिए जाएँ
Mozilla Foundation की Mitchell Baker ने यह बात कहीं सुनी और फोन किया
→ “Richard, आप यह पूरी तरह गलत कर रहे हैं। मैं आपको consortium बनाना सिखाती हूँ।”
→ फिर उन्होंने नियम बनाने शुरू किए
→ “control developers के पास होना चाहिए। उनका फैसला अंतिम होना चाहिए। सिर्फ़ शामिल होने भर से voting rights नहीं मिल जाने चाहिए।”
→ “जो कंपनियाँ इसका इस्तेमाल करती हैं, उन्हें धन देने का सम्मान मिलेगा, लेकिन अंतिम निर्णय आपको लेना होगा।”
→ वह बहुत दृढ़ थीं और उन्होंने सब कुछ व्यवस्थित कर दिया। वह वकील हैं।
Richard ने पूछा, “लोग इसमें क्यों जुड़ेंगे? incentive क्या होगा?”
→ “चिंता मत कीजिए। वे जुड़ेंगे। और अगर आप ऐसा करते हैं, तो Mozilla founding member बनेगा।”
Mozilla, Symbian और Adobe के समर्थन से consortium की शुरुआत हुई
→ जब Symbian ने पहली बार कहा कि consortium की ज़रूरत है, तब उन्हें समझ नहीं आया कि क्या करना चाहिए। Mitchell Baker को यह कैसे पता चला और उन्होंने फोन कैसे किया, यह उन्हें आज भी नहीं पता, लेकिन यह पूरा सफ़र अद्भुत रहा।

Enter Android : Android की शुरुआत

क्योंकि सभी smartphones SQLite का उपयोग कर रहे थे, Richard शुरुआती smartphone development को लगभग हर कोण से देख पा रहे थे
2005 में Android के साथ meeting हुई। तब तक न Android आया था, न iPhone
एक BlackBerry जैसे phone से connect करके SQLite debug किया गया, जिसमें ऊपर छोटा display और पूरा QWERTY keyboard था
असली working phone network से जुड़े device पर GDB से debugging करना अद्भुत अनुभव था
उस समय Motorola, Symbian और Nokia में से कोई भी ऐसा नहीं कर रहा था, और तभी उन्हें लगा कि Android बहुत बड़ा बनने वाला है

Guy, This Is Important : दोस्तों, यह सच में बहुत महत्वपूर्ण है

उस दौर में दूसरी कंपनियों के hardware और software update cycles लगभग 30 दिन के होते थे, लेकिन Android असली network से जुड़े phones में दिन में कई बार नया OS डाल रहा था।
NDA के तहत मिला prototype Android phone ऐसा लगता था जैसे उसका case 3D print किया गया हो, लेकिन फिर भी उसे साथ लेकर चला जा सकता था।
→ दूसरी कंपनियों के prototypes बड़े breadboard जैसे थे और network से भी जुड़े नहीं थे, इसलिए उन्हें phone की तरह इस्तेमाल ही नहीं किया जा सकता था
वे Motorola और Symbian के लोगों से कहना चाहते थे, “यह बहुत महत्वपूर्ण है, तुम्हें यह solve करना होगा,” लेकिन NDA की वजह से कह नहीं सकते थे। और इसी ने अंतर पैदा किया।

Testing and Aviation Standards : testing और aviation standards

Adam (interviewer): “आज Richard का DB बहुत सक्रिय स्थिति में है। टीम प्रतिभाशाली है, लेकिन यह 1~4 लोगों की एक software consulting company है जो हर Android phone में जाने वाले DB को support करती है। डेवलपर्स DB को लेकर बहुत गंभीर हैं और data में समस्या आना उन्हें पसंद नहीं।”
हम भोलेपन में सबको बताते थे कि SQLite में कोई bug नहीं है, लेकिन Android ने साफ़ दिखा दिया कि हम गलत थे।
हमें लगा था कि bug-free software बन सकता है, लेकिन जब software लाखों devices पर install होता है, तब कितने bugs निकल सकते हैं, यह चौंकाने वाला था।
लगभग उसी समय वे avionics company Rockwell Collins के साथ काम कर रहे थे, और वहीं उन्होंने DO-178B [2] की अवधारणा से परिचय कराया।
→ DO-178B safety-critical aviation products के quality standard से जुड़ा है, और दूसरे quality standards के विपरीत यह “पढ़ने लायक (readable)” है
→ इसकी कीमत कुछ सौ डॉलर है, लेकिन यह पतला है, इसलिए इसे ज़रूर पढ़ने की सलाह दी गई
उन्होंने वास्तव में DO-178B की process follow करनी शुरू की, जिनमें से एक थी 100% MCDC test coverage
MCDC (Modified Condition / Decision Coverage) [3] का मतलब है कि testing में हर individual branch कम-से-कम एक बार तो cover हो
SQLite को 100% MCDC तक पहुँचाने में, हफ़्ते के 60 घंटे के हिसाब से, एक साल लगा। यह बेहद कठिन था। रोज़ 12 घंटे काम करना पड़ता था और वे बुरी तरह थक जाते थे।
90~95% test coverage आसान है, लेकिन आख़िरी 5% बहुत कठिन। लेकिन एक साल की मेहनत के बाद जब 100% तक पहुँचे, तो Android से bug reports आना बंद हो गया
वहीं से चीज़ें सही चलने लगीं और बड़ा फ़र्क पड़ा। उसके बाद 8~9 साल तक कोई bug नहीं आया।

अरबों tests

पहला test TCL (Tool Command Language) में लिखा गया था, और वह सामान्य developer testing के लिए था
पहला TCL test आज भी maintain किया जा रहा है और सार्वजनिक है। 100% नहीं है, लेकिन SQLite की लगभग सारी functionality को विस्तार से test करता है।
100% MCDC coverage वाले suite को TH3 कहा जाता है और वह सार्वजनिक नहीं है (proprietary)
इसे aviation companies को बेचकर पैसा कमाने की कोशिश की गई, लेकिन एक भी copy नहीं बिकी, इसलिए उस लिहाज़ से यह सफल नहीं रहा..
लेकिन इसने हमारे product को बेहद मज़बूत बनाए रखने और नए features व bug fixes जल्दी करने में बहुत मदद की
tests की संख्या गिनना मुश्किल है, लेकिन 100,000 individual tests parameterize होकर अरबों test runs बनाते हैं
एक checklist है, और release से पहले कम-से-कम 3 दिन तक testing की जाती है
जानबूझकर कई OSes पर testing की जाती है
→ आजकल लगभग सारे devices little-endian हैं, लेकिन पहले big-endian systems भी बहुत थे। इसलिए PowerPC iBook पर big-endian tests किए जाते थे
→ 32-bit platforms, ARM और Intel, 64-bit platforms, Windows, Linux, Mac, OpenBSD आदि—जितने platforms और OSes पर संभव हो, सब पर test किया जाता है
→ कई अलग-अलग test suites हैं; मूल TCL suite भी है, TH3 भी है। लगातार चलने वाला fuzzer (fuzz testing) भी है।
SQL Logic test भी है
→ 10 साल पहले Shane Harrelson ने SQL statements का एक विशाल संग्रह बनाया था
→ इसे हर उस DB पर चलाया गया जिसे हाथ लगाया जा सकता था, और लगभग हर DB engine सही answer देने में विफल रहा या segmentation fault दे बैठा। SQLite भी उनमें था। सिर्फ़ Postgres अपवाद था।
→ केवल Postgres ही लगातार result देता रहा और उसमें कोई कमी नहीं मिली। Postgres developers ने कहा कि शायद हमने पर्याप्त कोशिश नहीं की.. Postgres में error निकालना शायद संभव रहा हो, लेकिन हम बहुत प्रभावित हुए
→ commercial Oracle version भी crash हुआ, और DB2 भी crash हुआ
→ महत्वपूर्ण बात यह थी कि SQLite को इन सभी queries पर एक जैसा उत्तर देने लायक बनाया गया

Building From First Principles

जब उन्होंने शुरुआत की, तो यह देखने की कोशिश की कि SQL DB engine कैसे बनाया जाता है, इस पर कोई reference मिलता है या नहीं, लेकिन कुछ नहीं मिला। इसलिए सब कुछ खुद बनाना पड़ा; यह पूरी तरह स्वतंत्र मिशन था।
MIT, Harvard और Berkeley में बहुत-सा theory work हो रहा था, लेकिन अगर आप उन संस्थानों में न हों तो आपको यह भी पता नहीं चलता कि ऐसा theory work मौजूद है, न ही उसे ढूँढने का तरीका पता चलता
Postgres का Volcano model और SQLite का bytecode model देखने पर अंततः एक ही तरह के विचारों पर पहुँचते दिखते हैं
ऊपर से देखें तो शुरुआती बिंदु बहुत अलग लगते हैं, लेकिन performance बढ़ाने की कोशिश में दोनों एक ही दिशा में converge करते हैं
उन्हें लगता है कि सिद्धांत के स्तर पर यह एक तरह का validation है: दो स्वतंत्र development lines का एक ही उत्तर तक पहुँचना
उदाहरण के लिए, उन्हें covering index के बारे में बिल्कुल पता नहीं था। फिर Germany में हुई एक PHP conference में गए, जहाँ MySQL के David Axmark ने भी talk दी
→ उस talk में बताया गया कि MySQL ने covering index कैसे बनाया
→ जब DB index में कई columns हों, और query index के शुरुआती columns पर ही हो तथा answer बाकी columns में ही मिल जाए, तो DB मूल table को पढ़े बिना सिर्फ़ index से काम कर सकता है, जिससे speed बढ़ती है
→ फिर घर लौटते समय flight में, जब आस-पास कम लोग थे, उन्होंने laptop खोला और Atlantic के ऊपर उड़ान के दौरान SQLite में covering index implement कर दिया

B-Trees and The Art of Computer Programming

बहुत-सी चीज़ें खुद बनानी पड़ीं। किसी ने उन्हें B-tree नहीं सिखाया था; उन्होंने बस उसका नाम सुन रखा था।
जब खुद B-tree develop करने की कोशिश कर रहे थे, तो bookshelf में Don Knuth की TAOCP मिली। उसमें B-tree देखा और उन्होंने algorithm समझाया था
मज़ेदार बात यह थी कि किताब में B-tree search और insertion algorithm विस्तार से समझाए गए हैं, लेकिन deletion algorithm नहीं दिया गया। वह chapter के अंत में exercise के रूप में था, इसलिए अपना B-tree बनाने से पहले उन्हें वह सवाल खुद हल करना पड़ा। “धन्यवाद Don, बहुत-बहुत धन्यवाद।”
आज के लोगों को कम-से-कम TAOCP पढ़नी या कम-से-कम पलटकर देखनी तो चाहिए

Freedom to Build It Yourself : खुद बनाने की आज़ादी

SQLite, Richard द्वारा खुद बनाए गए हिस्सों के अलावा, किसी और dependency पर निर्भर नहीं है (C compiler और libc को छोड़कर)। उन्होंने अपना version control system भी बनाया और bug tracker भी। इससे Richard को स्वतंत्रता मिली
freedom का मतलब है अपनी देखभाल खुद करना
backpacking करने वाले लोग जब अपनी ज़रूरत का सब kuch पीठ पर लेकर चलते हैं, तो वे खुद को स्वतंत्र कहते हैं क्योंकि वे अपना ख़याल खुद रख रहे होते हैं
अगर आप सब कुछ खुद बनाते हैं, तो आप किसी और से बंधे नहीं रहते; और इसी में स्वतंत्रता है
मान लीजिए SQLite 2 के storage engine के लिए Berkeley DB चुना गया होता
→ उस समय Berkeley DB open source था, लेकिन बाद में Oracle ने उसे खरीद लिया और वह dual-source proprietary model में चला गया, जिससे license fee दिए बिना latest source code नहीं मिल पाता
आज SQLite का parser generator Yak या Bison नहीं, बल्कि खुद लिखा गया Lemon है; इसलिए जब नए language features की ज़रूरत हुई, तो वे उन tools पर निर्भर हुए बिना इसे बदल सके
2000 के शुरुआती वर्षों में लगभग हर project CVS इस्तेमाल करता था, इसलिए उन्होंने भी वही इस्तेमाल किया। लेकिन 2000 के मध्य तक distributed version control का विचार उभरने लगा

Fossil बनाना

Git और Mercurial को देखने के बाद requirements व्यवस्थित कीं और फिर खुद version control system बनाने का फैसला किया
अब Fossil अच्छी तरह काम करता है और अपने आप में एक project बन चुका है
Linus Torvalds ने Linux Kernel development को support करने के लिए Git बनाया था, इसलिए अगर आपका काम Linux Kernel से जुड़ा है तो Git एकदम सही version control system है
Fossil, SQLite पर काम करने के लिए बिल्कुल उपयुक्त version control system है। क्योंकि इसे मैंने खुद बनाया, यह मेरी requirements को ठीक-ठीक पूरा करता है
खुद develop करके आप अपने भाग्य पर नियंत्रण रखते हैं, अधिक स्वतंत्रता पाते हैं, और third party पर निर्भर नहीं रहते

आत्मनिर्भर बनना

शहर छोड़कर अपना खाना खुद उगाकर जीने वाले लोगों को क्या कहते हैं? Survivalist (जीवित रहने की तैयारी करने वाला)? या Prepper (पूर्वतैयारी करने वाला)?
“जैसा कि आपने मुझसे संपर्क करते समय भी देखा, मेरा Gmail थोड़ा अजीब व्यवहार कर रहा है। mails बार-बार वापस लौट रही हैं। इसलिए मैं अपना mail server बनाना चाहता हूँ। जब हम यह meeting setup कर रहे थे, तब भी मैं उससे जुड़े notes लिख रहा था। यह DB engine लिखने से कठिन तो नहीं होगा, लेकिन मैं Gmail पर निर्भर नहीं रहना चाहता। मैं नहीं चाहता कि वे मेरा भाग्य नियंत्रित करें। मैं नहीं चाहता कि वे मेरी सारी बातचीत का रिकॉर्ड नियंत्रित करें। मैं खुद नियंत्रण चाहता हूँ, इसलिए भले ही यह कष्टदायक हो और इसमें बहुत काम हो, फिर भी मैं ऐसा समाधान खोजने की कोशिश करूँगा जिसे मैं खुद नियंत्रित कर सकूँ। cloud में virtual machine किराए पर लेकर चलाया जा सकता है, ताकि किसी third party पर निर्भर न रहना पड़े।”
अगर कोई आकर कहे कि वह आपकी समस्या हल कर देगा, तो आपको समझना चाहिए कि वह आपकी स्वतंत्रता छीन भी सकता है। “अगर स्वतंत्र रहना है, तो खुद करना होगा।”

दूसरों के लिए सलाह

मैंने एक पागल-से विचार से शुरुआत की थी कि ऐसा DB engine बनाऊँगा जिसे server की ज़रूरत न हो और जो सीधे disk से पढ़े-लिखे।
अगर आप experts से पूछेंगे, तो वे कहेंगे, “यह असंभव है। यह कभी काम नहीं करेगा। यह बेवकूफ़ी भरा विचार है।”
सौभाग्य से मैं ऐसे experts को जानता नहीं था, इसलिए मैंने बस काम शुरू कर दिया, और फिर यह सब हुआ।
experts की बात बहुत ज़्यादा मत सुनिए। जो समझ में आता है, वह कीजिए। अपनी समस्या हल कीजिए

[1] Bus Factor : वह जोखिम स्तर जिसमें किसी team member के अचानक अनुपलब्ध हो जाने पर टीम संकट में पड़ सकती है।

यह उस जोखिम का संकेतक है जो तब पैदा होता है जब team members के बीच जानकारी और functions साझा नहीं होते।
इस संख्या को बढ़ाना ज़रूरी है ताकि जानकारी साझा हो और काम किसी एक व्यक्ति पर केंद्रित न रह जाए।

[2] DO-178B : aircraft systems और equipment certification के लिए software considerations (Software Considerations in Airborne Systems and Equipment Certification)

इसे FAA ने aviation software certification के लिए compliance साबित करने के एक तरीके के रूप में अपनाया है

[3] MCDC : Modified Condition / Decision Coverage

जब कई conditions हों, तब test cases इस तरह डिज़ाइन करने की विधि कि हर individual condition, बाकी conditions से स्वतंत्र रूप से, पूरे condition expression के परिणाम को प्रभावित करे

16 टिप्पणियां

enowy 2025-08-07

इतना अच्छा लेख था। इसका अनुवादित संस्करण पढ़ने को मिलना खुशी की बात है।

mkeasy 2021-07-08

यह ऐसा लेख है जिसे बार-बार पढ़ने का मन करता है। धन्यवाद।

अगर आप स्वतंत्र होना चाहते हैं, तो आपको खुद करना होगा।

ऐसा काम करें जो सार्थक हो।

अपनी समस्या खुद हल करें।

edunga1 2021-07-05

यह सच में बहुत दिलचस्प लेख है!

"90~95% test coverage तक पहुँचना आसान होता है, लेकिन बाकी 5% सच में बहुत मुश्किल होता है. लेकिन 1 साल तक ऐसा करने के बाद आखिरकार 100% तक पहुँच गए, तो Android से bug report आना बंद हो गया"

यह भी हो सकता है, है ना.

panarch 2021-07-05

बहुत अच्छा पढ़ा। धन्यवाद!

jsryu 2021-07-05

बहुत अच्छा लगा पढ़कर। धन्यवाद

falconer 2021-07-05

अच्छी तरह पढ़ा.

gmlwo530 2021-07-05

मज़े से पढ़ा!

kwangyeol 2021-07-05

बहुत रुचि के साथ पढ़ा। धन्यवाद।

baeba 2021-07-05

बहुत अच्छी तरह पढ़ा।

लगता है कि इसे संक्षेप में व्यवस्थित करना और भी मुश्किल होगा।

shaichoi 2021-07-05

अच्छा पढ़ा। इससे बहुत से विचार आए। धन्यवाद :)

fureweb 2021-07-05

बहुत अच्छा लगा पढ़कर। धन्यवाद!

kalihman 2021-07-05

अच्छी तरह पढ़ा.

jongpak 2021-07-05

पढ़ते-पढ़ते समय का पता ही नहीं चला, हाहा

अब मुझे शर्म आ रही है कि मैंने इसे सिर्फ एक साधारण embedded DB समझकर कम आंका था^^;

sixmen 2021-07-05

मैंने इसे बस लोकल डेवलपमेंट के लिए एक साधारण DBMS समझकर इस्तेमाल किया था, लेकिन यह बिल्कुल भी साधारण नहीं निकला!!

nicewook 2021-07-05

इसे पढ़कर बहुत मज़ा आया.

xguru 2021-07-05

इस समय दुनिया भर में 1 ट्रिलियन से ज़्यादा SQLite इंस्टेंस चल रहे हैं.

4 अरब से ज़्यादा सभी स्मार्टफ़ोन (Android, iOS)
Mac/Windows
FF/Chrome/Safari ब्राउज़र
PHP/Python
Skype/iTunes/Dropbox/Turbotax
ज़्यादातर set-top box और TV
ज़्यादातर कारों के मल्टीमीडिया सिस्टम

https://www.sqlite.org/mostdeployed.html