<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Storage | The .NET Blog</title><link>https://thedotnetblog.com/hi/tags/storage/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>hi</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Wed, 15 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/hi/tags/storage/index.xml" rel="self" type="application/rss+xml"/><item><title>Azure Smart Tier GA हुआ — Lifecycle Rules के बिना स्वचालित Blob Storage लागत अनुकूलन</title><link>https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/azure-smart-tier-blob-storage-ga/</link><pubDate>Wed, 15 Apr 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/azure-smart-tier-blob-storage-ga/</guid><description>Azure Blob Storage smart tier अब generally available है, जो वास्तविक access patterns के आधार पर objects को hot, cool, और cold tiers के बीच स्वचालित रूप से ले जाता है — कोई lifecycle rules ज़रूरी नहीं।</description><content:encoded>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, &lt;a href="https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/azure-smart-tier-blob-storage-ga/"&gt;यहाँ क्लिक करें&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;अगर आपने कभी Azure Blob Storage lifecycle policies tune करने में समय बिताया है और फिर देखा है कि access patterns बदलने पर वे ध्वस्त हो जाती हैं, तो यह खबर आपके लिए है। Microsoft ने Azure Blob और Data Lake Storage के लिए &lt;a href="https://azure.microsoft.com/en-us/blog/optimize-object-storage-costs-automatically-with-smart-tier-now-generally-available/"&gt;smart tier की general availability की घोषणा की&lt;/a&gt; — यह एक fully managed tiering capability है जो वास्तविक उपयोग के आधार पर objects को hot, cool, और cold tiers के बीच स्वचालित रूप से ले जाती है।&lt;/p&gt;
&lt;h2 id="smart-tier-वसतव-म-कय-करत-ह"&gt;Smart tier वास्तव में क्या करता है&lt;/h2&gt;
&lt;p&gt;अवधारणा सीधी है: smart tier आपके storage account में हर object के last access time का लगातार मूल्यांकन करता है। बार-बार access होने वाला data hot में रहता है, 30 दिनों बाद निष्क्रिय data cool में चला जाता है, और फिर 60 दिनों बाद cold में। जब data फिर से access होता है, तो वो तुरंत hot पर वापस आ जाता है। चक्र फिर से शुरू होता है।&lt;/p&gt;
&lt;p&gt;Configure करने के लिए कोई lifecycle rules नहीं। Access pattern predictions नहीं। कोई manual tuning नहीं।&lt;/p&gt;
&lt;p&gt;Preview के दौरान, Microsoft ने बताया कि &lt;strong&gt;smart-tier-managed capacity का 50% से अधिक हिस्सा actual access patterns के आधार पर स्वचालित रूप से cooler tiers में चला गया&lt;/strong&gt;। बड़े storage accounts के लिए यह एक सार्थक cost reduction है।&lt;/p&gt;
&lt;h2 id="net-developers-क-लए-यह-कय-मयन-रखत-ह"&gt;.NET developers के लिए यह क्यों मायने रखता है&lt;/h2&gt;
&lt;p&gt;अगर आप ऐसी applications बना रहे हैं जो logs, telemetry, analytics data, या किसी भी तरह का growing data estate generate करती हैं — और सच में, कौन नहीं बना रहा — तो storage costs तेज़ी से बढ़ती हैं। पारंपरिक approach थी lifecycle management policies लिखना, उन्हें test करना, और फिर जब app के access patterns बदलें तो फिर से tune करना। Smart tier उस पूरे workflow को हटा देता है।&lt;/p&gt;
&lt;p&gt;कुछ व्यावहारिक scenarios जहाँ यह मदद करता है:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Application telemetry और logs&lt;/strong&gt; — debugging के समय hot, कुछ हफ्तों बाद शायद ही access&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Data pipelines और ETL outputs&lt;/strong&gt; — processing के दौरान भारी access, फिर mostly cold&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;User-generated content&lt;/strong&gt; — recent uploads hot हैं, पुराना content धीरे-धीरे ठंडा होता है&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Backup और archival data&lt;/strong&gt; — compliance के लिए कभी-कभी access, mostly idle&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="इस-setup-करन"&gt;इसे Setup करना&lt;/h2&gt;
&lt;p&gt;Smart tier enable करना एक बार का configuration है:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;नए accounts&lt;/strong&gt;: storage account creation के दौरान smart tier को default access tier के रूप में चुनें (zonal redundancy ज़रूरी है)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;मौजूदा accounts&lt;/strong&gt;: अपने current default से blob access tier को smart tier में switch करें&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;128 KiB से छोटे objects hot में रहते हैं और monitoring fee नहीं लगती। बाकी सब के लिए, आप standard hot/cool/cold capacity rates pay करते हैं बिना tier transition charges, early deletion fees, या data retrieval costs के। Per object एक monthly monitoring fee orchestration को cover करती है।&lt;/p&gt;
&lt;h2 id="ज-tradeoff-जनन-चहए"&gt;जो tradeoff जाननी चाहिए&lt;/h2&gt;
&lt;p&gt;Smart tier के tiering rules static हैं (30 दिन → cool, 90 दिन → cold)। अगर आपको custom thresholds चाहिए — जैसे किसी specific workload के लिए 7 दिनों में cool पर जाना — तो lifecycle rules अभी भी सही तरीका है। और दोनों को mix न करें: smart-tier-managed objects पर lifecycle rules use करने से बचें, क्योंकि वे conflict कर सकते हैं।&lt;/p&gt;
&lt;h2 id="नषकरष"&gt;निष्कर्ष&lt;/h2&gt;
&lt;p&gt;यह क्रांतिकारी नहीं है, लेकिन यह एक real operational सिरदर्द हल करता है। अगर आप बढ़ते blob storage accounts manage करते हैं और lifecycle policies maintain करते-करते थक गए हैं, तो &lt;a href="https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-smart"&gt;smart tier enable करें&lt;/a&gt; और Azure को यह handle करने दें। यह आज लगभग सभी zonal public cloud regions में उपलब्ध है।&lt;/p&gt;</content:encoded></item></channel></rss>