S3 फ़ाइल सिस्टम नहीं, बल्कि फ़ाइल स्टोरेज तकनीक है

 (calpaterson.com)
2 पॉइंट द्वारा GN⁺ 2024-03-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Amazon S3 2006 में आई शुरुआती cloud तकनीक है; फ़ाइल स्टोर करने में मजबूत है, लेकिन Unix file API का सीधा विकल्प बनने वाला file system नहीं है
  • Unix file API open, read, write, seek, close जैसे संकरे interface के पीछे buffering, page cache, permissions, IO scheduling को छिपाने वाले deep module के करीब है
  • S3 GetObject और PutObject पर केंद्रित होने से सरल लगता है, लेकिन Range के जरिए केवल partial read संभव है और partial overwrite सपोर्ट नहीं करता
  • Postgres, SQLite, MySQL, MongoDB, Elasticsearch जैसे databases page-level overwrite पर निर्भर करते हैं, इसलिए SQLite या DuckDB फ़ाइल को सीधे S3 पर डालने का तरीका छोटे datasets के अलावा आम तौर पर उपयुक्त नहीं होता
  • ऊँची read/write bandwidth और कम operational burden S3 की ताकत हैं, लेकिन rename/move की अनुपस्थिति, धीमी listing, केवल-XML API, local test environment की कमी जैसी सीमाओं को भी ध्यान में रखना चाहिए

S3 फ़ाइलें स्टोर करता है, लेकिन file system नहीं है

  • S3 2006 में आई शुरुआती cloud technology है, और उस समय प्रचलित शब्दों के अनुसार इसे “object store” कहा गया
  • व्यवहार में यह फ़ाइल storage के रूप में व्यापक रूप से इस्तेमाल होता है, लेकिन इसे “Amazon Cloud Filesystem” की तरह समझना सिर्फ आंशिक रूप से सही है
  • यह फ़ाइलें अच्छी तरह स्टोर करता है, लेकिन मौजूदा file system के behavior और expectations को ज्यों-का-त्यों replace नहीं कर सकता

Unix file API और deep module

  • Unix file API का core इन पाँच calls में संक्षेपित किया जा सकता है
    • open(filepath): फ़ाइल खोलता है
    • file.read(size=100): मौजूदा position से पढ़ता है और position को आगे बढ़ाता है
    • file.write("hello, world"): मौजूदा position पर लिखता है और position को आगे बढ़ाता है
    • file.seek(94): position को किसी खास byte पर ले जाता है
    • file.close(): फ़ाइल बंद करता है
  • ये calls वास्तविक system calls के पूरे set में core मानी जा सकती हैं, और file read/write के लिए जरूरी न्यूनतम functionality के करीब हैं
  • संकरे interface के पीछे बहुत सारी processing होती है, इसलिए Unix file API को deep module माना जा सकता है
    • buffering और page cache
    • fragmentation handling
    • permission management
    • IO scheduling
    • SD card में wear-levelling जैसी सुविधाओं का लाभ भी users को बिना खुद ध्यान दिए मिल जाता है

Shallow module और YAML, ORM

  • shallow module में जो functionality दी जाती है, उसकी तुलना में API surface अपेक्षाकृत बड़ा होता है
  • आज shallow module पहचानने का एक संकेत यह है कि interface YAML हो
    • YAML markup language जैसा दिखता है, लेकिन वास्तव में इसे लगभग किसी भी semantics को जोड़ सकने वाले reusable syntax की तरह इस्तेमाल किया जाता है
    • DevOps क्षेत्र में YAML अक्सर “programming language” की तरह behave करता है
    • अगर YAML mini-language loop structure देती है, तो उसके Turing-complete होने की संभावना होती है
  • shallow module हमेशा खराब नहीं होते
    • SQL ORM मूलतः leaky abstraction है और SQL समझे बिना इस्तेमाल करना मुश्किल है
    • कुछ मामलों में shallow module संभवतः सबसे अच्छा रूप हो सकता है
  • समान परिस्थितियों में, अधिक deep module बेहतर होता है

S3 API सरल है, लेकिन file API से अलग है

  • Unix file API 1970 के दशक की शुरुआत में स्थापित हो गया था, और compatibility के लिए interface कायम रखते हुए internal implementation कई बार बदला गया
  • Amazon S3 Unix file system API को फिर से implement नहीं करता
  • S3 की basic operations Unix file API से केवल आंशिक रूप से match करती हैं
    • GetObject(Bucket, Key, Range=None): पूरे object या उसके हिस्से को पढ़ता है
    • PutObject(Bucket, Key): पूरा object लिखता है
  • bucket नाम का अतिरिक्त concept है, लेकिन functionality की तुलना में interface ratio देखें तो S3 को Unix file API से भी सरल कहा जा सकता है
  • निर्णायक फर्क partial overwrite की अनुपस्थिति है
    • GetObject के Range argument से object का हिस्सा पढ़ा जा सकता है
    • object के केवल किसी हिस्से को overwrite करना संभव नहीं है
    • overwrite पूरी फ़ाइल के स्तर पर करना पड़ता है
  • इसी फर्क के कारण S3 मौजूदा file use cases में से केवल कुछ के लिए ही अच्छा fit है

Databases को S3 पर ज्यों-का-त्यों port करना मुश्किल है

  • कई databases अपना data file system पर files में स्टोर करते हैं
    • Postgres हर table के लिए 2–3 files और कई management files बनाए रखता है
    • SQLite सभी data को single file में स्टोर करने के लिए जाना जाता है
    • MySQL, MongoDB, Elasticsearch भी data को files में स्टोर करते हैं
  • समस्या यह है कि databases आम तौर पर page-level partial overwrite पर निर्भर करते हैं
    • data आमतौर पर 4KB या 8KB जैसे pages में स्टोर होता है
    • heap file के अंदर हजारों pages हो सकते हैं
    • जरूरी data store करने के लिए pages को आंशिक रूप से overwrite किया जाता है
  • अगर SQLite database को S3 पर रखा जाए, तो हर write पर पूरी database file फिर से लिखनी पड़ेगी
  • S3 बड़े writes को तेजी से handle कर सकता है, लेकिन सबसे छोटे datasets को छोड़कर हर बार पूरी file overwrite करने की strategy संभालना मुश्किल है
  • हर बार database file को फिर से लिखने पर database implementers द्वारा बनाई गई transaction integrity का उपयोग करना भी मुश्किल हो जाता है
  • S3 में आखिरी write जीतता है

S3 क्या अच्छा करता है और क्या नहीं

  • S3 की ताकत यह है कि read और write की bandwidth बहुत ज्यादा है
    • online S3 में 10GB प्रति सेकंड से ज्यादा write या read करने के उदाहरण ढूँढना मुश्किल नहीं है
    • S3 write job से एक financial customer के office network को saturate करने का अनुभव भी रहा है
  • partial overwrite की अनुपस्थिति के अलावा भी file system से अलग सीमाएँ हैं
  • S3 में rename या move operation नहीं है
    • rename को CopyObject के बाद DeleteObject से handle किया जाता है
    • CopyObject में file size के अनुपात में linear time लगता है
    • गलत location पर बहुत सारी files लिखने के बाद उन्हें वापस करना बहुत धीमा होता है
  • file listing धीमी है
    • read/write bandwidth बहुत ज्यादा है, लेकिन stored items को list करने का काम कहीं ज्यादा धीमा है
    • यह धीमे local file system से भी धीमा हो सकता है
  • इसके बदले file system की तुलना में operational burden कम है
    • bucket और key name specify कर दें, बाकी cloud संभालता है
    • backup, offsite replication, provisioning जैसे repetitive tasks का बोझ घटता है
    • provisioning केवल capacity पर नहीं, बल्कि IO operations पर भी लागू होती है

संगठनों के बीच interfaces में deep module ज्यादा महत्वपूर्ण होता है

  • S3 का पहला popular cloud API होना deep API के फायदों से जुड़ा है
  • deep API एक ही system के internal modules के बीच complexity छिपाने में उपयोगी है, और दो कंपनियों के interaction जैसी high-cost relationships में और भी महत्वपूर्ण है
  • कंपनियों के बीच computer systems को जोड़ने को पारंपरिक रूप से integration कहा जाता था, और इसे अक्सर दर्द का पर्याय माना जाता है
  • SAP जैसे बड़े enterprise software deep module नहीं हैं
    • लगभग पूरी organization को SAP समझना पड़ता है
    • मौजूदा working methods के साथ लगातार adjustments करने पड़ते हैं
    • SAP integration projects महंगे और विशाल होते हैं, और failure cases भी दोहराए जाते हैं
  • S3 की internal complexity SAP installation से बहुत कम हो, ऐसा नहीं है
    • Amazon ने S3 को “Simple Storage Service” कहा, लेकिन असल S3 की complexity बड़ी है
    • इसमें queuing theory, IO contention, sharding, और file systems द्वारा handle की जाने वाली कई समस्याएँ शामिल हैं
  • S3 में “simple” वास्तविक सरलता से ज्यादा deep interface के करीब है

S3 के लिए उपयुक्त exceptions और बची हुई सीमाएँ

  • इसका मतलब यह नहीं कि S3 अपने use case की तुलना में महंगा होने की समस्या को नजरअंदाज किया जा रहा है
  • deep module और shallow module की अवधारणाएँ John Ousterhout की A Philosophy of Software Design से आई हैं
  • कुछ databases ऐसे भी हैं जिन्हें शुरू से S3 API को storage layer के रूप में इस्तेमाल करने के लिए design किया गया है
    • Snowflake ऐसा एक उदाहरण है
    • हालांकि यह transparent porting नहीं, बल्कि शुरुआती design decision मांगता है
    • Snowflake कम-से-कम 2016 तक इस decision को बहुत जल्दी लेने का उदाहरण था
  • केवल databases ही S3 पर मुश्किल का सामना नहीं करते
    • कई file formats सस्ते seek को assume करते हैं
    • Zip file S3 की तुलना में disk पर बेहतर performance देने वाला प्रमुख उदाहरण है

S3 में खटकने वाली बातें

  • S3 API केवल XML है
    • JSON 2006 में भी मौजूद था, लेकिन उस समय XML का प्रभुत्व था
    • Amazon का SOAP से REST पर जाते समय JSON version न लाना खटकता है
  • Amazon ने XSD schema maintain करना भी बंद कर दिया
    • XML API का एक मुख्य फायदा schema है, लेकिन अब standard documentation website है
  • Amazon local test environment उपलब्ध नहीं कराता
    • Python में thorough testing के लिए कभी-कभी moto library इस्तेमाल की जाती है
    • moto commercial service testing tool होने के बावजूद volunteers द्वारा maintain की जाती है
  • Amazon S3 checksum सपोर्ट करता है, लेकिन default रूप से enabled नहीं है
    • Amazon durability को लेकर कई दावे करता है
    • वास्तविक समस्या होने की बातें नहीं सुनीं, लेकिन ऐसे दावों के tested examples भी नहीं देखे
  • पहले S3 में eventual consistency का pitfall था
    • file पढ़कर overwrite करने और फिर दोबारा पढ़ने पर अभी तक न बदली हुई content दिख सकती थी
    • यह थोड़े समय के लिए कभी-कभी होता था और confusion पैदा करता था
    • अन्य S3 implementations ने इस behavior को replicate नहीं किया, और Amazon ने भी कुछ साल पहले strong read-after-write consistency के साथ इसे ठीक कर दिया

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

1 टिप्पणियां

 
GN⁺ 2024-03-11
Hacker News की रायें

  • S3 durability भले बढ़ा-चढ़ा कर कही गई लगे, लेकिन भरोसेमंद है, और इसे पारंपरिक file system से तुलना करना मुश्किल है
    फर्क सिर्फ software का नहीं, बल्कि physical infrastructure और safety culture तक फैला है, और AWS का Availability Zone isolation दूसरे clouds से बेहतर लगता है
    S3 में काम करते समय GCP Blob Storage से कीमतों की बहुत तुलना होती थी, लेकिन Google डेटा को उसी building में या उसी building के किसी दूसरे कमरे में रख सकता था, इसलिए AWS-style separation से यह fair comparison नहीं था
    पूरी organization data integrity को लेकर बेहद obsessive थी, हर चीज़ पर checksum लगाती थी, और प्राकृतिक आपदा जैसी बड़ी घटनाओं के लिए भी तैयार रहती थी
    S3 के scale पर gamma rays के hard disk platter से टकराने से होने वाले random bit flips जैसे bit rot भी detect किए जा सकते थे, और disk manufacturer तथा production period के हिसाब से failure rate तक मापे जाते थे, ताकि किसी खास batch के खराब हो जाने पर भी data loss की संभावना कम हो
    इतना कि महत्वपूर्ण data कहीं और store नहीं करूंगा; मैंने S3 placement system खुद बनाया था

    • दूसरे storage vendors में अनुभव कैसा रहा, यह जानना चाहूंगा
      यह व्याख्या कुछ ऐसी लगती है जैसे Cinnabon की तारीफ की जाए कि वह अपना dough खुद बनाता है; जिन चीज़ों का जिक्र है, वे storage company आम तौर पर करती ही हैं
      हर चीज़ पर checksum लगाना कई file systems की basic feature है, और अगर घर के computer पर भी bit rot detect करके alert मिल सकता है, तो बड़े storage vendors तो जाहिर है करते होंगे
      Disk manufacturer के हिसाब से failure rate track करना भी common है, storage companies reports publish भी करती हैं, और 6 लोगों की IT organization में भी हम इसे spreadsheet में manage करते थे
      AWS के बाहर भी, और AWS के अस्तित्व में आने से बहुत पहले से, storage में बहुत smart लोग काम करते रहे हैं
    • AWS का Availability Zone isolation हर vendor से बेहतर है, ऐसा नहीं है
      rsync.net का geo-redundant account उदाहरण के लिए Fremont में primary storage और Denver में secondary storage की तरह अलग-अलग states या countries में मौजूद होता है
      यह भी सही नहीं कि S3 अपने scale के कारण bit rot detect कर सकता है; personal server पर ZFS चलाने पर भी छोटे scale पर bit rot अच्छी तरह detect होता है
      [1] he.net headquarters
    • Data पर checksum लगाना paranoia की वजह से कम, और Reed-Solomon algorithm चलाने के लिए यह जानना जरूरी होने की वजह से अधिक है कि कौन-सा block unusable है
      अगर ऐसी corruption events पर्याप्त संख्या में हों, तो वे individual data blocks को दूसरी machines पर move करके system को “heal” करने के signal के रूप में भी काम कर सकती हैं
      कुल मिलाकर जिन चीज़ों का जिक्र है वे storage systems में काफी typical हैं, सिर्फ S3 की खासियत नहीं
    • Google का एक ही building में data store करना सच नहीं लगता
      Google Cloud Storage documentation के मुताबिक data कई zones में replicate होता है, और हर zone अलग clusters से mapped होता है
      https://cloud.google.com/compute/docs/regions-zones/zone-vir...
    • “भरोसा करो” के बजाय मैं test results पर भरोसा करना चाहूंगा
      जानना चाहूंगा कि S3 की durability, integrity और consistency को Jepsen जितनी कठोरता से validate करने वाला कोई neutral third party है या नहीं
      अगर कोई S3-compatible cloud storages की rigorously तुलना करे, तो डरावनी और बड़ी समस्याएं सामने आ सकती हैं, और शायद ऐसी तुलना पहले से मौजूद भी हो

  • S3 में वाकई उपयोगी चीज़ read/write speed से ज्यादा list operation है
    बिना version वाले buckets या delete markers न रखने वाले buckets में किसी specific prefix की listing लगभग constant time जैसी चलती है, इसलिए 100 billion objects वाले bucket में भी किसी arbitrary string के बाद आने वाली alphabetic order की 1000 keys मांगी जा सकती हैं
    / को delimiter के रूप में इस्तेमाल करना सिर्फ default है; किसी भी character का इस्तेमाल करके common prefix set पाया जा सकता है, और directories वास्तव में मौजूद नहीं होतीं, बस जरूरत पड़ने पर बनी हुई जैसी दिखती हैं
    इस characteristic की वजह से performance की चिंता किए बिना data को जरूरी identifiers के आधार पर कई तरीकों से partition किया जा सकता है
    अगर listing बस धीमी होती, file-prefix-based lookup भी नहीं कर पाती, और keys की संख्या के अनुपात में धीमी होने वाले traditional Unix file system जैसी होती, तो S3 बिल्कुल उपयोगी नहीं होता

    • यह बहुत convincing नहीं लगता
      prefix के पहले और बाद की keys निकालने की क्षमता database indexes की basic चीज़ है जो 1970s से मौजूद है, इसलिए यह खास impress नहीं करती
      use case अलग हो सकते हैं, लेकिन bucket listing धीमी होने से कई बार बाधा आई है, और bucket थोड़ा भी बड़ा हो जाए तो keys enumerate करने में पढ़ने से ज्यादा समय लगने लगता है
      याद पड़ता है कि listing 1Mbps से कम के स्तर पर थी, लेकिन अभी test करने के लिए मेरे पास बड़ा bucket नहीं है
    • Flat lexicographic key hierarchy और directories में nested file system hierarchy का फर्क उदाहरण से साफ हो जाता है
      जब dir1/a/000000 से dir1/a/999999 तक हों और dir1/b हो, तो real hierarchical file system में ls dir1/ को सिर्फ "a" और "b" दो items traverse और return करने होते हैं
      इसके उलट delimiter handling के बिना flat string-index key-value store को "b" तक पहुंचने से पहले "a/00000" से "a/999999" तक 10 लाख directory entries से गुजरना पड़ेगा
      इसलिए simple flat hierarchy में किसी directory की contents list करना real file system के O(direct children) के बजाय O(all recursive children) हो जाता है और बहुत धीमा होता है
      हालांकि अगर listing algorithm को / जैसा delimiter character बताया जाए, तो lexicographic prefix tree अगले / पर subtree को efficiently skip कर सकता है
      Amazon S3 documentation भी साफ कहता है कि CommonPrefixes field में ज्यादा गहरे level पर nested लाखों keys को skip करके summarize किया जाता है
      https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...
      वास्तविक implementation सच में traversal बचाती है या traverse करने के बाद केवल result घटाती है, यह test नहीं किया, लेकिन उम्मीद है कि वह बचाती होगी
    • 1993 में XFS से शुरू होकर HPFS से प्रभावित अच्छे UNIX file systems directories को किसी न किसी तरह के B-tree के रूप में implement करते आए हैं
      इसलिए वे item count के अनुपात में धीमे नहीं होते, और file-prefix-based listing भी बहुत तेज होती है
    • S3 usage का 99% शायद पहले से ज्ञात key से object fetch करना ही होगा
      Prefix listing को core feature मानना अजीब लगता है
    • यहां “constant time” की definition हमारी समान है या नहीं, पता नहीं
      एक network call में 1000 keys मिल जाने से backend complexity के बारे में कुछ भी guarantee नहीं होती

  • हाल ही में S3 asset management script पर काम करते समय list query speed देखकर हैरानी हुई
    एक सहकर्मी ने कहा कि file list cache चाहिए और पहले से भरा हुआ cache भेज दिया; शुरुआत में लगा कि इसकी सच में ज़रूरत नहीं हो सकती, लेकिन खुद जाँचने पर बात अलग निकली
    अलग-अलग assets के लिए लगभग 100,000 root directories हैं, हर एक में 5~6 directories और कुछ files हैं, कुल files शायद 10 लाख से कम हैं और depth अधिकतम करीब 3 levels है
    इन files को recursively list करने में सचमुच 15 मिनट लग गए
    Stack Overflow और ChatGPT के speed improvement सुझावों में से कई चीज़ें आज़माईं, लेकिन कोई meaningful result नहीं मिला, और समझ नहीं आया कि यह इतना धीमा क्यों है
    पता नहीं Amazon ने इसे ठीक क्यों नहीं किया; बाहर से देखने पर लगता है कि individual buckets में कुछ B-trees जोड़ देने से काम हो जाना चाहिए
    अगर यह कठिन समस्या है, तो उसका कारण रोचक होगा, इसलिए सुनना चाहूँगा

    • S3 मूल रूप से key-value store है
      objects को “directories” की तरह देख पाना सिर्फ prefix filter है; यह file system नहीं है और इसमें directory की अवधारणा भी नहीं है
    • “recursively” शब्द और “directories”, “levels” को लंबा समझाने वाला हिस्सा चिंता पैदा करता है
      S3 में objects को सबसे तेज़ तरीके से list करने के लिए recursion की बिल्कुल ज़रूरत नहीं होती; बस किसी prefix के नीचे के सभी objects list कर दें
      path separator का इस्तेमाल करके S3 keys को folder structure जैसा दिखाने और “folder-by-folder” घूमने पर यह बहुत धीमा हो जाता है
      ListObjectsV2 call करते समय delimiter pass नहीं करना चाहिए; अगर delimiter feature का इस्तेमाल नहीं करते, तो “directories” और “levels” performance को प्रभावित नहीं करते
      कुल desired time तक पहुँचने के लिए एक list operation को कई prefixes पर parallel list queries में बाँटा जा सकता है
    • इस समस्या का एक दिलचस्प परिणाम यह है कि S3 bucket delete करना सरल नहीं है
      जिस bucket में objects हों उसे delete नहीं किया जा सकता, और S3 से एक बार में सभी objects हटाने को भी नहीं कहा जा सकता
      हर object के लिए अलग delete API request भेजनी पड़ती है, और ऐसा करने के लिए objects को 1000-1000 करके list करने वाली requests भी भेजनी पड़ती हैं; इन list calls में समय भी लगता है और cost भी आती है
      स्थिति को यह लेख अच्छी तरह समझाता है: https://cloudcasts.io/article/deleting-an-s3-bucket-costs-mo...
      S3 bucket को जल्दी साफ करने का सबसे तेज़ तरीका आखिरकार उस AWS account को delete करना है जिसमें वह bucket है
    • वजह कहीं ज़्यादा सामान्य भी हो सकती है
      एक request में 10,000 objects list किए जा सकते हैं, और अगले 10,000 पाने के लिए पिछली request का result चाहिए, इसलिए सब कुछ serial है
      10 लाख files list करने के लिए लगातार 100 requests चाहिए; round-trip time सिर्फ 50ms हो तो भी सिर्फ round trips में 5 seconds लगेंगे, और flat iteration में list खुद बनाने की cost अलग है
      10,000 items की list query की cost write cost जैसी होती है, और यह अपने-आप में काफी धीमी है; हर list query संभवतः strong consistency snapshot भी हो सकती है, जिससे cost और बढ़ती है
      B-tree शायद तब तक खास मदद नहीं करेगा जब तक directory traversal न किया जा रहा हो; और उस स्थिति में भी bottleneck network operations और externally exposed API होने की संभावना ज़्यादा है
      अंततः file list query इतना महत्वपूर्ण use case नहीं है; आमतौर पर object lifecycle जैसी features के जरिए S3 को desired काम सौंप दिया जाता है, ताकि वह internal file system layer में इसे efficiently handle करे
    • S3 bucket के अंदर directories हैं, ऐसा सोचना अच्छा model नहीं है
      सब कुछ objects है, और web interface slash से बँटे prefixes को बस देखने में अच्छा बनाकर दिखाता है
      हर object की एक key होती है और उस key में slash हो सकता है; सुविधा के लिए हर segment को directory मान सकते हैं
      लेकिन जैसे ही आप आमतौर पर directory पर किए जाने वाले operations आज़माते हैं, वह भ्रम टूट जाता है

  • S3 बनाने वालों को पता था कि यह file system नहीं है, और object storage नाम, मेरे हिसाब से, लेख में बताई गई भिन्नताओं को समझाने वाला expression था
    “objects लोकप्रिय थे” का मतलब execution code और local state को बाँधने वाले software components के रूप में objects से है, लेकिन S3 के शुरुआती examples “live object को serialize करके दूसरे process में deserialize” करने जैसे नहीं थे
    examples सभी website static assets जैसी चीज़ें थीं, और उस समय database क्षेत्र में भी “binary large object” या “blob” में object वाला अर्थ इस्तेमाल होता था
    S3 database में रखना awkward लगने वाली चीज़ों को store करने की जगह के अधिक करीब था, और शुरुआती design के समय launch use cases यह मानकर चलते थे कि content index कहीं और है, इसलिए list query का धीमा होना भी इसी प्रकृति को समझाता है

    • लेखक शायद यह नहीं जानता कि “object storage” object-oriented programming से असंबंधित storage system term है
      https://en.wikipedia.org/wiki/Object_storage
    • चिंता है कि लेखक object-oriented programming और object storage को मिला रहा है
      GCP की व्याख्या के अनुसार, object storage एक architecture है जो unstructured data को object units में बाँटकर structurally flat data environment में store करता है
      https://cloud.google.com/learn/what-is-object-storage
      यानी unstructured, flat organization, और whole-item unit operations—read और write—इसके core हैं

  • S3 न तो file है और न ही file system
    file abstraction से हम बदलाव की क्षमता की उम्मीद करते हैं: file के किसी हिस्से को edit करना, उसे बढ़ाना-घटाना, और किसी भी arbitrary offset से read/write करना संभव होना चाहिए
    एक बार file पकड़ लेने के बाद दोबारा root या parent concept तक ऊपर जाने की जरूरत नहीं होनी चाहिए, लेकिन S3 केवल एक mutable list के ऊपर immutable objects देता है, और बदलाव करना हो तो copy करके फिर से upload करना पड़ता है
    असली file abstraction disk के sectors को ढूंढकर client को उन्हें continuous buffer जैसा दिखाना है, जबकि S3 कोई अलग समस्या हल करता है
    कई लोग UNIX के “everything is a file” वाले अच्छे idea को गलत समझकर यह मान लेते हैं कि हर चीज continuous virtual buffer जैसी दिखनी चाहिए
    असल मुद्दा यह है कि चाहे file हो या कोई और object जिसे system process को दिखाना चाहता है, एक basic leaf node होता है; directories समेत हर चीज directory में list की जा सकती है; और एक recursive tree होता है
    file system बनाने वाली चीज किसी खास leaf node का type नहीं, बल्कि directory है
    socket या framebuffer जैसे नए leaf type जोड़ना लगभग मामूली है और इस idea को नुकसान नहीं पहुंचाता, लेकिन list जैसे किसी अलग तरह के container को जोड़ने से file system structure जटिल हो जाता है और conceptual consistency टूट जाती है
    S3 ये चीजें नहीं करता, लेकिन यह ठीक है
    बस database में फिट न होने वाली चीजें उसमें रख दीजिए और उम्मीद कीजिए कि जब आप उन्हें देख नहीं रहे हों, तब bit rot न हो
    मुझे लगता है कि S3 को file system जैसा बनाने की चाहत इस वजह से आती है कि customers S3 की असली ताकत को गलत समझते हैं, और product management उस गलतफहमी को रोकने के बजाय स्वीकार कर लेता है

    • मैं सहमत हूं कि S3 file system नहीं है
      ज्यादा सही analogy block storage device है, बस वह बहुत अजीब block device जैसा है जिसमें block size arbitrary है और keys लगाई जा सकती हैं
      file system, block storage device के ऊपर बैठने वाली abstraction है, इसलिए “S3 file system” भी S3 को underlying block storage की तरह रखकर उसके ऊपर बनी abstraction होना चाहिए
    • सोच रहा हूं कि read-only file system इस definition में कैसे fit होता है

  • file system एक abstraction है जो block device के ऊपर बनाई जाती है
    block device एक विशाल byte array देता है, और उदाहरण के लिए “position 273041 पर ये 300 bytes लिखो” जैसे block-level read/write करने देता है
    block device खुद भी real hardware के ऊपर बनी abstraction है, इसलिए “ये 300 bytes लिखो” असल में “platter 2 की needle को position 6 पर ले जाओ” जैसी operations में बदलता है
    S3 raw storage के ऊपर बनी बस एक अलग abstraction है, और सख्ती से देखें तो एक flat key-object store है
    अगर file system features चाहिए तो उन्हें app में implement करें या file system इस्तेमाल करें
    अगर सिर्फ append चाहिए, तो database से append chain track करें और chunks S3 में store करें; अगर यह fit न हो, तो कुछ और इस्तेमाल करें
    अगर copy चाहिए, तो database में उसी object का नया reference बना दें; अगर यह fit न हो, तो कुछ और इस्तेमाल करें
    S3 बहुत लोगों के लिए अच्छा fit है, इसलिए उसे कुछ और बनाने की कोशिश नहीं करनी चाहिए
    पहले से established field terminology के meaning बदलने की कोशिश भी बंद करनी चाहिए; file system textbooks में समझाया गया concept है, और S3 ने कभी यह दावा नहीं किया कि वह file system है
    operating system design थोड़ा पढ़ना वाकई मददगार है और मजेदार भी

  • Apache Arrow के object_store और Apache OpenDAL API की तुलना पर चर्चा https://github.com/apache/arrow-rs/issues/3888 पर हुई थी
    Apache OpenDAL एक library है जो S3 और कई cloud storage सहित कई backends के ऊपर file system जैसी API देती है
    GreptimeDB और Databend जैसे कुछ database systems cloud storage में data access करने के लिए OpenDAL को एक बेहतर S3 SDK की तरह इस्तेमाल करते हैं
    S3 के ऊपर file system जैसा interface manage करने के लिए Alluxio और JuiceFS भी दूसरे solutions हैं, लेकिन Apache OpenDAL के उलट इन्हें अलग deployment और dedicated internal metadata service चाहिए

    • TrinoDB के लिए local cache layer के रूप में Alluxio को OpenDAL से replace किया जा सकता है या नहीं, यह मुझे ठीक से नहीं पता

  • S3 की बात करते समय Backblaze B2 का भी जिक्र करना ठीक रहेगा
    इसकी कीमत S3 से 3 गुना कम है, इसलिए मुझे यह बहुत पसंद है, और मैं Backblaze से जुड़ा नहीं हूं

    • Backblaze B2 सस्ता है, लेकिन production environment में इस्तेमाल करें तो कुछ चीजें लागत में शामिल करनी चाहिए
      हर हफ्ते PST 11:30~13:30 का 2 घंटे का maintenance window होता है, और आम तौर पर downtime नहीं होता, लेकिन कभी-कभी अमेरिका के business hours के बीच में पूरा outage भी हो जाता है
      error rate unusable level तक बढ़ जाए तो support ticket डालना पड़ता था, और पिछले कुछ वर्षों में लगभग साल में एक बार ऐसा हुआ
      support बस ढेरों सवाल पूछता है, जैसे उनकी तरफ error logs या visibility ही न हो, और issue को ठीक से investigate नहीं करता
      false success भी होता है, जहां upload success का response आता है लेकिन असल में B2 system में 0 bytes के रूप में store होता है, इसलिए success code आने पर भी upload verify करना जरूरी है
      Log4j2 CVE जैसी high-severity vulnerability आने पर 10 घंटे के outage जैसे लंबे incidents भी हो सकते हैं
      कीमत सबसे अच्छी है, लेकिन यह ऐसा product नहीं है जिसकी तुलना सीधे ज्यादा mature cloud storage services से की जा सके
    • alternative services में हमेशा मुख्य बात यह होती है कि data उतना ही safe है जितना आप उस company पर भरोसा कर सकते हैं
      हालांकि मुझे लगता है कि दो layers के external backup से इसे कुछ हद तक compensate किया जा सकता है
    • B2 अच्छा था, लेकिन इतना नहीं कि IPv4 address cost तक चुकाकर इस्तेमाल किया जाए
      खुद को multicloud solution के तौर पर advertise करने के बावजूद, जब NAT gateway और IPv4 charges हर जगह जुड़ते हों, तो adoption की संभावना को लगभग खत्म कर देना अजीब है
      हमारा usage read-heavy और write-light था, इसलिए B2 bandwidth charges देने के बाद भी पैसे बच सकते थे, लेकिन अगर NAT64 gateway से गुजरना पड़े या B2 तक पहुंचने के लिए hourly charges देने पड़ें, तो ऐसा नहीं होता

  • अच्छा लेख है, और rclone mount के साथ cloud storage को FUSE के रूप में mount करने की यात्रा शुरू करने से पहले इसे पढ़ना उपयोगी होता
    कई बार दोहराने के बाद rclone में एक VFS layer बनी, जो S3, Google Cloud Storage, Azure Blob, OpenStack Swift, Oracle Object Storage जैसी storage को POSIX-जैसी file system layer में ढालती है, और असली rclone mount code उसके ऊपर एक पतली layer है
    VFS layer में compatibility के कई स्तर हैं; off में यह सिर्फ directory caching करती है
    इस mode में, जैसा लेख में कहा गया है, उसी file को एक साथ पढ़ और लिख नहीं सकते, file के बीच में write नहीं कर सकते, और file में केवल क्रम से ही write किया जा सकता है
    हैरानी की बात है कि इन सीमाओं के बावजूद काफी चीजें अच्छी तरह काम करती हैं
    अगला स्तर writes है, जो उसी file को एक साथ पढ़ना-लिखना, file के बीच में write करना आदि apps द्वारा चाही जाने वाली अधिकतर POSIX क्षमताओं को support करता है, लेकिन इसकी कीमत यह है कि file की local copy बनती है और close होने पर async तरीके से upload होती है
    VFS caching mode का documentation लेख में बताई गई सीमाओं को अच्छी तरह दर्शाता है: https://rclone.org/commands/rclone_mount/#vfs-file-caching
    मूल रूप से S3 में असली directories भी नहीं होतीं, इसलिए ऐसी directory नहीं हो सकती जिसमें files न हों, और directory के पास modification time जैसा valid metadata भी नहीं होता
    / पर खत्म होने वाली 0-byte file के रूप में directory marker बनाया जा सकता है और rclone समेत कई tools इसे support करते हैं
    खाली directories न होना आम तौर पर बड़ी समस्या नहीं है, क्योंकि VFS layer उन्हें fake कर देती है और ज्यादातर apps जल्द ही उनके अंदर कुछ लिख देती हैं
    आखिरकार S3 जैसी दिखने वाली चीज को POSIX file system जैसा दिखाने में काफी काम लगता है, और open file का नाम बदलने जैसे behavior और पेचीदा edge cases के पीछे बहुत सारा illusion होता है
    rclone के low-level move/sync/copy commands ऐसा handling नहीं करते और लगभग सीधे S3 API का उपयोग करते हैं
    अगर S3 API में एक चीज बदली जा सके, तो मैं चाहूंगा कि list query के समय metadata भी पढ़ने का option हो
    rclone file modification time को object metadata में store करता है, लेकिन इसे bulk में पढ़ने का कोई तरीका नहीं है, इसलिए हर object के लिए HEAD करना पड़ता है
    या upload करते समय object का Last-Modified set किया जा सके तो भी अच्छा होगा

    • लगता है metadata को key name में ही store करके workaround किया जा सकता है
      key length limit 1024 है, इसलिए store किए जा सकने वाले metadata की मात्रा सीमित है, लेकिन file path को ध्यान में रखने पर भी यह काफी जगह है
      normalized path में invalid // जैसे separator का उपयोग करके /path/to/file.txt//mtime=1710066090 जैसा रखा जा सकता है
      फिर भी prefix से “directory” ला सकते हैं, और // को prefix की तरह इस्तेमाल करके सीधे file ला सकते हैं
      हालांकि ऐसा format दूसरे software के साथ compatibility को काफी नुकसान पहुंचाएगा
    • मैं सहमत हूं कि list query में metadata शामिल करने का option अच्छा होगा
      MinIO में उन्होंने सही permissions होने पर list query में metadata और tags शामिल करने वाला metadata=true नाम का “secret” parameter जोड़ा है
      extension होने के कारण इसे भरोसेमंद तरीके से इस्तेमाल नहीं किया जा सकता, लेकिन rclone हमेशा try करके, संभव हो तो use कर सकता है
      / पर खत्म होने वाली 0-byte file भी संभव है, लेकिन list query के shared prefix को ही directory माना जा सकता है
      तब directories stateless होती हैं और उनके अंदर कोई object न हो तो वे मौजूद नहीं रह सकतीं—इसके अपने फायदे-नुकसान हैं
      upload करते समय Last-Modified set करने की सुविधा client constraints को कम करेगी, लेकिन server time को आधार मानने का भी फायदा है
      client-side replication या mirroring में भी वही constraints handle करने पड़ते हैं
      निजी तौर पर मेरी सबसे बड़ी शिकायत यह है कि single object की version information लौटाने वाला HeadObjectVersions नहीं है
      ListObjectVersions यह नहीं जान सकता कि दिया गया prefix असली prefix है या object key, इसलिए यह हमेशा cluster-wide operation ही बनता है
      AWS ने हाल में GetObjectAttributes जोड़ा है, लेकिन उसमें version information नहीं है, जो उसमें अच्छी तरह फिट होती

  • S3 में “Simple” का मतलब “गहरा नहीं” नहीं है, बल्कि यह है कि requirements हासिल करने के लिए सबसे कम parts चाहिए
    अगर distributed, centralized, replicated, high-availability, high-durability, high-bandwidth, low-latency, strongly consistent, synchronous, scalable object storage और HTTP REST API तक चाहिए, तो मुझे लगता है S3 से सरल बनाना मुश्किल है
    AWS S3 में लंबे समय में कई features जोड़े गए हैं, लेकिन basic behavior वैसा ही बना हुआ है

    • लेख में इस्तेमाल terminology के हिसाब से “minimum necessary parts” ही deep होने का अर्थ है
      Ousterhout की 『A Philosophy of Software Design』 के अनुसार simple होने का मतलब non-complex होना है, और Rich Hickey की “Simple Made Easy” भी इसी संदर्भ में है
      इसके उलट “deep” का मतलब है छोटे interface के जरिए अंदरूनी तौर पर बहुत सारी complex functionality देना, इसलिए S3 के लिए “simple” से ज्यादा यह अभिव्यक्ति फिट बैठती है
      यह उस अर्थ वाली simplicity से अलग है कि S3 में कुछ खास नहीं है
      https://www.infoq.com/presentations/Simple-Made-Easy/
    • लेख की phrasing के अनुसार, simplicity को लगभग depth और narrow interface निहित मान सकते हैं