S3 Files और S3 का बदलता रूप

 (allthingsdistributed.com)
11 पॉइंट द्वारा GN⁺ 2026-04-08 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े पैमाने पर डेटा मूवमेंट की अक्षमियों को कम करने के लिए, S3 डेटा को file system की तरह सीधे access करने योग्य बनाने वाला S3 Files पेश किया गया है
  • यह फीचर Amazon EFS और S3 को एकीकृत करता है, जिससे EC2, containers, Lambda आदि में S3 bucket को NFS के रूप में mount करके read·write किया जा सकता है
  • अंदरूनी तौर पर यह stage और commit संरचना का उपयोग करता है ताकि बदलावों को समय-समय पर S3 में लागू किया जा सके, और files तथा objects के बीच दो-तरफ़ा synchronization को support किया जा सके
  • S3 Tables, S3 Vectors के साथ S3 Files, S3 को एकीकृत data platform तक विस्तारित करने वाले मुख्य घटक के रूप में काम करता है
  • S3 अब केवल एक साधारण storage से आगे बढ़कर data-केंद्रित एकीकृत workspace में विकसित हो रहा है, जो developers को डेटा का सीधे उपयोग करने का आधार देता है

S3 में बदलाव और S3 Files की डिज़ाइन

  • डेटा मूवमेंट की मुश्किलें और S3 Files की शुरुआत

    • बड़े पैमाने पर डेटा को इधर-उधर ले जाने की प्रक्रिया, scientific research से लेकर machine learning तक, कई industries में लगातार inefficiency का कारण रही है
    • UBC के genomics research उदाहरण में, researchers ने S3 और local file system के बीच copy operations पर बहुत समय खर्च किया
    • यह data friction इसलिए पैदा होता है क्योंकि tools डेटा को अलग-अलग तरीकों से access करते हैं
    • S3 Files को इस friction को कम करने के लिए S3 डेटा को सीधे file system की तरह access करने योग्य बनाया गया है

  • एजेंट-आधारित development और डेटा का महत्व

    • Agentic tooling के विकास से application development की गति और विविधता तेज़ी से बढ़ी है
    • Code लिखने की बाधा कम होने से domain experts सीधे applications बना सकें, ऐसा माहौल बन रहा है
    • Applications का lifecycle छोटा हो रहा है, और डेटा लंबे समय तक टिकने वाली मुख्य asset के रूप में उभर रहा है
    • Storage सिर्फ़ एक repository नहीं, बल्कि ऐसी abstraction layer होना चाहिए जो डेटा को applications से अलग रखकर लगातार उपयोग योग्य बनाए

S3 के नए data primitives

  • S3 Tables

    • S3 ने structured data को संभालने के लिए Apache Iceberg-आधारित S3 Tables पेश किए
    • Iceberg की क्षमताओं को बनाए रखते हुए यह data integrity protection, automatic compaction, cross-region replication जैसी सुविधाएँ देता है
    • इस समय 20 लाख से अधिक tables S3 Tables में stored हैं, और कई applications इन्हीं पर बनाए गए हैं

  • S3 Vectors

    • AI के विकास के साथ vector index की माँग बढ़ी है
    • मौजूदा vector databases index को memory या SSD में store करते हैं, लेकिन इसमें cost और scalability की सीमाएँ हैं
    • S3 Vectors ऐसा fully elastic vector index देता है जिसका cost·performance·durability profile S3 objects जैसा है
    • यह सैकड़ों से लेकर अरबों records तक scale कर सकता है, और similarity search के लिए API endpoints देता है

S3 Files का आगमन

  • अवलोकन

    • S3 Files Amazon EFS को S3 में एकीकृत करता है, जिससे S3 डेटा को network file system (NFS) की तरह सीधे access किया जा सकता है
    • EC2, containers, Lambda आदि में S3 bucket या prefix को mount करके file की तरह read और write किया जा सकता है
    • बदलाव अपने-आप S3 में लागू हो जाते हैं, जिससे files और objects के बीच दो-तरफ़ा synchronization संभव होता है

  • डिज़ाइन की चुनौतियाँ

    • File system और object storage की data models मूल रूप से अलग हैं
    • शुरुआत में EFS और S3 को सीधे जोड़ने की कोशिश की गई, लेकिन “unpalatable compromises” ही बचे
    • Files सूक्ष्म बदलावों और concurrent access को support करती हैं, जबकि objects immutability और whole-unit updates पर आधारित होते हैं
    • S3 का event notification system रोज़ 300 अरब से अधिक notifications process करता है, और object-level changes पर काम करता है

Stage and Commit डिज़ाइन सिद्धांत

  • सीमा को feature में बदलना

    • Files और objects के अंतर को छिपाने के बजाय, उसे स्पष्ट boundary के रूप में डिज़ाइन किया गया
    • बदलाव EFS में stage (अस्थायी रूप से संग्रहीत) होते हैं, और तय अंतराल पर commit होकर S3 में लागू किए जाते हैं
    • यह तरीका Git की version control अवधारणा से प्रेरित है, जिससे समय और policy-आधारित data transfer control संभव होता है

  • Consistency और atomicity

    • File system की atomic (rename, move) operations और S3 की whole-object updates दोनों को साथ support किया जाता है
    • दोनों layers को अलग रखकर, हर system का consistency model बनाए रखते हुए single data view दिया जाता है

  • Permission management

    • S3 की IAM policy और file system की inode-आधारित permissions संरचनात्मक रूप से अलग हैं
    • S3 Files mount-level permissions देकर इन दोनों systems को अलग रखता है
    • S3 IAM policy अंतिम backstop के रूप में बनी रहती है, ताकि data boundary बदलने पर access control संभव हो

  • Namespace mismatch

    • S3 में directory की अवधारणा नहीं होती, और path delimiter भी मनचाहे तरीके से तय किया जा सकता है
    • File system के साथ इस mismatch को सुलझाने के लिए दोनों पक्षों के naming rules को जस का तस रखा गया
    • असंगत objects को move नहीं किया जाता, बल्कि event trigger किया जाता है ताकि developer उसे संभाल सके

  • Performance और latency

    • File system metadata-केंद्रित access के लिए optimized है, जबकि S3 large-scale parallel access के लिए optimized है
    • ज़्यादातर workloads files और objects को एक साथ access नहीं करते, इसलिए दोनों models को पूरी तरह मिलाने के बजाय synchronization layer बनाए रखना अधिक व्यावहारिक है
    • File view NFS consistency बनाए रखता है, object view S3 strong consistency बनाए रखता है, और synchronization layer दोनों के बीच कड़ी का काम करता है

S3 Files कैसे काम करता है

  • मूल संरचना

    • S3 Files EFS को backend के रूप में इस्तेमाल करके file system जैसा अनुभव देता है
    • Directory access के समय S3 metadata लाकर synchronized view बनाया जाता है, और 128KB से छोटी files के लिए डेटा भी तुरंत load किया जाता है
    • बड़ी files के लिए lazy hydration के ज़रिए ज़रूरत पड़ने पर ही डेटा लाया जाता है
    • बदलाव लगभग हर 60 सेकंड में एक single PUT के रूप में S3 में commit होते हैं, और दो-तरफ़ा synchronization चलता है

  • Conflict और management

    • दोनों तरफ़ एक साथ modification होने पर S3 को source of truth माना जाता है
    • Conflicted files को lost+found directory में भेजा जाता है, और CloudWatch metrics में रिकॉर्ड किया जाता है
    • 30 दिनों तक access न की गई files को file system view से हटा दिया जाता है ताकि cost optimize की जा सके

  • Performance optimization

    • read bypass फीचर के ज़रिए बड़े sequential reads के दौरान parallel GET requests से सीधे S3 से पढ़ा जाता है

      • इससे प्रति client 3GB/s throughput हासिल होता है, और multiple clients पर terabit-स्तर की scalability मिलती है

  • सीमाएँ और आगे के सुधार

    • S3 में native rename operation नहीं है, इसलिए directory rename के लिए पूरा copy·delete करना पड़ता है
    • 5 करोड़ से अधिक objects वाले mount पर warning दिखाई जाती है
    • Explicit commit control शुरुआती version में शामिल नहीं है
    • कुछ object keys को POSIX filename के रूप में व्यक्त नहीं किया जा सकता, इसलिए उन्हें file view से बाहर रखा जाता है

डेटा की विविधता और S3 का विकास

  • डेटा access तरीकों का सह-अस्तित्व

    • UBC research उदाहरण की तरह, developers data movement, caching, naming management पर बहुत समय लगाते हैं
    • S3 team, Tables, Vectors और Files के ज़रिए विभिन्न data access patterns को एकीकृत support देती है
    • Files और objects के अंतर को मिटाने के बजाय, उनकी विशेषताओं को स्वीकार कर boundary को feature बनाया गया है

  • S3 की विस्तारित भूमिका

    • S3 एक साधारण object storage से विकसित होकर विभिन्न data forms को support करने वाला integrated storage platform बन रहा है
    • Tables, Vectors और Files के ज़रिए काम करने के तरीके के अनुसार डेटा का सीधे उपयोग संभव हो जाता है
    • लक्ष्य यह है कि storage काम में बाधा नहीं, बल्कि पारदर्शी आधारभूत infrastructure बने
    • आगे stage/commit control, pipeline integration जैसी क्षमताओं का विस्तार जारी रहेगा

  • निष्कर्ष

    • S3 Files, files और objects के बीच स्पष्ट boundary बनाए रखते हुए दोनों के फ़ायदे जोड़ता है
    • 20 साल पहले object storage के रूप में शुरू हुआ S3 अब data-केंद्रित integrated workspace में विकसित हो चुका है
    • “अब, बनाना शुरू करो (Go build!)” के संदेश की तरह, S3 developers को डेटा के साथ अधिक तेज़ी से experiment और build करने का आधार देता है

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

4 टिप्पणियां

 
xguru 2026-04-08

आह, अब "साथ में पढ़ने लायक लेख" संबंधित आधिकारिक लेखों को अच्छी तरह जोड़ देता है, इसलिए सुविधाजनक हो गया है.
ऐसे मामलों में, जहाँ परिचयात्मक लेख और आधिकारिक लेख अलग-अलग हों, इसे कैसे संभालना चाहिए इस बारे में मैं हमेशा सोचता था,
लेकिन अच्छा लगता है कि "साथ में पढ़ने लायक लेख" बढ़िया काम कर रहा है.. haha

अब S3 फ़ाइल, टेबल और वेक्टर—तीनों को शामिल करने वाले data platform के रूप में फैल रहा है.

ऐसा लगता है कि आधुनिक cloud infrastructure की शुरुआत रहे S3 को 20 साल बाद फिर से परिभाषित किया जा रहा है
 
rtyu1120 2026-04-13

S3 के साथ फ़ाइल संरचना transparently साझा नहीं होती, लेकिन ZeroFS नाम का एक open source प्रोजेक्ट भी है जो S3 को डेटाबेस की तरह इस्तेमाल करके POSIX-compliant फ़ाइलसिस्टम चलाता है. S3 पर PostgreSQL चलाने वाले डेमो के कारण यह काफ़ी लोकप्रिय था.

https://www.zerofs.net/
 
rtyu1120 2026-04-13

पहले S3 इंजीनियर द्वारा शुरू किए गए Archil में उनकी अपनी प्रोडक्ट से तुलना करने वाली एक पोस्ट भी है, उसे साथ में देखें तो मज़ा आता है, haha

https://x.com/jhleath/status/2042613823522377933
 
GN⁺ 2026-04-08
Hacker News की राय

  • यह असल में S3FS का उपयोग करने वाली संरचना है, लेकिन EFS (AWS की managed NFS service) को active data और छोटे random access के लिए cache layer की तरह इस्तेमाल करती है
    समस्या यह है कि EFS की महंगी pricing structure भी साथ ही आ जाती है
    — हर write operation पर $0.06 प्रति GB लगता है, जो write-heavy workload के लिए घातक हो सकता है
    — cache से read करने पर $0.03 प्रति GB शुल्क लगता है, और 128KB से बड़े read सीधे S3 bucket से stream होते हैं, इसलिए वे मुफ़्त हैं
    — cache की कीमत $0.30 प्रति GB प्रति माह है, लेकिन यह मुख्य रूप से 128KB या उससे छोटे files को ही persist करता है, इसलिए लागत शायद बहुत ज़्यादा नहीं होगी

    • मैं जानना चाहता हूँ कि क्या बड़े file read (>128KB) वास्तव में हमेशा cache को bypass करते हैं
      S3 latency काफ़ी खराब मानी जाती है, इसलिए चिंता हो रही है

  • “NFS provides the semantics your applications expect” वाली पंक्ति अब तक की सबसे मज़ेदार चीज़ों में से एक लगी

    • applications यह उम्मीद नहीं करतीं कि सिर्फ़ network disconnect होने से system call अनंत प्रतीक्षा में फँस जाए और filesystem unmount भी न हो पाए

  • Hugging Face Buckets ने भी हाल ही में bucket को filesystem की तरह mount करने की सुविधा जोड़ी है
    hf-mount changelog

  • sync वाले हिस्से को लेकर जिज्ञासा थी
    AWS docs के अनुसार,
    अगर /mnt/s3files/report.csv को modify करने के बाद S3 bucket में उसका कोई दूसरा version upload हो जाए, तो conflict होने पर मेरा version .s3files-lost+found-file-system-id directory में move कर दिया जाएगा और bucket वाला version उसकी जगह ले लेगा
    यानी, conflict की स्थिति में automatic recovery directory मौजूद है

  • FiberFS लगभग अपने पहले official release के चरण में है
    इसमें built-in cache, CDN compatibility, JSON metadata, और concurrency safety है, और यह सभी S3-compatible storage को target करता है

    • Amazon के अपने FUSE implementation की तुलना में यह कैसा है, यह जानने की इच्छा है। अब तक इसका तीसरा version आ चुका है

  • अच्छा होता अगर AWS local NVMe storage के साथ managed bridging देता
    NVMe, EBS से काफ़ी तेज़ है, और EBS, EFS से तेज़ है
    NVMe के ऊपर cache layer रखी जाए तो speed काफ़ी अच्छी मिल सकती है, लेकिन fully integrated option और भी बेहतर होगा

    • अगर EFS सिर्फ़ एक simple NFS mount है, तो NVMe volume attach करके और cachefilesd configure करके इसे खुद भी बनाया जा सकता है
      उदाहरण के लिए 
      mkfs.ext4 /dev/nvme0n1 && \
mount /dev/nvme0n1 /var/cache/fscache && \
mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
      इस तरह शायद यह तुरंत काम भी कर जाए
      असल में यह सिर्फ़ तीन lines का command है, और इसे managed service के रूप में पेश करना AWS-स्टाइल कदम लगता है

  • मुझे लगा था AWS पहले कहता था कि S3 को filesystem की तरह इस्तेमाल मत करो, तो अब यह बदलाव क्यों आया, यह सोचने वाली बात है

    • इस बार लगता है कि S3 के सामने असली filesystem (EFS) रखकर transparent sync किया जा रहा है
      blog में भी consistency issues और object naming handling जैसी सावधानियों का ज़िक्र है
      S3 का प्रशंसक होने के नाते, मुझे यह design काफ़ी अच्छा समझौता लगता है
    • बड़े enterprise customers के architects बहुत पहले से S3 को filesystem की तरह इस्तेमाल करते रहे हैं
      AWS पर पड़े support ticket pressure और “यह क्यों नहीं चलता?” जैसे सवाल शायद जमा होते गए, और आख़िरकार चीज़ें इस दिशा में चली गईं
      व्यक्तिगत रूप से मुझे यह “मूल रूप से अलग चीज़ को बस नए wrapper में पेश करने” जैसा लगता है, लेकिन यह $$$ के सामाजिक दबाव का असर भी हो सकता है
    • यह कम technical skill वाले user segment को भी अंदर लाने की रणनीति लगती है
      “S3asYourFS.exe” जैसे tools इस्तेमाल करने वालों को भी AWS customer बनाया जा सकता है
      लेकिन AWS की customer support capability को देखते हुए, यह समझदारी भरा फ़ैसला है या नहीं, इस पर संदेह है
      फिर भी हर महीने bill चुकाने वाले users की बढ़ती संख्या का आकर्षण बड़ा रहा होगा
    • वैसे भी लोग S3 को filesystem की तरह इस्तेमाल करने वाले हैं, तो बेहतर है कि इसे officially support ही किया जाए
    • आख़िरकार AWS ने सामने cache रखकर एक revenue model बना लिया है
      user के लिए performance बेहतर होती है, और AWS का load कम होता है
      पैसे बच भी सकते हैं, और नहीं भी

  • सोच रहा हूँ कि इसमें SQLite database store करने पर क्या होगा
    शायद सिर्फ़ read-only replica जैसा कुछ संभव होगा, और Litestream जैसा backup शायद नहीं चलेगा

    • SQLite का lock mechanism NFS पर safe नहीं है, इसलिए यह काम नहीं करेगा

  • NFS का locking behavior वैसे ही जटिल है, और उसमें remote S3 backend जोड़ देने पर चीज़ें और उलझी हुई लगती हैं

  • Werner Vogels वाकई कमाल के इंसान हैं
    मैंने पहली बार उनके लेख DynamoDB पढ़ते समय देखे थे, और तभी से मैं उनका प्रशंसक हूँ