AWS S3 धीमी HDD पर प्रति सेकंड 1 पेटाबाइट कैसे प्रोसेस करता है

 (bigdata.2minutestreaming.com)
19 पॉइंट द्वारा GN⁺ 2025-09-27 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS S3 एक बड़े पैमाने की multi-tenant object storage सेवा है, जो उच्च availability और durability को कम लागत पर उपलब्ध कराती है
  • यह पुराने और धीमे (≈120 IOPS) HDD का उपयोग करता है, लेकिन अत्यंत कम लागत और विशाल क्षमता वाले स्टोरेज माध्यम की अर्थव्यवस्था का अधिकतम लाभ उठाता है
  • S3 अपनी आंतरिक storage layer (ShardStore) को log-structured (LSM) रूप में डिज़ाइन करता है, ताकि write path sequential I/O के अनुरूप रहे, जबकि read path में Erasure Coding (5-of-9) और massive parallelization के जरिए performance समस्या की भरपाई की जाती है
  • client, frontend और storage के पूरे रास्ते में multipart upload, byte-range GET, connection pool, hedged requests जैसी तकनीकों से tail latency घटाई जाती है और throughput को aggregate किया जाता है
  • random distributed placement, Power of Two Random Choices, continuous rebalancing, और de-correlation जिसके कारण scale बढ़ने पर load अधिक समतल हो जाता है, के जरिए hotspot से बचते हुए अंततः >1 PB/s स्तर का throughput हासिल किया जाता है

AWS S3 की बड़े पैमाने की storage architecture

  • लगभग सभी जानते हैं कि AWS S3 क्या है, लेकिन बहुत कम लोग जानते हैं कि S3 कितने विशाल scale पर चलता है और इसे संभव बनाने के लिए कौन-सी innovations की गईं
  • S3 एक scalable multi-tenant object storage service है, जो API के जरिए object को store और retrieve करने देता है, और बहुत उच्च availability तथा durability को अपेक्षाकृत कम लागत पर उपलब्ध कराता है

  • S3 का scale

    • 400 ट्रिलियन से अधिक objects stored
    • प्रति सेकंड 150 मिलियन requests प्रोसेस
    • peak पर प्रति सेकंड 1 PB से अधिक traffic support
    • करोड़ों hard disks का संचालन
  • उच्च availability और durability (“11 nines” design goal), तथा अपेक्षाकृत कम लागत को user experience की बुनियादी शर्त के रूप में पेश किया गया
    • यह data analytics और machine learning data lake के default storage layer तक विस्तार कर चुका है
  • design goal यह है कि cost efficiency बनाए रखते हुए random access pattern और massive concurrency को संभाला जाए
    • S3 इस धारणा पर बना है कि हर tenant अलग-अलग size और offset के साथ collective random access workload पैदा करेगा

आधार तकनीक: hard drive (HDD)

  • S3 की चौंकाने वाली scalability और performance का आधार पारंपरिक storage medium HDD है
  • HDD पुरानी तकनीक है; इसकी durability ऊंची होती है, लेकिन physical movement के कारण IOPS और latency में सीमाएं होती हैं
    • rotation per second (जैसे 7200 RPM) और actuator seeking जैसी mechanical motion आवश्यक होने से latency संरचनात्मक रूप से अधिक और लगभग अपरिहार्य होती है
    • औसत half-platter seek ≈4 ms, औसत half-rotation ≈4 ms, 0.5 MB transfer ≈2.5 ms → random 0.5 MB read का औसत ≈11 ms, single-disk random throughput ≈45 MB/s
  • SSD के विपरीत, यह capacity↑·price↓ की दीर्घकालिक प्रवृत्ति के कारण “अत्यंत कम लागत/उच्च क्षमता” वाली अर्थव्यवस्था देता है, इसलिए बड़े पैमाने के storage में अब भी उपयोगी है
    • कीमत: प्रति byte 6 अरब गुना गिरावट (मुद्रास्फीति-समायोजित)
    • capacity: 72 लाख गुना वृद्धि
    • size: 5,000 गुना कमी
    • weight: 1,235 गुना कमी
  • लेकिन 30 साल से IOPS लगभग 120 पर रुका हुआ है, और random access performance तथा latency में बहुत सुधार नहीं हुआ
  • SSD random I/O के लिए बेहतर है, लेकिन peta/exa-scale storage में total cost of ownership (TCO) के लिहाज से कमजोर पड़ता है

sequential I/O के लिए optimized write path

  • HDD sequential access के लिए optimized होता है; लगातार bytes को पढ़ने-लिखने पर disk platter स्वाभाविक रूप से घूमता रहता है और data को तेज़ी से प्रोसेस किया जा सकता है
  • log-structured data structure ऐसी sequential विशेषताओं का लाभ उठाती है
    • S3 की आंतरिक storage layer ShardStore log-structured LSM अपनाती है, ताकि writes को disk sequential append के रूप में संभाला जा सके
    • इसी तरह batch processing के जरिए disk sequential throughput को अधिकतम किया जा सकता है

random read path के लिए parallelization और Erasure Coding

  • read में user request के अनुसार arbitrary (random) location jump होते हैं, इसलिए यह सीधे भौतिक सीमाओं से टकराता है (random I/O की औसत latency लगभग 11ms)
    • एक HDD पर random I/O से अधिकतम 45MB प्रति सेकंड प्रोसेस किया जा सकता है
    • इसलिए बड़ी मात्रा में data storage के लिए HDD cost-effective है, लेकिन random access performance कमजोर रहती है
  • S3 इस physical limit को पार करने के लिए data को कई disks में shard करता है और एक साथ पढ़कर aggregated throughput बढ़ाने वाली massive parallelization अपनाता है
    • data को असंख्य HDD में distribute किया जाता है, और हर disk की input/output को parallel में इस्तेमाल कर कुल throughput बहुत बढ़ाया जाता है
    • उदाहरण के लिए, 1TB file को 20,000 HDD में split करके store किया जाए तो सभी disks का throughput जोड़कर TB/s स्तर की read संभव हो सकती है

error correction coding (Erasure Coding)

  • storage system में redundancy सुनिश्चित करना अनिवार्य है
  • S3 Erasure Coding (EC) का उपयोग करके data को K data fragments और M parity fragments में विभाजित करता है
    • कुल K+M में से कोई भी K fragments मिल जाएं तो reconstruction संभव है
  • S3 9-way split (5 data shards, 4 parity shards) पर आधारित Erasure Coding (5-of-9) से संतुलन हासिल करता है
    • 5 data + 4 parity = 9 fragments
    • अधिकतम 4 shards खोने पर भी recovery संभव, यानी कोई भी 5 fragments मूल data को restore करने के लिए पर्याप्त हैं, जिससे fault tolerance मिलती है
    • storage overhead ≈1.8x है, जो 3x replication की तुलना में अधिक capacity-efficient है
    • साथ ही 5 parallel read paths मिलते हैं, जो shard parallelization और straggler avoidance के लिए फायदेमंद हैं
  • इस तरह S3 इन physical limits को पार करते हुए बड़े पैमाने के data पर random access उपलब्ध कराता है

parallel processing structure

  • S3 3 मुख्य parallelization तरीकों का उपयोग करता है
    • 1. user data को कई chunks में बांटकर upload और download करता है
    • 2. client कई frontend servers को एक साथ request भेजता है
    • 3. server object को कई storage servers में distribute करके store करता है

  • 1. frontend server unit parallel processing

    • internal HTTP connection pool का उपयोग कर कई distributed endpoints से एक साथ connection बनाए जाते हैं
    • इससे किसी खास infrastructure node या cache पर overload रुकता है

  • 2. hard drives के बीच parallel processing

    • EC के आधार पर data को कई HDD में छोटे shards के रूप में distribute किया जाता है

  • 3. PUT/GET request parallel processing

    • client data को कई भागों में तोड़कर parallel upload करता है
    • PUT: multipart upload से नए writes की parallelization को अधिकतम किया जाता है
    • GET: byte-range GET support (object के भीतर केवल कुछ range पढ़ी जा सकती है)
  • parallel distributed processing से प्रति सेकंड 1GB upload जैसी चीज़ें भी बिना कठिनाई हासिल की जा सकती हैं

hotspot से बचाव

  • S3 करोड़ों drives, प्रति सेकंड सैकड़ों मिलियन requests, और सैकड़ों मिलियन shards वाले parallel operating environment में काम करता है
  • अगर load किसी खास disk या node पर केंद्रित हो जाए, तो पूरे system की performance गिरने का जोखिम होता है
  • इसे रोकने की मुख्य रणनीतियाँ:
    • 1. data placement का random distribution
    • 2. सतत rebalancing
    • 3. system scale का विस्तार

  • 1. shuffle sharding & Power of Two

    • शुरुआती data placement को random तरीके से distribute किया जाता है
    • ‘Power of Two Random Choices’ algorithm लागू किया जाता है:
      • random 2 nodes में से कम load वाले को चुनने पर प्रभावी load balancing मिलती है

  • 2. rebalancing

    • data temperature: इस गुण का उपयोग कि नया data अधिक hot होता है (ज्यादा बार access होता है), और periodic rebalancing के जरिए space और I/O को फिर से distribute किया जाता है
      • data जितना पुराना होता जाता है, access frequency उतनी कम होती है, जिससे पूरे storage system की I/O headroom बढ़ती है
    • S3 cold data को redistribute कर space और resource utilization को अधिकतम करता है
    • नया rack जोड़ने पर (जैसे 20 PB/rack, 1000×20 TB) खाली capacity में active distribution की जरूरत होती है

  • 3. Chill@Scale

    • scale effect: workload जितने स्वतंत्र होते हैं, burst concurrency उतनी घटती है, और aggregate load अधिक समतल हो जाता है; इसे de-correlation कहा जाता है
    • system जितना बड़ा होता है, peak/average gap घटती है और predictability बढ़ती है
    • यानी उपयोग भले ही तेज़ बढ़े और फिर idle हो, बड़े scale पर वे उतार-चढ़ाव एक-दूसरे को cancel करके अधिक पूर्वानुमेय load बनाए रखते हैं

operations, reliability culture और अन्य तकनीकें

  • DNS-level shuffle sharding के जरिए name resolver स्तर पर tenants के बीच isolation और समान वितरण हासिल किया जाता है
  • software rollout भी EC की तरह gradual और zero-downtime तरीके से किया जाता है, और ShardStore migration भी service impact के बिना आगे बढ़ाया गया
  • durability culture: लगातार fault detection, chain of custody, durability threat modeling, formal verification जैसी process-driven reliability practices अपनाई जाती हैं

यह क्यों महत्वपूर्ण है: S3 पर आधारित data infrastructure trends

  • Stateless architecture के प्रसार के साथ एक पैटर्न बढ़ रहा है जिसमें application nodes stateless रहते हैं और persistence, replication, load balancing को S3 को सौंप देते हैं
    • उदाहरण: Kafka Diskless(KIP-1150), SlateDB, Turbopuffer, Lucene on S3, ClickHouse/OpenSearch/Elastic की object storage integration
  • इसके फायदे हैं elastic scaling, operations simplification, cost reduction, जबकि नुकसान latency बढ़ने की संभावना है; इसलिए workload के अनुसार latency, cost, durability के तीन-तरफ़ा trade-off को डिज़ाइन करना पड़ता है

सारांश

  • AWS S3 एक बड़े पैमाने की multi-tenant storage service है, जो धीमे storage media की सीमाओं को massive parallelism, load balancing, data sharding जैसी तकनीकों से पार करती है
  • Erasure Coding, random distribution, continuous rebalancing, hedged requests के जरिए reliability और performance सुनिश्चित किए जाते हैं
  • शुरुआत में यह backup और media-centric storage के लिए था, लेकिन अब data analytics और machine learning जैसे big data infrastructure के मुख्य storage के रूप में विकसित हो चुका है
  • S3-आधारित architecture stateless scalability हासिल करता है और durability, replication, load balancing जैसी समस्याओं को प्रभावी ढंग से AWS को सौंप सकता है
  • इससे cloud cost reduction और management efficiency भी मिलती है

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

2 टिप्पणियां

 
shakespeares 2025-10-05

अगर तकनीक अच्छी नहीं होती, तो लगता है इससे मुनाफा नहीं होता।
 
GN⁺ 2025-09-27
Hacker News राय

  • इसमें कुछ तथ्यात्मक गलतियां हैं, लेकिन लेख के प्रवाह पर उनका बहुत बड़ा असर नहीं पड़ता। उदाहरण के लिए, यह दावा कि S3 5:9 sharding स्कीम का इस्तेमाल करता है, जबकि वास्तव में S3 कई तरह की sharding स्कीम इस्तेमाल करता है, और मेरी जानकारी में 5:9 उनमें से एक नहीं है। 1 logical byte पर 1.8 physical byte का अनुपात HDD लागत के नज़रिये से वास्तव में बहुत खराब संख्या है। असल में इस अनुपात को और कम करने के तरीके भी हैं, और इससे parallelism बढ़ता है तथा availability भी बेहतर होती है। उदाहरण के लिए, यह सोचना ज़रूरी है कि जब पूरा AZ डाउन हो जाए, तब object के GET न हो पाने की स्थिति आने तक कितने shards खोए जा सकते हैं

    • मैंने इस YouTube वीडियो के 42:20 बिंदु पर यह समझा था कि S3 वही sharding स्कीम इस्तेमाल करता है। अगर आपको इससे ज़्यादा पता हो तो जानना चाहूंगा

    • 1.8x अनुपात को कम करते हुए availability बढ़ाना एक साथ सहज रूप से समझना कठिन लगता है। अगर replicas कम हों, तो AZ failure की स्थिति में data loss का जोखिम नहीं बढ़ेगा? मेरी समझ थी कि AWS 3 AZ में पूरी तरह स्वतंत्र replicas देता है। और 16MB chunk को पढ़ने के लिए वास्तव में 5 अलग hard drives से 4MB-4MB पढ़ना तेज़ होता है, यह बात अब भी मुझे हैरान करती है

    • VAST data 146+4 स्कीम का उपयोग करता है। (लिंक)

  • मुझे यह लेख पढ़कर मज़ा आया, लेकिन शीर्षक के सवाल का जवाब बहुत स्पष्ट है: parallelism

    • आमतौर पर मैंने storage I/O speed को इतने बड़े पैमाने पर लगभग कभी नहीं सोचा था। पहले कभी hard disk को तेज़ लिखने के लिए RAID0 इस्तेमाल किया था, लेकिन वह बहुत पुरानी बात है। शुरुआत में मुझे लगा था कि शायद caching या tiering जैसी कोई दिलचस्प तकनीक होगी। पढ़ने के बाद ही लगा कि parallelism ही स्वाभाविक जवाब है, लेकिन S3 के implementation details या error correction के तरीके तक मैंने नहीं सोचा था। parallelism शब्द ही मुख्य बात है, लेकिन विवरण में अच्छी insight थी। मेरा मानना है कि minio के पास भी scaling को लेकर इसी तरह की कहानी होगी: फिर वही parallelism

    • मुझे लगता है कि लेख का शीर्षक थोड़ा भ्रमित करता है क्योंकि वह केवल S3 की कुल peak throughput पर फोकस करता है। असली दिलचस्प सवाल यह है कि "HDD की maximum throughput से ज़्यादा GET throughput कैसे संभव है"। अगर सिर्फ replication हो, तो कई HDD को GET के लिए parallel में assign करने से S3 के पूरे सिस्टम के स्तर पर throughput बढ़ेगा, लेकिन आखिरकार वह individual HDD throughput * GET request count तक सीमित रहेगा। जबकि S3 में यही सीमा नहीं है, और यही उसकी गुप्त तथा दिलचस्प बात है

    • अगर लाखों hard disks को जोड़ दें, तो बहुत बड़ा I/O bandwidth मिलता है

    • यह कुछ "चांद पर जाने का तरीका स्पष्ट है: यात्रा" जैसी तर्कशैली लगती है

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    औसतन, अगर [0,1] अंतराल में दो बिंदु uniform distribution से हों, तो उनके बीच की दूरी का expected value 0.5 नहीं बल्कि 1/3 होता है। अगर full platter seek time 8ms है, तो average seek time 2.666ms होना चाहिए

    • आधुनिक drives में full seek, 8ms की तुलना में 25ms के काफ़ी करीब होता है। अगर आप खुद test करना चाहें, और आपके पास hard disk और root access हो, तो fio में --readonly option देकर disk के दोनों सिरों से बारी-बारी से पढ़ने का test चला सकते हैं। एक अच्छा paper भी है (यहां) जो समझाता है कि आधुनिक drives में 1/3 वाला आंकड़ा क्यों सटीक नहीं है। अगर disk drive mechanics या performance को लेकर और सवाल हों, तो मैं जवाब दे सकता हूं

    • जब tracks के बीच move किया जाता है, तो head acceleration होता है। दूरी जितनी कम होती है, peak speed उतनी कम होती है, और कुछ constant latency भी होती है (जैसे settling time), इसलिए वास्तविक औसत 4ms हो सकता है

    • Platter गोल होता है, इसलिए uniform distribution [0, 1] नहीं बल्कि [0, 2pi] वाले unit circle distribution का उपयोग करना चाहिए, और चूंकि platter सिर्फ एक दिशा में घूमता है, दूरी हमेशा clockwise ही गिनी जानी चाहिए।
      अगर समस्या को सरल करें: शुरूआती बिंदु 0 degree है, और लक्ष्य बिंदु कोई भी random बिंदु है, तो औसत दूरी क्या होगी? 0-180 degree और 180-360 degree की arc length समान है, इसलिए औसत दूरी 180 degree होगी। यानी half-platter seek, full-platter seek का ठीक आधा है

  • अगर S3 अब भी अपनी base service में HDD का उपयोग करता है, तो कीमत देखकर और उसे IOPS के आधार पर convert करके इसका अंदाज़ा लगाया जा सकता है। S3 के GET/PUT request charges इतने महंगे हैं कि AWS के पास high-performance tenants के लिए कुछ disk space खाली छोड़कर इस्तेमाल करने की गुंजाइश है। लेकिन यह केवल थोड़ा-सा अधिक महंगा होने तक ही सही बैठता है, उससे ज़्यादा नहीं

  • मैं सोच रहा हूं कि क्या S3 का कुछ हिस्सा SSD पर चलता है। मुझे लगा था कि standard S3 भी SSD-backed होगा, और केवल slow tiers ही HDD या धीमे सिस्टम का उपयोग करते होंगे

    • S3 का KeyMap Index SSD का उपयोग करता है। इस समय तक यह मानना उचित है कि SSD पहले से ही hot object cache या नए one zone products के किसी हिस्से में इस्तेमाल हो रहा होगा

    • असली stored data लगभग निश्चित रूप से HDD पर होने की संभावना है। लेकिन metadata, index वगैरह के लिए कहीं तेज़ flash storage उपयोग होने की उम्मीद है। छोटे Ceph clusters के MDS servers भी आमतौर पर ऐसा करते हैं, और S3 का scale तो उससे कहीं बड़ा है

    • यह बात ऊपर एक बार आ चुकी है, लेकिन standard tier के लिए request charges इतने ऊंचे हैं कि अगर कुछ ग्राहकों का IOPS/TB ratio ज़्यादा भी हो, तो भी कुछ disk capacity खाली छोड़ना लागत के हिसाब से ठीक बैठता है। लेकिन उससे अधिक महंगा होने पर यह फायदेमंद नहीं रहता। आधुनिक HDD लगभग 30TB store करते हैं, और AWS इन्हें वास्तव में कितने में खरीदता है यह नहीं पता, लेकिन मोटे तौर पर 300-500 डॉलर के बीच अनुमान लगाया जा सकता है। 30TB SSD की तुलना में यह बहुत सस्ता है। साथ ही, ऐसे HDD को high-density systems में भी लगाया जा सकता है, जैसे 4U में 100 drives, और इससे कुल cost में केवल लगभग 25% की बढ़ोतरी होती है। दूसरी ओर, बहुत सारे SSD support करने वाले hardware boxes में per-slot cost कहीं ज़्यादा होती है

    • मेरा अनुमान है कि S3 Express One Zone शायद SSD-based होगा। हालांकि Amazon ने शायद इसे सार्वजनिक रूप से स्पष्ट नहीं किया है

    • metadata तो लगभग निश्चित रूप से SSD पर रखा जाता होगा। बार-बार पढ़े जाने वाले hot objects को SSD पर cache किया जा सकता है

  • यह हैरानी की बात है कि HDD की कीमतें लगातार गिरती रहीं, लेकिन S3 की pricing कम से कम 8 साल तक वही रही। price-cut competition की कमी के कारण ऊंची pricing बनी हुई है। इससे AWS को कितनी बड़ी कमाई होती होगी, इसकी कल्पना की जा सकती है

    • AWS की pricing policy लगभग सभी services में ऐसी ही है। उदाहरण के लिए, EC2 का m7a.medium instance on-demand पर 50 डॉलर प्रति माह और 1-year reserved पर 35 डॉलर है। समान specs वाली दूसरी कंपनियों की services की तुलना में भी यह बहुत competitive नहीं लगता

    • inflation का असर भी है, इसलिए nominal pricing समान रहने पर भी वास्तविक रूप से कीमत घटी मानी जा सकती है। लेकिन मैं सहमत हूं कि inflation की रफ्तार, technology progress की गति से बहुत धीमी होती है

    • मेरा मानना है कि cost reduction incentive का लक्ष्य ही नहीं है। Splunk या CrowdStrike जैसी कंपनियों को देखें जो AWS में बहुत विशाल data store करती हैं, तो वहां बहुत अधिक repetitive data होता है, और वे उसे लगभग वैसे ही ग्राहकों को bill कर देते हैं, बस साधारण deduplication लागू करके। अगर cost कम की जाए, तो उल्टा बेकार usage और बढ़ाने का incentive बनता है

    • मुझे जिज्ञासा है कि क्या HDD की कीमतों में गिरावट वास्तव में इतनी बड़ी रही है। पिछले कुछ वर्षों में hard disk की per-GB कीमत गिरने की रफ्तार काफी धीमी हुई है, इसलिए लगता है कि SSD जल्द ही इसकी बराबरी कर सकता है

  • S3 पर और दिलचस्प लेख के रूप में "Building and operating a pretty big storage system called S3" की सिफारिश करता हूं

  • rustfs का वास्तविक performance कैसा है, यह जानने की उत्सुकता है

  • जब यह कहा जाता है कि करोड़ों HDD इस्तेमाल हो रहे हैं, तो यदि enterprise HDD की क्षमता 10-20TB मानी जाए, तो AWS S3 की कुल capacity सैकड़ों Exabyte के स्तर पर आंकी जा सकती है। संभव है कि यह पृथ्वी का सबसे बड़ा storage system हो

    • अगर 2013 के बाद से hardware upgrade हुआ है, तो Utah का एक खास data center शायद उस capacity को पार कर सकता है (संबंधित लेख)

    • मौजूदा enterprise HDD 30TB तक हैं, और जल्द 50TB तक भी पहुंचने की संभावना है

  • मैं ऐसा open source service जानना चाहता हूं जो HDD के लिए optimize हो और समान performance दे सके। प्रमुख projects (MinIO, Swift, Ceph+RadosGW, SeaweedFS) सभी flash-only deployment की सिफारिश करते दिखते हैं। हाल में मैं Garage नाम के project को देख रहा हूं, लेकिन उसका design काफी अलग है, जैसे कि वह EC का उपयोग नहीं करता

    • Ceph+RadosGW भी HDD पर काफ़ी अच्छी तरह काम करता है। बस index pool के लिए SSD चाहिए, और HDD pool से वास्तव में कितने IOPS की उम्मीद की जा सकती है, इस पर वास्तविक समझ होनी चाहिए। client side के IOPS असल में कई गुना बढ़कर backend पर असर डालते हैं, और S3 भी इस समस्या को बहुत सारे HDD के ज़रिए हल करता है। 4MB streaming large-object storage के लिए यह बड़ी समस्या नहीं है, लेकिन अगर छोटे keys पर बहुत random reads/writes हों या एक ही key पर बहुत distributed access हो, तो backend performance महत्वपूर्ण हो जाता है

    • Lustre/ZFS भी समान speed दे सकते हैं। लेकिन अगर high IOPS चाहिए, तो Lustre के मामले में MDS पर flash चाहिए, और ZFS में dedicated log SSD चाहिए

    • इन सभी services को वही performance देने के लिए बड़े data-center स्तर पर बहुत सारी drives चाहिए होती हैं। बहुत कम deployments ही ऐसे scale को संभाल पाते हैं। इसी वजह से flash, space/cost के हिसाब से fast access के लिए अधिक efficient है

    • SeaweedFS ने पिछले कुछ वर्षों में काफी प्रगति की है और अब RDMA support तथा EC भी जोड़ लिया है

    • मेरी पिछली नौकरी में हमने SwiftStack पर आधारित object storage चलाया था, जहां metadata SSD पर और object data सामान्य HDD पर रखा जाता था। यह काफी अच्छी तरह काम करता था