SQLite: फ़ाइल सिस्टम से 35% तेज़

• SQLite छोटे Blob (जैसे: thumbnail image) को अलग-अलग फ़ाइलों में fread() या fwrite() से पढ़ने या लिखने की तुलना में 35% अधिक तेज़ी से पढ़ और लिख सकता है
• साथ ही, 10KB Blob को स्टोर करने वाला एक single SQLite database, Blob को अलग-अलग फ़ाइलों के रूप में स्टोर करने की तुलना में लगभग 20% कम disk space इस्तेमाल करता है
• प्रदर्शन में यह अंतर संभवतः इसलिए होता है क्योंकि SQLite database पर काम करते समय open() और close() system call केवल एक-एक बार किए जाते हैं, जबकि अलग-अलग फ़ाइलों के Blob के साथ काम करते समय हर Blob के लिए open() और close() एक-एक बार कॉल होते हैं। ऐसा लगता है कि open() और close() का overhead, database इस्तेमाल करने के overhead से बड़ा है
• आकार में कमी इसलिए आती है क्योंकि अलग-अलग फ़ाइलें file system block size के अगले multiple तक भरी जाती हैं, जबकि Blob, SQLite database में अधिक सघन रूप से पैक होते हैं

ध्यान देने योग्य बातें

• 35% का आँकड़ा एक मोटा अनुमान है। वास्तविक timing hardware, operating system, और experiment की बारीकियों पर निर्भर करती है, और वास्तविक hardware पर performance में random variation भी होता है
• 35% का आँकड़ा उन सभी systems पर test चलाने के परिणाम पर आधारित है, जिन तक लेखक की आसानी से पहुँच थी। कुछ reviewers ने बताया कि उनके systems पर SQLite की latency direct I/O से अधिक है। इस अंतर को अभी तक समझा नहीं गया है
• यह पाया गया कि cold file system cache के साथ experiment चलाने पर SQLite, direct I/O जितना अच्छा perform नहीं करता
• यह दस्तावेज़ इस आम धारणा का खंडन करता है कि relational database, direct file system I/O से धीमा होना चाहिए
• 2022 के एक अध्ययन के अनुसार, वास्तविक workloads में SQLite, Linux के Btrfs और Ext4 की तुलना में लगभग 2 गुना तेज़ पाया गया

मापन कैसे किया गया

• I/O performance को SQLite source tree के kvtest.c program का उपयोग करके मापा गया
• इस test program को compile करने के लिए, SQLite amalgamation source files sqlite3.c और sqlite3.h के साथ kvtest.c source file को एक directory में रखें, फिर Unix पर नीचे जैसे command चलाएँ
• इस command से बनने वाले kvtest program का उपयोग 100,000 random uncompressed Blob से बना test database बनाने के लिए किया जाता है, जहाँ हर Blob का आकार 8,000 bytes से 12,000 bytes के बीच होता है
• सभी Blob की copies को directory में अलग-अलग files के रूप में बनाने के लिए --tree command-line option के साथ export command चला सकते हैं
• database से Blob पढ़ने और अलग-अलग files से Blob पढ़ने के performance को मापने के लिए नीचे दिए गए commands का उपयोग किया जाता है
• --blob-api option का उपयोग करने पर, SQLite SQL statements चलाने के बजाय sqlite3_blob_read() function का उपयोग करके Blob content लोड कर सकता है, जिससे read test में यह थोड़ा और तेज़ चलता है

read performance मापन

• Windows10 पर SQLite database से content को disk से सीधे पढ़ने की तुलना में लगभग 5 गुना तेज़ी से पढ़ा जा सकता है
• Android पर SQLite, disk से पढ़ने की तुलना में लगभग 35% तेज़ है
• memory-mapped database में sqlite3_blob_read() का उपयोग करके पढ़ने पर Mac और Android में यह disk से अलग-अलग files पढ़ने की तुलना में 2 गुना तेज़ है, और Windows में 10 गुना तेज़

write performance मापन

• सभी systems में direct I/O और SQLite दोनों के लिए write performance, read की तुलना में 5 से 15 गुना धीमी है
• write test में antivirus software का SQLite write पर लगभग कोई असर नहीं पड़ता, लेकिन disk पर direct write लगभग 10 गुना धीमा हो जाता है
• संभवतः ऐसा इसलिए है क्योंकि SQLite केवल एक single database file को बदलता है, जबकि disk पर direct बदलाव करने में हज़ारों अलग-अलग files बदलती हैं जिन्हें antivirus को scan करना पड़ता है

सामान्य परिणाम

• SQLite, read और write दोनों में अलग disk files में स्टोर किए गए Blob के मुकाबले प्रतिस्पर्धी है और आमतौर पर अधिक तेज़ है
• antivirus protection चालू होने पर Windows में SQLite, disk पर direct write की तुलना में कहीं अधिक तेज़ है
• सभी systems में, और SQLite तथा direct disk I/O दोनों के लिए, read लगभग write से 10 गुना तेज़ है
• I/O performance operating system और hardware के अनुसार काफ़ी बदलती है। निष्कर्ष निकालने से पहले अपना खुद का मापन करना ज़रूरी है
• कुछ अन्य SQL database engines developers को सलाह देते हैं कि Blob को अलग files में स्टोर करें और फिर database में file name रखें। ऐसे मामलों में पूरे Blob को database में स्टोर करना SQLite में कहीं बेहतर read और write performance देता है

GN⁺ की राय

• SQLite का प्रदर्शन अलग-अलग files को पढ़ने और लिखने से बेहतर होना बहुत दिलचस्प है। इससे database इस्तेमाल करने वाले applications की performance बेहतर करने में मदद मिल सकती है
• हालांकि, यह benchmark result हर स्थिति पर सामान्य रूप से लागू नहीं होता। यह data की प्रकृति, access pattern, hardware configuration आदि पर निर्भर कर सकता है। महत्वपूर्ण applications के लिए वास्तविक workload के साथ benchmark करना ज़रूरी है
• SQLite का एक और फ़ायदा यह है कि यह antivirus scan से बच सकता है। यह बड़ी संख्या में छोटी files संभालने वाले applications में विशेष रूप से उपयोगी हो सकता है
• SQLite की कमी यह है कि सारा data एक ही file में स्टोर होता है, इसलिए यदि database file corrupt हो जाए तो सारा data खो सकता है। इसलिए database file का नियमित backup लेना महत्वपूर्ण है

[iolothebard]

या तो डेटाबेस में फ़ाइल attributes (फ़ाइल नाम, आकार, access permissions, …) तक की पहुँच भी शामिल होनी चाहिए,
वरना क्या इसकी तुलना file I/O नहीं बल्कि block I/O से करनी चाहिए, ऐसा लगता है…
जो भी हो, SQLite तेज़ तो है ही।

[GN⁺]

Hacker News राय

• फ़ाइल सिस्टम attributes या metadata नहीं होने से अतिरिक्त attribute लिखने या update करने की ज़रूरत नहीं पड़ती, और physical file या pipe/symbolic link की जाँच, permission checks, block size alignment mismatch जैसी चीज़ें भी नहीं होतीं, इसलिए सिर्फ़ एक ही open command काफ़ी होती है

  • जब features छोड़ दिए जाएँ और general-purpose design को नज़रअंदाज़ किया जाए, तो यह बात समझ में आती है
  • SQLite के लिए fuse mapping इस्तेमाल करके और directory को mount करके access करने पर performance समान या उससे भी धीमी हो सकती है
  • अगर attributes disable करके optimized block size के साथ custom file system बनाया जाए, तो similar performance मिल सकती है
  • rsync जैसे shell commands का उपयोग करके files को browse और manipulate करने की सादगी होती है
  • SQLite packaged static assets या appliance-type applications के लिए उपयुक्त है

• Windows 10 में 4 गुना speed increase यह दिखाता है कि Windows file system calls कितनी धीमी हैं

• digital piano से निकलने वाले सभी notes को real time में log करने का एक विचार था

  • SQLite का उपयोग करके इसे एक single table में store किया गया, जहाँ हर row piano का एक MIDI event है
  • performance अच्छी है और बाद में analysis किया जा सकता है

• database lab में OS research से इसकी तुलना करना दिलचस्प लगा

  • relational databases छोटे individual records और consistency के लिए optimized होते हैं
  • row size बढ़ने पर performance तेज़ी से गिरती है

• WAL2 mode में sqlite DB में append करने पर विचार किया जा रहा है

  • write performance penalty लगभग नहीं है और read/analysis में बड़ा फ़ायदा है

• SQLite database में open() और close() system calls सिर्फ़ एक बार call होते हैं

  • individual files में blobs इस्तेमाल करने की तुलना में overhead कम होता है

• SQLite blob fields का उपयोग करके files store करना recommended नहीं है

  • blob का maximum size 2GB है
  • objects को bytes में serialize/deserialize करना पड़ता है
  • दूसरे systems/services के साथ interact करने के लिए files की ज़रूरत होती है
  • SQLite में parallel requests संभालने की settings हैं, लेकिन competing requests की वजह से database lock हो जाता है

• file system के ऊपर बनी कोई चीज़ file system से तेज़ है, इसका मतलब है कि file system को unoptimized तरीके से इस्तेमाल करने पर वह धीमा है

• SQLite database में बहुत सारी rows delete करना files delete करने से धीमा है

• सभी file system/drive access OS द्वारा managed होते हैं

  • database file disk पर clusters के रूप में store होती है
  • database management system खास domains और problems को हल करने के लिए सुविधाजनक रूप से बनाया जाता है

[halfenif]

20 साल पहले मैंने files को Oracle DB में blob के रूप में डालने वाली architecture का अच्छा उपयोग किया था.. लेकिन हर बार लोगों को उसके फ़ायदे समझाने पड़ते थे। बेशक, हर बार सफलता नहीं मिलती थी।

[narusas]

20 साल पहले Oracle SAN DISK की कीमतें शायद काफ़ी ज़्यादा रही होंगी..