IO डिवाइस और लेटेंसी

 (planetscale.com)
1 पॉइंट द्वारा GN⁺ 2025-03-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • non-volatile storage टेप से HDD, SSD और cloud network storage तक विकसित हो चुका है, लेकिन डेटा की location और placement अब भी IO लेटेंसी तय करते हैं
  • टेप स्टोरेज sequential read/write में मजबूत है, लेकिन दूर स्थित डेटा पढ़ने में दर्जनों सेकंड लग सकते हैं, इसलिए यह high-traffic transaction database के लिए उपयुक्त नहीं है
  • HDD ने टेप की तुलना में लेटेंसी काफी घटाई, लेकिन rotating platter और head movement के कारण random read आम तौर पर 1~3ms स्तर का होता है, और request order के अनुसार performance में बड़ा अंतर आता है
  • SSD बिना mechanical parts के NAND flash पर काम करते हैं, इसलिए random read 16μs तक तेज हो सकता है, लेकिन parallelism के उपयोग और garbage collection के कारण डेटा placement अब भी लगातार महत्वपूर्ण रहता है
  • cloud में storage और compute का separation scalability और failure handling को आसान बनाता है, लेकिन network round-trip और IOPS limit जोड़ता है; PlanetScale Metal direct-attached NVMe SSD और replication से इस लागत को कम करने की कोशिश करता है

स्टोरेज लेटेंसी को तय करने वाले बुनियादी तत्व

  • non-volatile storage बिजली बंद होने पर भी डेटा सुरक्षित रखता है, और फोटो, ईमेल, बैंक बैलेंस, मेडिकल रिकॉर्ड जैसे डेटा को स्टोर करने की बुनियाद है
  • CPU register, CPU cache, RAM जैसे volatile storage तेज होते हैं, लेकिन इन्हें लगातार बिजली चाहिए
  • स्टोरेज performance सिर्फ capacity का सवाल नहीं है; यह इस बात पर निर्भर करता है कि डेटा तक कैसे पहुँचा जाता है, read/write unit क्या है, queuing कैसे होती है, parallelism कितना है, और network round-trip है या नहीं
  • PlanetScale ने PlanetScale Metal लॉन्च करते समय बताया कि Metal network-attached storage की जगह local NVMe drive पर cloud database चलाता है

टेप स्टोरेज: sequential access में मजबूत, random access में कमजोर

  • कंप्यूटर 1950 के दशक से tape drive को non-volatile digital storage के रूप में इस्तेमाल करते आए हैं
  • tape cartridge कई track और बहुत सारे cell से मिलकर बनती है, और हर cell की magnetic polarization state binary data को दर्शाती है
  • cartridge को reader में डालकर motor से घुमाया जाता है, और IO head उसके पास से गुजरने वाले डेटा को पढ़ता है
  • अगर read/write position head के पास हो तो यह तेज होता है, लेकिन दूर होने पर लेटेंसी बढ़ जाती है
    • आधुनिक tape system में भी दूर का डेटा पढ़ने के लिए सैकड़ों मीटर टेप घुमानी पड़ सकती है
    • ऐसे मामलों में read में दर्जनों सेकंड लग सकते हैं
  • read/write की संख्या समान होने पर भी अगर डेटा बिखरा हुआ हो तो sequential placement की तुलना में बहुत अधिक समय लगता है
    • लेख का उदाहरण दिखाता है कि बिखरे हुए read/write उसी workload में लगभग 7 गुना अधिक समय ले सकते हैं
  • random read/write लेटेंसी खराब होने के बावजूद, टेप अभी भी लंबे sequential read/write के लिए उपयुक्त है
    • SSD और HDD की तुलना में इसकी GB प्रति लागत कम है और archival lifetime लंबी है
    • CERN tape storage data warehouse में 400PB से अधिक डेटा प्रबंधित करता है
    • AWS भी tape archiving service प्रदान करता है
  • high-traffic transaction database के लिए टेप उपयुक्त नहीं है

HDD: rotating disk और command queuing का समझौता

  • HDD टेप की जगह circular metal disk यानी platter पर डेटा स्टोर करता है
  • platter enclosure के भीतर तेज़ी से घूमता है, और उदाहरण के तौर पर 7200 RPM को सामान्य गति बताया गया है
  • HDD के track गोलाकार होते हैं, और एक disk पर 100,000 से अधिक track हो सकते हैं
  • हर track में सैकड़ों हजार page हो सकते हैं, और हर page लगभग 4KB डेटा रखता है
  • HDD head movement और platter rotation से read/write position को align करता है
    • टेप के विपरीत, पूरी सतह के bit हमेशा access के लिए उपलब्ध रहते हैं
    • इच्छित डेटा सामने आने तक टेप लपेटने की ज़रूरत नहीं होती
  • सामान्य random read 1~3ms में किया जा सकता है
  • request order performance पर बड़ा असर डालता है
    • अधिक sequential read/write जल्दी पूरे होते हैं
    • वही 6 read/write अगर मिश्रित क्रम में हों, तो platter के सही position पर आने का इंतज़ार बढ़ जाता है
  • magnetic disk लंबे समय से command queuing को support करती है
    • SCSI ने 1980 के दशक से, और SATA ने 2000 के दशक से संबंधित features दिए हैं
    • OS कई command को parallel या बदले हुए क्रम में execute होने के लिए भेज सकता है
    • disk controller task queue का उपयोग करके disk structure के अनुसार read/write schedule कर सकता है
  • HDD टेप से बेहतर है, लेकिन खासकर random read/write में यह अब भी धीमा हो सकता है

SSD: mechanical parts हटने के बाद भी बचे performance variable

  • SSD या flash storage का आविष्कार 1980 के दशक में हुआ, लेकिन consumer storage के रूप में यह 2000 के दशक में मुख्यधारा में आया
  • SSD डेटा पढ़ने के लिए mechanical parts पर निर्भर नहीं करता
    • यह NAND flash नाम के non-volatile transistor का उपयोग करता है
    • 1 और 0 को physical parts की movement के बिना electrical signal से read, write और erase किया जाता है
  • SSD एक या अधिक target से बना होता है; हर target में कई block होते हैं, और हर block में कई page होते हैं
  • SSD page unit में read और write करता है
    • भले ही केवल कुछ डेटा चाहिए, drive request unit page ही होती है
  • उदाहरण configuration में page 4096 bit, block 16K page, target 16K block, और device 8 target का हो तो कुल 4k * 16k * 16k * 8 = 8,796,093,022,208 bit यानी 8TB बनता है
  • SSD random read मॉडल के अनुसार अलग हो सकता है, लेकिन 16μs तक तेज हो सकता है
  • mechanical parts न होने पर भी डेटा placement महत्वपूर्ण रहता है
    • SSD performance factors में parallelism और garbage collection शामिल हैं

SSD parallelism: target distribution throughput बदलता है

  • आम तौर पर हर target के पास control unit से जुड़ी एक dedicated line होती है
  • हर line read/write संभालती है, लेकिन एक बार में सिर्फ एक page भेज सकती है
  • page transfer बहुत तेज़ होता है, फिर भी इसमें थोड़ा समय लगता है
  • अगर 8 write 4 target में बँटे हों, तो 4 line को parallel उपयोग करके दो time slice में लिखा जा सकता है
  • अगर 8 write सभी एक ही target पर आ जाएँ, तो सिर्फ एक line उपयोग होगी और बाकी line खाली रहेंगी
  • read/write order और डेटा placement SSD में भी performance को प्रभावित करते हैं
  • MySQL जैसे software को design करते समय इस बात पर ध्यान देना चाहिए कि डेटा किस structure में store हो रहा है और disk पर कैसे रखा जा रहा है

SSD garbage collection: write से पहले erase की लागत

  • SSD page को कई बार पढ़ा जा सकता है, लेकिन एक बार लिखे गए page को पुराने डेटा को explicit रूप से erase किए बिना नए डेटा से overwrite नहीं किया जा सकता
  • अलग-अलग page erase नहीं किए जा सकते; पूरा block erase करना पड़ता है
  • SSD को empty, in-use और dirty page प्रबंधित करने के लिए internal algorithm चाहिए
    • dirty page वह page है जिस पर लिखा जा चुका है, लेकिन जिसका डेटा अब ज़रूरी नहीं है और जो erase के लिए तैयार है
  • नया write लेने के लिए कभी-कभी डेटा को फिर से arrange करना पड़ता है; इसे संभालने वाला algorithm garbage collector कहलाता है
  • अगर पर्याप्त unused page हों, तो नया डेटा सीधे लिखा जा सकता है
  • unused page कम हों और dirty page अधिक हों, तो पहले garbage collection करना पड़ता है
    • उदाहरण में नए 5 page लिखने के लिए 2 non-dirty page को दूसरी जगह ले जाया जाता है
    • उसके बाद उस target के सभी page को dirty state में बदल दिया जाता है ताकि उन्हें erase किया जा सके
    • ये अतिरिक्त चरण write performance को काफी धीमा कर देते हैं
  • read, write और delete बहुत अधिक होने वाले busy SSD में garbage collection दूसरे कामों को भी धीमा कर सकता है

cloud ने जो अतिरिक्त बदलाव जोड़ा: storage और compute का separation

  • टेप से HDD और SSD तक का बदलाव durable IO performance को काफी बढ़ा चुका है
  • cloud की ओर बढ़ने से IO performance में एक और बदलाव आया
  • AWS को 2006 में लॉन्च होने के बाद cloud adoption को व्यापक बनाने वाली service के रूप में प्रस्तुत किया गया है
  • cloud environment में user बड़े data center के किसी भी hardware पर virtualized server किराए पर लेते हैं
  • server hardware failure, replacement, network disconnection जैसी कई वजहों से कभी भी बंद हो सकता है
  • rented cloud infrastructure पर system बनाते समय अधिक बार होने वाली failure को सहने की क्षमता होनी चाहिए
  • इन्हीं परिस्थितियों और dynamically scalable storage volume की ज़रूरत ने storage और compute के separation को जन्म दिया

network-attached storage के फायदे और लागत

  • पारंपरिक रूप से server, desktop, laptop और phone non-volatile storage को direct attach करते हैं
    • SATA cable, PCIe interface, या उसी SoC में built-in रूप जैसी संरचनाएँ उपयोग होती हैं
  • direct-attached storage तेज़ होता है, लेकिन इसकी दो सीमाएँ हैं
    • अगर server बंद हो जाए, तो डेटा भी साथ में उपलब्ध नहीं रहता
    • storage size fixed रहता है
  • application server आम तौर पर ephemeral environment के लिए उपयुक्त होते हैं, और बहुत सा काम memory में होता है, इसलिए यह समस्या वहाँ बड़ी नहीं होती
  • database में server बंद होने पर भी डेटा खोना नहीं चाहिए, और डेटा का आकार तेज़ी से बढ़कर storage limit तक पहुँच सकता है
  • कई cloud provider compute instance से अलग configurable network-attached storage जोड़ने की सुविधा देते हैं
    • EC2 का default setup आम तौर पर EBS network storage volume attach करने का होता है
    • Amazon RDS, Amazon Aurora, Google Cloud SQL, PlanetScale जैसी database service भी ऐसे system पर निर्भर हैं जहाँ compute और storage network से अलग होते हैं
  • यह तरीका data growth या shrink के अनुसार storage volume को dynamic रूप से adjust करने देता है
  • server बंद हो जाए तब भी डेटा सुरक्षित रहता है और किसी दूसरे server से फिर attach किया जा सकता है
  • इसके बदले network round-trip और IOPS limit जैसी performance cost आती है

local NVMe और network storage के बीच लेटेंसी का अंतर

  • direct-attached NVMe SSD ऐसा SSD है जो non-volatile memory host controller interface specification का उपयोग करता है और तेज़ IO speed तथा bandwidth देता है
  • CPU से RAM तक round-trip लगभग 100ns बताया गया है
  • CPU से locally attached NVMe SSD तक round-trip लगभग 50,000ns, यानी 50μs है
  • network-attached storage volume के लिए data center के भीतर भी एक छोटा network round-trip चाहिए
  • EBS जैसे network-attached storage में round-trip लगभग 250,000ns, यानी 250μs या 0.25ms बताया गया है
  • वही आधुनिक SSD इस्तेमाल होने पर भी network connection individual read/write request की processing time को एक अंक के गुणक जितना बढ़ा देता है
  • बड़े sequential IO में नकारात्मक असर कम किया जा सकता है, लेकिन पूरी तरह हटाया नहीं जा सकता
  • network-attached storage storage system तक हर access पर अतिरिक्त लेटेंसी जोड़ता है

IOPS limit और direct-attached storage का अंतर

  • AWS और Google Cloud सहित कई cloud provider network-attached storage model में wire पर भेजे जा सकने वाले IO operation की संख्या सीमित करते हैं
  • Amazon के GP3 EBS instance में default रूप से प्रति सेकंड 3000 IOPS की अनुमति होती है
    • इसे बढ़ाया जा सकता है, लेकिन अतिरिक्त लागत लगती है
  • पुराने GP2 EBS volume कभी-कभी burst देने के लिए IOPS pool जमा करने वाले मॉडल पर काम करते थे
  • storage को compute instance से direct attach करने पर ऐसा कोई artificial IO cap नहीं होता
  • direct attach में hardware जितना अनुमति दे, उतना पढ़ा और लिखा जा सकता है

durability और scalability बनाए रखने का तरीका

  • direct-attached SSD के साथ समस्या 1 यानी data durability को replication से हल किया जा सकता है
  • सामान्य तरीका यह है कि एक server primary होता है जो सभी write request लेता है, और 2 या अधिक अतिरिक्त server डेटा की replica रखते हैं
  • अगर डेटा तीन जगह हो, तो data loss की संभावना बहुत कम हो जाती है
  • उदाहरण के रूप में अगर monthly server failure probability 1% मानी जाए:
    • single server में हर महीने data loss probability 1% होगी
    • तीन server में यह 1% × 1% × 1% = 0.0001% यानी 10 लाख में 1 तक घट जाती है
  • PlanetScale failed node को अपने-आप detect और replace करता है, और database data का नियमित और विश्वसनीय backup लेता है
  • समस्या 2 यानी drive scalability के लिए अधिक manual intervention चाहिए
    • जब disk capacity limit के करीब पहुँचे, तो monitoring और alerting चाहिए
    • आवश्यकता पड़ने पर capacity आसानी से बढ़ाने वाले tools चाहिए

PlanetScale Metal का दृष्टिकोण

  • Metal direct-attached NVMe SSD उपयोग करने वाले database cluster प्रदान करता है
  • हर database instance direct-attached NVMe SSD पर चलता है
  • Metal cluster default रूप से 1 primary और 2 replica से बना होता है
  • supported database cluster Vitess या Postgres हैं
  • storage limit तक पहुँचने पर कुछ clicks में बड़े drive वाले server पर resize किया जा सकता है
  • अंदरूनी तौर पर नया node शुरू किया जाता है और existing instance से नए instance में डेटा migrate किया जाता है; यह प्रक्रिया zero downtime के साथ की जाती है
  • Metal database में कोई artificial IOPS cap नहीं है
  • user कम लेटेंसी के साथ IO operation कर सकते हैं, और cloud provider के महंगे IOPS class cost या throttle के बिना hardware जितना अनुमति दे उतना उपयोग कर सकते हैं

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

1 टिप्पणियां

 
GN⁺ 2025-03-15
Hacker News की राय

  • मैं ब्लॉग लेखक हूं। यह लेख लिखने की प्रक्रिया वाकई मज़ेदार रही, और अब तक बनाए गए लेखों में यह निस्संदेह सबसे जटिल था
    इंटरैक्टिव visualizations बनाने के लिए मैंने सचमुच JavaScript की हजारों लाइनें लिखीं, उम्मीद है सबको यह दिलचस्प लगेगा

    • Visualization शानदार है, और खासकर उछलते बॉक्स वाला animation relative latency को समझाने के सबसे अच्छे तरीकों में से लगा
      हालांकि durability के लिए “10 लाख में 1” वाली अभिव्यक्ति मुझे थोड़ी ज़्यादा pessimistic लगती है, क्योंकि नया server आने और फिर से replicate होने से पहले failure window छोटा होता है
      उदाहरण के लिए अगर recovery 10 मिनट में हो जाए, तो तीन server अगर हर महीने एक बार ज़रूर fail हों, तब भी उनके overlap होकर सभी fail होने की probability शायद पहले ही करीब 20 लाख में 1 होगी; और अगर मासिक failure probability 1% हो, तो तीन failures के overlap की संभावना बेहद कम हो जाती है
      अगर customer 10 लाख हैं, तो 10 लाख में 1 बहुत अच्छा आंकड़ा नहीं है, इसलिए यह जोड़ रहा हूं
    • Animations शानदार हैं और interaction implementation भी बेहतरीन है। काम में लोगों को latency समझाने की ज़रूरत अक्सर पड़ती है, और HDD व SSD जैसे devices की latency difference को आंखों से देखने पर समझना बहुत आसान हो जाता है
    • लगाई गई मेहनत साफ दिखती है। अंदाज़े से ही सही, जानना चाहूंगा कि कितना समय लगा
      मुझे पता है कि keyboard पर टाइप करने में लगा समय और दिमाग में सोच-विचार में लगा समय काफी अलग होते हैं
    • विषय से लगभग आधा जुड़ा सवाल है: animation के लिए कौन-सी library इस्तेमाल की, यह जानना चाहूंगा। source page में तुरंत दिख नहीं रही
      यह विषय मेरे लिए बहुत परिचित है, इसलिए content पर जोड़ने को कुछ नहीं है, और सरसरी तौर पर देखने पर भी अच्छा लग रहा है। लेकिन मैं अपने ब्लॉग के लिए animation की योजना बना रहा हूं और हाल में आज़माई कुछ libraries मुझे पसंद नहीं आईं

  • मैं कुछ समय से SQLite+NVMe combo को promote कर रहा था। निजी तौर पर यह एक नया pattern लगता है जो आम तौर पर जितना आगे जा पाते हैं उससे कहीं ज़्यादा आगे तक ले जा सकता है, और कुछ मामलों में horizontal scaling के बिना भी अंत तक टिक सकता है
    Performance में latency ही राजा है, खासकर जब items को serially process करना पड़े। NVMe पर SQLite चलाने से ऐसा latency advantage मिलता है जो दूसरे providers नहीं दे सकते
    ज्यादातर realistic use cases में मुझे यह भी नहीं लगता कि in-memory execution, NVMe persistent storage से बहुत बेहतर है

    • जानना चाहूंगा कि Postgres जैसे traditional client-server database के बजाय SQLite क्यों
      Single host पर यह थोड़ा तेज हो सकता है, लेकिन जैसे ही web servers 1 से 2 हो जाते हैं और दोनों को database में लिखना पड़ता है, लगता है आप खुद ही काम मुश्किल बना रहे हैं
      Latency महत्वपूर्ण है कहना भी misleading हो सकता है। Consistency न हो तो performance का कोई मतलब नहीं, और जैसे ही कई web servers होते हैं, उस consistency को आपको खुद solve करना पड़ता है
      इसके अलावा database latency आम तौर पर Internet round-trip latency से बहुत कम होती है, और वह Internet latency भी images या code libraries जैसे page assets load होने की “latency” के मुकाबले छोटी होती है
      शुरुआत से ही serial database queries से जितना हो सके बचना चाहिए, संभव हो तो joins इस्तेमाल करें, और जब न हो सके तब भी जितना संभव हो async तरीके से queries एक साथ भेजकर parallel execution करवाना चाहिए
    • SQLite का file system layout HDD defragmentation को ध्यान में रखकर बना है, इसलिए SSD के हिसाब से ज्यादा modern layout में बदलकर NVMe इस्तेमाल करने जितना फायदा शायद नहीं मिलेगा
    • SQLite write parallelism के साथ बहुत अच्छी तरह fit नहीं बैठता। Support है, लेकिन थोड़ा rough है और फिर भी fail हो सकता है
      Parallel writes की समस्या से बचने के लिए कुछ खास rough operating modes set करने के अलावा, application में write-only single thread इस्तेमाल करने की trick अपनाई जा सकती है
      इससे पहले से complex parallel code आम तौर पर थोड़ा और complex हो जाता है। अगर write thread एक हो, तो SQLite सचमुच शानदार चलता है
    • Desktop computer पर ext4 file system की file पर fsync() करके देखें तो NVMe disk पर भी अभी 1~2ms latency measure होती है
      ज्यादा नए system में यह लगभग 800µs थी
    • Coolify से app और database को एक ही machine पर चलाकर देखना काफी मज़ेदार था। SQL queries में लगभग zero latency दिखती है, और practically सिर्फ engine cost बचती है—यह impressive था

  • जानकारी इतनी अच्छी थी कि पढ़ते-पढ़ते यह बात पूरी तरह भूल गया कि यह product promotion है। Visualization और interaction शानदार हैं

  • Disk I/O animation देखकर Melvin Kaye याद आ गए
    धीमे Flexowriter को output characters के बीच delay की ज़रूरत होती थी, तब भी Mel ने time delay loop इस्तेमाल नहीं किया
    इसके बजाय उन्होंने drum पर instructions की position adjust की ताकि जब भी next instruction की ज़रूरत पड़े, read head उसे अभी-अभी पार कर चुका हो, और drum को next instruction खोजने के लिए एक और चक्कर लगाना पड़े
    https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...

    • मुझे भी Mel याद आए। अगर नहीं देखा है, तो YouTube पर Usagi Electric ने 1950s के drum memory system को लगभग पूरी तरह working state में वापस ला दिया है

  • Metal वाकई शानदार दिखता है, लेकिन पिछली job में GCP के instance local SSD इस्तेमाल किए थे तो device blocks data खो देते थे जैसी गंभीर reliability problems आई थीं
    अब स्थिति बदली है या नहीं, और कौन-सा machine type इस्तेमाल कर रहे हैं, जानना चाहूंगा
    उस समय workaround यह था: https://discord.com/blog/how-discord-supercharges-network-di...

    • दिलचस्प workaround है। हमने 2024 में ही GCP Local SSD इस्तेमाल करना शुरू किया, और testing के दौरान bad sectors की वजह से read/write failures नहीं देखे
      हालांकि हम MySQL semi-synchronous replication के साथ redundancy system चला रहे हैं, ताकि client को acknowledge होने से पहले हर write अलग-अलग availability zones की दो machines पर persist हो जाए
      Kubernetes operator और Vitess का vtorc process साथ मिलकर failed या suspicious replicas को actively detect और replace करते हैं
      GCP में n2d-highmem machines पर सबसे अच्छे results मिले, और AWS में instance storage वाले latest generation types को लगभग across the board इस्तेमाल करते हैं

  • अच्छा लेख है। आम तौर पर cloud storage के असामान्य रूप से धीमे होने की समस्या भी होती है
    इसे दूसरी जगहों पर पहले ही कवर किया गया है, लेकिन यह लेख समस्या को अच्छी तरह summarize करता है: http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
    हाल ही में https://github.com/feldera/feldera में incremental indexes को S3/object storage में store करने का support जोड़ा गया है, जबकि NVMe को पहले से support किया जा रहा था, क्योंकि ऊपर के लेख में बताए गए साफ़ performance benefits थे
    काश कोई बेहतर delivery model के साथ इस क्षेत्र को हिला दे

    • वह Database Architects ब्लॉग पढ़ने लायक है

  • इस लेख में distributed storage को लेकर कुछ बातें कम आंकी गई हैं
    पहली, कुछ systems replication built-in नहीं देते। Cassandra cluster या MySQL में master-slave replication हो सकता है, लेकिन कई systems में ऐसा नहीं होता
    दूसरी, cloud में NVMe storage इस्तेमाल करने पर maintenance windows और cloud-initiated drains का ध्यान रखना पड़ता है, जिससे operations काफी मुश्किल हो जाते हैं
    अगर ऐसे system से integrate करके data को दूसरे nodes पर नहीं निकाला, तो data गायब हो जाएगा
    storage और compute को अलग करने पर cloud operator जरूरत पड़ने पर compute को खाली करके move कर सकता है, data compute से independent रहता है, और cloud operator उस data system और drain को भी manage करता है, इसलिए customer intervention के बिना workload placement adjust किया जा सकता है

    • अच्छा point है। PlanetScale की durability और reliability MySQL replication और उस operational software पर बनी है जिसे server exits, network partitions और cloud में आने वाली कई failure situations के बीच भी replication बनाए रखने के लिए लिखा गया है
      replicated network-attached storage, जो “local” file system API जैसा दिखता है, उन systems को durability देने का powerful तरीका है जिनमें हमारे जैसे built-in replication नहीं होता
    • theoretical तौर पर s2.dev ऐसी situation बचा सकता है। यह streaming bandwidth के साथ-साथ चलते हुए durability दे सकता है
    • DRBD शायद अभी भी मौजूद होगा, लेकिन EBS इस्तेमाल करना निश्चित रूप से आसान है
    • यहां drain से क्या मतलब है, यह जानना चाहूंगा

  • वाकई शानदार, और PlanetScale Metal भी काफी solid दिखता है। release में latency का काफी गिरना देखना खास तौर पर पसंद है: https://planetscale.com/blog/upgrading-query-insights-to-met...

  • कई सालों तक समझ नहीं आया कि replicated databases हमेशा EBS से क्यों चिपके रहते हैं और उस latency को क्यों सहते हैं। जब replication पहले से है, तो हिम्मत करके local disk क्यों नहीं इस्तेमाल करते, यही सवाल था
    पिछली organization में Elasticsearch को temporary logs/metrics store के तौर पर चलाते समय, reliability की demand भी ज्यादा नहीं थी, इसलिए मैंने ऐसा करने का सुझाव दिया था, लेकिन convince नहीं कर पाया और आखिर में हमें और खराब AWS Elasticsearch इस्तेमाल करना पड़ा
    मुझे पता है local disk capacity सीमित होती है, लेकिन core/memory/disk ratio ज्यादातर use cases के लिए काफी नहीं होगा क्या, ऐसा लगता है। अलग ratios वाले local disk instances भी काफी हैं, इसलिए सही balance मिल सकता है
    20TB से ज्यादा local hard disk instances से hot/cold storage भी implement किया जा सकता है
    PlanetScale team आखिरकार ऐसा काम कर रही है जो समझ में आता है, इसलिए उनकी बहुत तारीफ करना चाहता हूं। AWS तक Elasticsearch को local disk पर नहीं चलाता—ClickHouse या Cassandra जैसी चीजों को सभी local disk पर चलाने की कल्पना करें

    • Azure Las_v3 series VM के terabyte-scale local SSDs पर SQL Server Availability Groups चलाने के idea पर कभी विचार किया था
      मुख्य समस्या यह थी कि stop-start event के बाद disk wipe हो जाती थी। बाकी cluster ठीक हो और usable replica मौजूद हो, तब भी SQL Server इसे automatically handle नहीं कर पाता
      initialized node को auto-recover नहीं करता, इसलिए इसे bypass करने के लिए scripting और testing production में केवल सबसे साहसी और सक्षम organizations ही संभाल पाएंगी
    • इस बेहतरीन लेख ने storage performance के कुछ axes cover नहीं किए हैं। उनमें से एक यह है कि EBS इस्तेमाल करने पर disk के data को process करने वाले CPU और RAM को बदलने के लिए VM को ऊपर-नीचे scale किया जा सकता है
      हम इसी model से सैकड़ों ClickHouse clusters चलाते हैं। failures की तुलना में performance problems सुलझाने के लिए size adjust करना कहीं ज्यादा आम है
      उदाहरण के लिए, US time में Sunday morning को tenant performance issue आ जाए, तो सबसे सरल solution weekend भर के लिए बड़े VM पर upgrade करना और Monday morning core team से root cause दिखवाना है
      extra cost छोटी होती है, और बहुत महंगे employee burnout से बचा जा सकता है

  • वाकई बेहतरीन लेख है, और random write visualization बहुत अच्छी बनाई गई है
    network-attached storage की IOPS limits को लेकर कुछ शायद बेवकूफी भरे सवाल मन में आते हैं
    पहला, जानना चाहता हूं कि “IOPS” limit किसी खास तरह के network traffic, यानी EBS volume से आने-जाने वाले traffic, पर rate limit ही है क्या। आखिर में पूछना चाहता हूं कि क्या “IOPS” का मतलब “EBS volume network traffic” है
    दूसरा, यह भी जानना चाहता हूं कि क्या यह तरीका cost बचाता है। अगर हां, तो क्या यह अजीब AWS pricing arbitrage की वजह से है, या EBS networking कम होने से मिलने वाली efficiency gain की वजह से
    storage और compute को एक ही machine पर रखना latency के लिहाज से structurally एक hop कम करने का benefit देता है, यह साफ़ लगता है, लेकिन dollars per throughput के हिसाब से भी फायदा है क्या, यह जानना चाहता हूं

    • EBS volume खुद provisioned IOPS और throughput रखता है, और जिस EC2 instance से वह volume attached है, उस पर भी सभी attached EBS volumes को मिलाकर अलग limit होती है
      मैं इसे अलग model से देखता हूं। EBS volume PCIe bus से जुड़े physical board का हिस्सा नहीं है, बल्कि कई physical drives से बने बड़े distributed system में हिस्सेदारी है, और compute से आने-जाने के लिए dedicated network capacity वाले SAN के करीब है
      cost बच सकती है, लेकिन आखिरकार यह कई trade-offs का bundle है
    • network-attached storage की IOPS limit bandwidth नहीं, बल्कि packets per second को limit करती है। क्योंकि input/output operations 4K या 16K blocks जैसे अलग-अलग sizes में हो सकते हैं