क्लाउड में SSDs को छोड़कर, SSDs तेज़ हो गए हैं
Cloud SSD storage अक्सर modern consumer NVMe drives की तुलना में बहुत कम throughput और अधिक latency देता है, यहाँ तक कि major providers की “storage-optimized” instances पर भी। Commenters इस अंतर को network-attached या heavily virtualized storage, conservative firmware और wear-leveling, तथा raw speed की बजाय durability और live migration को प्राथमिकता देने वाले design choices से जोड़ते हैं। यह चर्चा cloud economics और abstractions की आलोचना तक फैलती है, जहाँ कई लोगों का कहना है कि I/O-intensive या steady workloads के लिए local NVMe वाला dedicated या colo hardware, public cloud options की तुलना में काफ़ी तेज़ और सस्ता हो सकता है।
क्लाउड बनाम bare metal और छोटे प्रदाता
- कई लोग तर्क देते हैं कि IO‑heavy workloads बड़े क्लाउड्स पर ठीक से नहीं चलाए जाते: IOPS और throughput महंगे हैं और throttled होते हैं; sustained उपयोग के लिए dedicated servers या NVMe के साथ colo “कहीं सस्ते” हैं।
- दूसरे जवाब देते हैं कि TCO में power, space, bandwidth, spares, और staff शामिल होना चाहिए; छोटी टीमों के लिए, cloud का operational offload hardware savings से बड़ा हो सकता है।
- AWS के विकल्पों में DigitalOcean, Hetzner, OVH, Scaleway, UpCloud (fast block storage), Entrywan, OCI, और कई managed PaaS विकल्प (जैसे Supabase) सुझाए गए। Hetzner की identity-verification freezes को लेकर चिंताएँ उठीं।
- Hybrid setups में सक्रिय रुचि है: elasticity और overflow के लिए cloud का उपयोग, लेकिन steady, IO‑heavy workloads को owned या rented metal पर चलाना।
क्यों cloud SSDs कमज़ोर प्रदर्शन करते हैं
- एक recurring theme: cloud का बहुत सा “SSD” network-attached होता है (EBS, PD-SSD, Azure managed disks) जिसमें:
- local NVMe की तुलना में latency अधिक होती है।
- कई tenants के बीच shared bandwidth होती है।
- अतिरिक्त layers (hypervisors, firmware, schedulers) peak throughput की कीमत पर fairness, durability, और predictable latency को प्राथमिकता देते हैं।
- Counterpoint: सभी बड़े clouds सचमुच local/instance SSD भी देते हैं (AWS instance store, GCP Local SSD, Azure temp/cached disks) जो PCIe-attached होते हैं, लेकिन:
- Ephemeral होते हैं (stop/migration पर data खो जाता है)।
- फिर भी modern consumer NVMe speeds से काफ़ी नीचे capped रहते हैं, संभवतः virtualization और controller firmware के कारण।
Benchmarks और anecdotes
- consumer या small-server NVMe (3–7 GB/s, ~1–1.5M IOPS, tens of µs latency) के कई reports हैं जो भारी मात्रा में outperform करते हैं:
- AWS storage-optimized instances को, जो व्यवहार में ~2–3 GB/s per device और ~500k 4k IOPS देते हैं।
- Azure Premium SSDs को, जिनकी latency 0.4–3 ms दिखती है; Azure के local SSD cache/temp disks ~40 µs तक पहुँच सकते हैं और databases को नाटकीय रूप से तेज़ करते हैं।
- कुछ लोगों को cloud CPUs भी समान on-paper specs की तुलना में धीमे लगते हैं; virtualization और cheap SKUs में पुराने generations पर संदेह है।
Latency, architecture, और trade-offs
- Databases और index-heavy workloads के लिए random-access latency और dependency chains, raw bandwidth से ज़्यादा मायने रखते हैं; networked storage यहाँ नुकसान पहुँचाती है।
- Local SSD को cache के रूप में उपयोग करना (जैसे Rails “SSD cache”, Azure read-caching) कई web workloads के लिए RAM जितना ही प्रभावी हो सकता है, लेकिन बहुत कम लागत पर।
- “Planet scale” के लिए cloud में design करने बनाम एक single powerful box (SQLite/Postgres + lots of RAM/NVMe) से शुरू करने और distributed complexity केवल तब जोड़ने पर बहस जब सच में ज़रूरत हो।
Economics, incentives, और trends
- कई टिप्पणीकार दावा करते हैं कि clouds hardware advances (NVMe, newer CPUs) से होने वाले अधिकांश gains को pricing और throttling के ज़रिए अपने पास रख लेते हैं; ग्राहकों के लिए performance per dollar धीरे-धीरे सुधरता है।
- ऑन‑prem/hybrid की ओर एक छोटा लेकिन बढ़ता हुआ रुझान महसूस किया जा रहा है, खासकर बड़े, data‑intensive AI और analytics workloads के लिए।
- कुछ लोग अनुमान लगाते हैं कि सस्ते local SSDs/GPUs और privacy चिंताएँ अधिक functionality को thick clients की ओर वापस धकेल सकती हैं, हालांकि mobile constraints अभी भी एक limitation बने हुए हैं।