IO डिवाइस और latency समस्याएँ

 (planetscale.com)
1 पॉइंट द्वारा GN⁺ 2025-03-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें

IO डिवाइस और latency

  • Non-volatile storage devices आधुनिक कंप्यूटर सिस्टम का एक मुख्य घटक हैं, और बिजली बंद होने पर भी डेटा स्टोर कर सकते हैं। CPU register, CPU cache और RAM जैसे volatile storage devices के विपरीत, इन्हें लगातार बिजली की आवश्यकता नहीं होती।

Tape storage devices

  • 1950 के दशक से कंप्यूटर non-volatile digital storage के लिए tape drives का उपयोग करते आए हैं। Tape डेटा की लंबी sequence को स्टोर करने के लिए उपयुक्त है, और उन स्थितियों में ठीक है जहाँ बड़ी मात्रा में डेटा को सुरक्षित रखना हो लेकिन उसे बार-बार पढ़ने की आवश्यकता न हो।
  • Tape कम लागत और लंबी आयु प्रदान करता है, और आज भी CERN और AWS जैसे बड़े data repositories में उपयोग किया जाता है।

Hard disk drives (HDD)

  • Hard disk drives tape की तुलना में तेज़ data access प्रदान करते हैं, और circular metal disks पर डेटा स्टोर करते हैं। Disk का पूरा surface area हमेशा उपलब्ध रहता है, जिससे data read और write latency कम होती है।
  • HDD command queuing को support करते हैं, जिससे कई commands को parallel में execute किया जा सकता है।

Solid-state drives (SSD)

  • Solid-state drives mechanical parts के बिना electronic तरीके से डेटा को read और write करते हैं, और NAND flash का उपयोग करके non-volatile storage प्रदान करते हैं।
  • SSD parallel processing और garbage collection के माध्यम से performance को optimize कर सकते हैं। डेटा की arrangement performance को प्रभावित कर सकती है।

Cloud में storage

  • Cloud की ओर बढ़ने से IO performance में बदलाव आया है, और कई कंपनियाँ अपने servers और database systems को cloud में migrate कर रही हैं।
  • Cloud environment में storage और computing का separation आम है, जो डेटा की safety और flexibility देता है, लेकिन performance degradation का कारण बन सकता है।

Storage और computing का separation

  • परंपरागत रूप से servers सीधे जुड़े non-volatile storage devices का उपयोग करते थे, लेकिन cloud में network के माध्यम से storage को जोड़ना सामान्य है।
  • Network-connected storage डेटा की safety प्रदान करता है, लेकिन IO performance पर नकारात्मक प्रभाव डाल सकता है।

Local vs network storage

  • Local NVMe SSD बहुत तेज़ IO speed प्रदान करते हैं, और network-connected storage की तुलना में कम latency रखते हैं।
  • Network-connected storage में IO operations पर सीमाएँ हो सकती हैं, जो performance degradation का कारण बन सकती हैं।

समाधान: Metal

  • Metal PlanetScale द्वारा दिया गया एक solution है, जो directly attached NVMe SSD drives का उपयोग करके बेहतरीन performance और scalability प्रदान करता है।
  • Metal cluster मूल रूप से एक primary server और दो replicas से बना होता है, जो डेटा की durability सुनिश्चित करता है, और storage capacity को आसानी से scale किया जा सकता है।
  • Metal database में IO operations पर कोई artificial limits नहीं हैं, और यह न्यूनतम latency के साथ IO operations कर सकता है।

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

1 टिप्पणियां

 
GN⁺ 2025-03-15
Hacker News की राय
  • उल्लेख किया गया कि ब्लॉग लेखक ने यह लेख लिखते समय बहुत आनंद लिया। हज़ारों lines की JavaScript का उपयोग करके interactive visual बनाए गए
  • बताया कि वे लंबे समय से SQLite+NVMe के समर्थक रहे हैं। यह एक नया pattern है, जो horizontal scaling के बिना भी समस्याएँ हल करने की संभावना देता है
    • performance समस्याओं में latency सबसे महत्वपूर्ण है
    • खासकर उन मामलों में जहाँ processing sequentially करनी होती है
    • NVMe पर SQLite चलाने से latency का ऐसा फ़ायदा मिलता है जो दूसरे providers नहीं दे सकते
    • ज़्यादातर वास्तविक use cases में memory execution, NVMe persistence की तुलना में बहुत बड़ा लाभ नहीं देता
  • इसकी जानकारी-समृद्धता की प्रशंसा की गई, यहाँ तक कि यह product promotion है यह बात भी भूल जाएँ। बेहतरीन visuals और interactivity का उल्लेख किया गया
  • disk IO animation देखते हुए Melvin Kaye की याद आने की बात कही गई
    • Mel ने time delay loop नहीं लिखा था
    • Flexowriter को output characters के बीच delay चाहिए होता था, तब भी ऐसा ही था
    • commands को drum पर इस तरह रखा गया था कि ज़रूरत पड़ने पर वे read head के ठीक पीछे आ जाएँ
    • drum को अगला command ढूँढने के लिए पूरा rotation करना पड़ता था
  • ब्लॉग को अच्छा बताया गया। आम तौर पर cloud storage के "असामान्य रूप से धीमा" होने की ओर इशारा किया गया
    • बताया गया कि हाल ही में S3/object storage में incremental index store करने का support जोड़ा गया है
    • NVMe को अधिक समय तक इस्तेमाल करने का कारण पिछले लेख में बताए गए performance फ़ायदे थे
    • उम्मीद जताई गई कि कोई बेहतर offering के साथ इस क्षेत्र में बदलाव लाए
  • distributed storage के बारे में इस लेख में पर्याप्त चर्चा न होने की ओर ध्यान दिलाया गया
    • कुछ systems में replication के लिए built-in support नहीं होता
    • Cassandra cluster और MySQL master-slave replication कर सकते हैं, लेकिन कई systems ऐसा नहीं कर सकते
    • cloud में NVMe storage इस्तेमाल करते समय maintenance interval और cloud द्वारा शुरू किए गए drain का सम्मान करना पड़ता है
    • storage को compute से अलग करने पर cloud operator ज़रूरत के मुताबिक compute को move कर सकता है
    • क्योंकि data, compute से स्वतंत्र होता है, cloud operator data system और drain को manage कर सकता है
  • Metal बहुत शानदार लग रहा है। यह भी बताया गया कि पिछली नौकरी में GCP के instance-local SSD का उपयोग करने की कोशिश के दौरान गंभीर reliability समस्याएँ थीं
    • device के blocks द्वारा data खोने की समस्या थी
    • पूछा गया कि क्या अब यह स्थिति सुधरी है
    • इस्तेमाल किए जा रहे machine type के बारे में पूछा गया
    • समाधान के रूप में Discord के network disk उपयोग करने का ज़िक्र किया गया
  • PlanetScale Metal बहुत मज़बूत दिखता है। releases में latency का काफ़ी कम होना देखना हमेशा दिलचस्प होता है
  • यह बहुत बेहतरीन लेख है। random writes की visualization बहुत अच्छी तरह की गई है
    • cloud में network-attached storage की एक और समस्या IOPS limit है
    • AWS और Google Cloud सहित कई cloud providers यह model इस्तेमाल करते हैं और भेजे जा सकने वाले IO operations की मात्रा सीमित करते हैं
    • यदि storage सीधे compute instance से जुड़ा हो, तो IO operations पर कोई कृत्रिम limit नहीं होती
    • hardware जितनी अनुमति दे, उतनी तेज़ी से read और write किया जा सकता है
    • यह जिज्ञासा जताई गई कि "IOPS" limit क्या किसी विशेष network traffic पर limit है
    • पूछा गया कि क्या इसका मतलब EBS volume network traffic है
    • यह भी सोचा गया कि क्या cost savings संभव है, क्या यह AWS के अजीब arbitrage की वजह से है, या कम EBS networking करने से efficiency मिलती है
    • साफ़ दिखता है कि storage और compute को एक ही machine पर रखने से latency के लिहाज़ से फ़ायदा होता है
    • यह भी पूछा गया कि क्या cost-per-throughput के लिहाज़ से भी कोई लाभ है
  • यह जिज्ञासा जताई गई कि "serverless" database providers कैसे "low-latency" access का विज्ञापन करते हैं
    • वे S3 जैसी object storage का उपयोग करते हैं, जिसकी latency network storage से काफ़ी खराब होने की उम्मीद है
    • बताया गया कि उन्होंने caching layer बनाई है और data को locally attached NVMe पर रखने की बात कही है