SQLite, अमेरिकी Library of Congress का अनुशंसित स्टोरेज फ़ॉर्मैट है

 (sqlite.org)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SQLite को US Library of Congress द्वारा datasets के लिए अनुशंसित storage formats में शामिल किया गया है
  • इसका संबंधित आधार Library of Congress के SQLite format description और डेटा के अनुशंसित फ़ॉर्मैट की सूची में देखा जा सकता है: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
  • 29 मई 2018 के अनुसार, datasets के लिए अनुशंसित storage formats में SQLite के अलावा केवल XML, JSON, और CSV शामिल हैं
  • Library of Congress के अनुशंसित storage formats वे फ़ॉर्मैट हैं जिन्हें preservation experts डिजिटल सामग्री की survivability और long-term accessibility को अधिकतम करने वाला मानते हैं
  • मूल्यांकन मानदंडों में openness, adoption, transparency, self-documentation, external dependencies, patent impact, और encryption जैसे technical protection mechanisms शामिल हैं

SQLite और LoC के अनुशंसित storage formats

अनुशंसित storage formats के मूल्यांकन मानदंड

  • अनुशंसित storage formats वे फ़ॉर्मैट हैं जिन्हें Library of Congress के preservation experts डिजिटल सामग्री की survivability और long-term accessibility को अधिकतम करने वाला मानते हैं
  • Library of Congress अनुशंसित storage formats चुनते समय निम्नलिखित मानदंडों पर विचार करता है

  • openness

    • यह देखा जाता है कि तकनीकी अखंडता की जाँच के लिए पूर्ण specifications और tools उपलब्ध हैं या नहीं, और डिजिटल सामग्री बनाने व बनाए रखने वाले लोगों की उन तक कितनी पहुँच है
    • मान्यता प्राप्त standardization body की स्वीकृति से अधिक पूर्ण documentation को महत्व दिया जाता है

  • adoption

    • यह देखा जाता है कि information resources के प्रमुख निर्माता, वितरक और उपयोगकर्ता उस फ़ॉर्मैट का पहले से कितना उपयोग कर रहे हैं
    • इसमें master format, end-user delivery format, और systems के बीच exchange माध्यम के रूप में उपयोग शामिल है

  • transparency

    • यह देखा जाता है कि क्या साधारण tools से डिजिटल representation का सीधे विश्लेषण किया जा सकता है, जैसे कि text-only editor में मनुष्य द्वारा पढ़ा जा सकना

  • self-documentation

    • self-documented digital objects में बुनियादी descriptive metadata, technical metadata, और अन्य administrative metadata शामिल होते हैं

  • external dependencies

    • यह देखा जाता है कि rendering या उपयोग किसी विशेष hardware, operating system, या software पर कितना निर्भर है, और भविष्य के तकनीकी वातावरण में उस निर्भरता को संभालने की जटिलता कितनी होगी

  • patent impact

    • यह देखा जाता है कि patents उस फ़ॉर्मैट की सामग्री को बनाए रखने की preservation institutions की क्षमता में कितनी बाधा डालते हैं

  • technical protection mechanisms

    • यह देखा जाता है कि क्या encryption जैसे mechanisms लागू हैं, जो trusted repositories में सामग्री के preservation में बाधा बन सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • मुझे हमेशा SQLite से प्रेरणा मिलती है। कुल मिलाकर यह बहुत पसंद है, लेकिन अगर आप लिख नहीं रहे हैं, तो यह कुछ ज़्यादा भारी विकल्प भी हो सकता है
    इसलिए मैं SQLite से आगे नहीं बढ़ पाया, लेकिन मैंने एक ऐसा फ़ॉर्मैट बनाया जो इससे कहीं हल्का और तेज़ है, और zstd compressed files पर भी काम करता है। इसका index बहुत छोटा है और SQLite की तरह binary या text रख सकता है
    decompress, read और search संभालने वाला wasm हिस्सा uncompressed के आधार पर 38KB है, और gzip के आधार पर शायद लगभग 16KB। SQLite के wasm और glue code के 1.2MB से तुलना करें तो यह 3% आकार है, लेकिन search और loading कहीं तेज़ हैं
    मेरा प्रोग्राम column-oriented नहीं है और spreadsheet management के लिए उपयुक्त नहीं, लेकिन dictionary और image/audio file archives के लिए बहुत अच्छा है
    मैंने jbig2 decoder को भी 17KB wasm module में port किया है, ताकि प्रति पेज 8KB वाले black-and-white scans भी पढ़े जा सकें और वे अब भी पहचानने लायक हों
    https://github.com/tnelsond/peakslab
    SQLite बहुत अच्छी तरह डिज़ाइन किया गया है, और PeakSlab बहुत सरल है

    • आपने “SQLite का wasm और glue code 1.2MB” कहा, लेकिन वर्तमान trunk में standard unminified form वास्तव में 1.7MB है। उसमें docs लगभग JS code जितने ही हैं, इसलिए WASM और JS लगभग आधे-आधे बँटे हैं। हालाँकि minify करने पर 1.2MB सही है
      संदर्भ के लिए, उसका maintainer मैं ही हूँ
      current trunk के अनुसार संख्याएँ हैं sqlite3.wasm 896745, sqlite3.mjs 816270 (docs सहित unminified), sqlite3.mjs 431388 (docs के बिना unminified), sqlite3.mjs 310975 (minified)
    • PeakSlab के बारे में पहले नहीं जानता था, लेकिन यह सच में शानदार और नया लगता है। dictionary performance भी बेहतरीन लगती है, बाद में फिर इस्तेमाल करने के लिए bookmark करने लायक है
    • यह पुराने Berkeley DB के साथ प्रतिस्पर्धा करने वाली चीज़ के ज़्यादा क़रीब लगता है: https://en.wikipedia.org/wiki/Berkeley_DB
      अभी देखा तो यह अब BSD license भी नहीं है, और खैर SQLite की वजह से लगभग गायब हो गया, लेकिन मूल disk-based key-value storage उपयोगों में यह काम आता था
    • SQLite भी अपने आप में काफ़ी सरल है, और उसके SQL dialect के design principles मुझे पसंद हैं
      जैसे “right join बस उल्टी दिशा का left join है, इसलिए उसकी ज़रूरत नहीं”
      बेशक, इससे भी सरल या अधिक specialized चीज़ें हमेशा संभव हैं। database इस्तेमाल करने वाले बहुत से apps सिर्फ SQLite से ही बढ़िया चलेंगे, और कुछ apps को SQLite जैसी DB के बजाय सिर्फ text files ही काफ़ी लगेंगी
    • ज़्यादा standard समाधान शायद cdb होगा। हालाँकि यह compressed data सपोर्ट नहीं करता
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • मुझे SQLite हमेशा पसंद रहा है, लेकिन सुना है कि कुछ कंपनियाँ इसके इस्तेमाल पर रोक लगाती हैं
    वजह यह है कि app के लिए database बनाना बहुत आसान हो जाता है, इसलिए application का बेहद core component बस एक file जैसा दिखने लगता है। उस file का कोई भी extension हो सकता है, और उसे दूसरे server पर copy भी किया जा सकता है। उसके भीतर PII हो तो भी यही बात लागू होती है
    अगर सोचें कि कंपनी के अंदर apps की संख्या जितनी है, उतनी बार यह स्थिति बढ़े, तो काफ़ी अराजकता हो सकती है
    DevOps और DBA teams चाहती हैं कि database कोई बड़ा, भारी-भरकम उपकरण हो जो साफ़-साफ़ database server जैसा दिखे। उससे connect करना भी स्पष्ट दिखाई दे, वगैरह
    फिर भी, मुझे SQLite अब भी पसंद है

    • तो फिर जिज्ञासा है कि क्या वही कंपनियाँ Excel पर भी प्रतिबंध लगाती हैं। Excel spreadsheets अक्सर अनपेक्षित जगहों पर shadow database बन जाते हैं
    • “कुछ भी mission-critical database बन सकता है” वाली बातचीत के लिए यह पोस्ट अनिवार्य पढ़ाई होनी चाहिए
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • अगर “ऐसी file जिसका कोई भी extension हो सकता है” समस्या है, तो magic number पढ़ लीजिए। वैसे भी file extension पर भरोसा नहीं करना चाहिए
      “दूसरे server पर copy किया जा सकता है” यह बात spreadsheet पर भी लागू होती है
      मैं यह नहीं कह रहा कि centralized data access वांछनीय नहीं है, लेकिन वह तर्क काफ़ी परिष्कृत नहीं लगता
    • SQLite का यह दिलचस्प उपयोग भी है: https://sqlite.org/sqlar.html
    • इसलिए ऐसी config files को AppData या dotfile directory में, या MacOS में ~/Library के भीतर उसके समकक्ष स्थान पर रखा जाता है

  • पहले मैं सोचता था, “SQLite खिलौना-स्तर का product है और असली data के लिए भरोसेमंद नहीं,” लेकिन अब मैं “लगभग हर चीज़ के लिए SQLite इस्तेमाल करो” वाले पक्ष में आ गया हूँ
    अगर आप single writer, multiple readers pattern में फिट हो सकते हैं, तो SQLite बहुत बढ़िया है। सही settings इस्तेमाल करें तो data नहीं खोता, और वे settings 1 मिनट की खोज में मिल जाती हैं
    आजकल मेरे ज़्यादातर apps बस Go binary + SQLite + systemd service file के संयोजन हैं
    मैंने अभी तक data नहीं खोया, performance शानदार है, और ज़्यादातर apps के लिए यह काफ़ी है

    • single writer वास्तव में उतनी बड़ी समस्या नहीं है जितनी अक्सर बताई जाती है। आजकल के NVMe drives कमाल के हैं, इसलिए optimized WAL settings के साथ प्रति सेकंड 5,000 writes आसानी से मिल जाती हैं। ज़्यादातर apps के लिए यह कल्पना से बाहर का स्तर है
      मैंने तो साधारण VPS पर batch writer pattern के साथ 180,000 writes per second भी हासिल किए हैं
    • क्या आप कई backend nodes इस्तेमाल करते हैं? अगर हाँ, तो यह भी जानना चाहूँगा कि अलग-अलग nodes से SQLite file को कैसे access करते हैं

  • इसमें “इस लेख को लिखते समय (2018-05-29)…” लिखा है, तो यह लगभग 8 साल पुरानी खबर है। फिर भी, मुझे आज तक यह पता नहीं था, इसलिए शिकायत नहीं है; पोस्ट करने के लिए धन्यवाद कहना ज़्यादा सही होगा
    मेरा गणित वाला दिमाग़ एक पल के लिए अटक गया और मैंने इसे 6 साल पुराना समझ लिया

    • अभी 2026 है, तो यह 8 साल पुराना हुआ
    • पढ़ते समय déjà vu जैसा लगा

  • 2026 के recommended storage formats: https://www.loc.gov/preservation/resources/rfs/data.html

    • अगर data को 300~500 साल बाद तक के लिए सुरक्षित रखना है, और हर तरह के innovation तथा बुनियादी तकनीकी aging को झेलने लायक बनाना है, तो long-term thinking सच में ज़रूरी है
      सबसे लंबे समय तक बचा रहने वाला paper medium कौन-सा है?
    • recommendation criteria काफ़ी ढीले लगते हैं। XLS “preferred” में शामिल है

  • public-sector data preservation के लिए SQLite सबसे अच्छे विकल्पों में से एक हो सकता है
    इसकी specification खुली है, यह व्यापक रूप से अपनाया गया है, और भविष्य में भी इसे पढ़ पाना संभव रहने की संभावना ज़्यादा है
    किसी खास operating system या service पर निर्भरता कम है, और patent risk भी कम है
    long-term sustainability के नज़रिए से किसी खास company या service पर निर्भर न होना बहुत महत्वपूर्ण है

    • archivists ऐसे formats भी पसंद करते हैं जो original के काफ़ी क़रीब हों। SQLite relational relationships को वैसे ही समेट सकता है, जिन्हें CSV में व्यक्त करना मुश्किल है

  • मुझे SQLite पसंद है और अच्छा लगा कि यह साझा किया गया, लेकिन title के अंत में शायद “(2018)” होना चाहिए
    इसमें लिखा है, “इस लेख को लिखते समय (2018-05-29), datasets के लिए recommended दूसरे storage formats सिर्फ XML, JSON, CSV हैं”

    • FYI, उसके बाद सूची में बहुत से formats जोड़ दिए गए
      preferred formats के रूप में, जब तक data complete रहे और details व precision बनी रहे, platform-independent character-based formats को native या binary formats पर प्राथमिकता दी जाती है। इसमें अच्छी तरह विकसित और व्यापक रूप से अपनाए गए de facto market standards शामिल हैं
      उदाहरण के लिए, public validation tools वाले well-known schema-based formats, TSV·CSV·fixed-width जैसे line-oriented formats, और .db·.db3·.sqlite·.sqlite3 जैसे platform-independent open formats शामिल हैं
      साथ ही proprietary formats भी शामिल हैं जो कुछ professions में de facto standard हैं या कई tools द्वारा supported हैं। जैसे Excel .xls/.xlsx, Shapefile
      character encoding में UTF-8, BOM सहित UTF-16, US-ASCII या ISO 8859-1, और उसके बाद अन्य named encodings को प्राथमिकता है
      acceptable formats में data के लिए ऐसे non-proprietary open documented formats शामिल हैं जिन्हें किसी specialist community या government agency ने standard के रूप में approved किया हो (CDF, HDF आदि), और ऐसे text-based data formats जिनके usable schemas उपलब्ध हों
      bundling या transfer के लिए encryption, password या अन्य protection mechanisms के बिना ZIP, RAR, tar, 7z स्वीकार्य हैं
      https://www.loc.gov/preservation/resources/rfs/data.html

  • कल ही मैं सोच रहा था कि HN के शीर्ष पर SQLite पर पोस्ट देखे काफ़ी समय हो गया
    मुझे SQLite की simplicity और speed बहुत पसंद है, और मैंने इसे personal projects और work projects दोनों में इस्तेमाल किया है
    फिर भी, रोज़मर्रा के काम में अंततः मैं Excel पर चला जाता हूँ। Excel ज़्यादा पसंद होने की वजह से नहीं, बल्कि इसलिए कि यह इतना व्यापक है कि कम technical stakeholders या executives के साथ dataset साझा और explore करने का यह सबसे कम friction वाला तरीका बन जाता है

    • मुझे नहीं लगता कि इससे आपका worldview अचानक टूट जाएगा, लेकिन यह मेरे लिए उपयोगी रहा है, इसलिए शायद आपके लिए भी हो — Metabase देख सकते हैं
      इसे self-host किया जा सकता है, और अगर आप सिर्फ stakeholders को data आसानी से समझ आने वाले रूप में दिखाना चाहते हैं, तो यह सच में बहुत simple है। हाँ, अगर बहुत गहराई में चले जाएँ तो ज़िंदगी के हर फ़ैसले पर पछतावा हो सकता है, लेकिन मैं खुद को वहाँ तक नहीं जाने देता
      https://www.metabase.com/
    • SQLite के काम करने के लिए text parsing पर निर्भर होना मुझे हमेशा खटकता रहा है। query text में ही क्यों लिखनी पड़े, program logic के रूप में क्यों नहीं व्यक्त की जा सकती, यह समझ नहीं आता
      इसी वजह से मैंने कभी relational database इस्तेमाल नहीं किया। क्योंकि मुझे यह नापसंद है। मुझे पता है कि यह pure structured data से बेहतर performance दे सकता है, लेकिन SQL और SQL का पूरा विचार ही मुझे पसंद नहीं, और न मैं इसे लिखना/सीखना चाहता हूँ, न उस पर निर्भर systems इस्तेमाल करना चाहता हूँ
      यह PHP-स्तर की ग़लत दिशा जैसा लगता है। क्या इसे कम करने का कोई तरीका है? मैं सिर्फ SQL की वजह से SQLite को छोड़ते रहना नहीं चाहता, लेकिन यह बात मेरे गले नहीं उतरती। strings बनाना, या stack में कहीं भी string parsing होना, मुझे ग़लत लगता है

  • SQLite चौंकाने वाली हद तक versatile है। बस कुछ हफ़्ते पहले ही SQLite में inter-process queues, streams, publish/subscribe लागू करने वाला extension जारी हुआ था
    Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    real-time notifications, SQLite backend के साथ पूरी app बनाने में missing बड़े हिस्सों में से एक थे, और अब उसके लिए काफ़ी अच्छा समाधान मौजूद है

  • SQLite को इस स्तर की institutional recognition मिलते देख अच्छा लगता है। single-file format की वजह से archive storage, traditional database dump की तुलना में बेहद सरल हो जाता है