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

• बड़े पैमाने पर डेटा मूवमेंट की अक्षमियों को कम करने के लिए, 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 करने का आधार देता है