SQL Materialized View: क्वेरी प्रदर्शन में सुधार

समझें कि SQL डेटाबेस में materialized views क्वेरी प्रदर्शन को कैसे बेहतर बनाते हैं। विभिन्न डेटाबेस में इनकी सीमाएँ और सर्वोत्तम प्रथाएँ जानें।

अपडेट किया गया 25 सित॰ 2026 · 9 मि॰ पढ़ें

AI के साथ खोजें

ChatGPT Claude Perplexity

Materialized views SQL डेटाबेस की एक शक्तिशाली विशेषता हैं, जो किसी क्वेरी के परिणामों को डिस्क पर भौतिक रूप से संग्रहीत करके क्वेरी प्रदर्शन को अनुकूलित करती हैं, जिससे पुनर्गणना कम होती है और प्रदर्शन तेज होता है। यह उन्हें विशेष रूप से उन जटिल, संसाधन-गहन क्वेरियों के लिए उपयोगी बनाता है जिनमें joins, aggregations, और बड़े डेटासेट शामिल होते हैं।

शुरू करने के लिए, मैं DataCamp का Introduction to SQL कोर्स और SQL Fundamentals स्किल ट्रैक करने की सलाह देता/देती हूँ ताकि आप SQL की बुनियादें और क्वेरियों से डेटा निकालना सीख सकें। SQL Basics Cheat Sheet डेटा को फ़िल्टर और एग्रीगेट करने के लिए सामान्य SQL फ़ंक्शंस का एक उपयोगी मार्गदर्शक होगा।

SQL Materialized Views क्या हैं?

Materialized views डेटाबेस ऑब्जेक्ट का एक विशेष प्रकार हैं जो नियमित views की तरह हर बार ऑन-द-फ्लाई गणना करने के बजाय, किसी क्वेरी के परिणामों को भौतिक रूप से संग्रहीत करते हैं। जहां एक सामान्य SQL view एक सेव्ड SQL क्वेरी होती है जो हर बार एक्सेस होने पर अपने परिणाम गतिशील रूप से बनाती है, वहीं materialized view पहले से ही डेटा को गणना करके तालिका-जैसी संरचना में संग्रहीत कर देता/देती है।

परिणाम सेट को डिस्क पर संग्रहीत करने से, materialized views डेटाबेस पर लोड को काफी कम कर सकते हैं, क्वेरी प्रदर्शन में सुधार कर सकते हैं, और संगणनात्मक रूप से गहन कार्यों के प्रसंस्करण को सरल बना सकते हैं।

SQL में Materialized View बनाना

Materialized view बनाने की प्रक्रिया में CREATE MATERIALIZED VIEW सिंटैक्स का उपयोग होता है, जो विभिन्न SQL डेटाबेस में थोड़ा-थोड़ा भिन्न होता है। नीचे SQL Server, PostgreSQL, और Oracle में materialized views कैसे बनाते हैं, यह दिखाया गया है।

PostgreSQL में materialized view

PostgreSQL में आप निम्न सिंटैक्स का उपयोग करके materialized view बना सकते हैं। यह उदाहरण sales_summary नाम का एक materialized view बनाता है, जो प्रत्येक प्रोडक्ट की कुल मात्रा और राजस्व का समेकन करता है।

-- Create a materialized view to summarize sales data
CREATE MATERIALIZED VIEW sales_summary AS
SELECT product_id, 
       SUM(quantity) AS total_quantity, 
       SUM(price * quantity) AS total_revenue
FROM sales
GROUP BY product_id;

SQL Server में materialized view

SQL Server में materialized views को "Indexed Views" कहा जाता है। Indexed view बनाने के लिए आधार तालिकाओं को विशेष आवश्यकताएँ पूरी करनी होती हैं, जैसे WITH SCHEMABINDING विकल्प को सक्षम करना।

WITH SCHEMABINDING विकल्प यह सुनिश्चित करता है कि indexed view के अस्तित्व में रहते हुए स्कीमा बदला नहीं जा सकता। View को materialize करने के लिए एक unique clustered index बनाना आवश्यक है।

-- Create an indexed view with schema binding to summarize sales data
CREATE VIEW sales_summary
WITH SCHEMABINDING 
AS
SELECT product_id, 
       COUNT_BIG(*) AS record_count,
       SUM(ISNULL(quantity, 0)) AS total_quantity,
       SUM(ISNULL(price, 0) * ISNULL(quantity, 0)) AS total_revenue
FROM sales
GROUP BY product_id;
GO
-- Create a unique clustered index to materialize the view
CREATE UNIQUE CLUSTERED INDEX IX_sales_summary 
ON sales_summary (product_id);
GO

यदि आप SQL Server के बारे में और सीखना चाहते हैं, तो हमारे SQL Server Fundamentals स्किल ट्रैक को देखें, ताकि आप डेटा विश्लेषण के लिए विभिन्न SQL कौशलों से परिचित हो सकें।

Oracle में materialized view

Oracle में materialized view बनाने का सिंटैक्स PostgreSQL डेटाबेस के समान है। हम refresh विकल्प भी निर्दिष्ट कर सकते हैं, जैसे ON DEMAND या ON COMMIT।

-- Create a materialized view to summarize sales data
CREATE MATERIALIZED VIEW sales_summary
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
AS
SELECT product_id, SUM(quantity) AS total_quantity, SUM(price * quantity) AS total_revenue
FROM sales
GROUP BY product_id;

वितरित डेटाबेस में materialized view

Materialized views, Azure Synapse या Amazon Redshift जैसे वितरित डेटा वेयरहाउस समर्थित डेटाबेस के लिए बेहतर प्रदर्शन हेतु वितरण विधियाँ भी निर्दिष्ट कर सकते हैं।

Amazon Redshift के लिए हैश वितरण

नीचे दी गई क्वेरी sales_summary नाम का materialized view बनाती है, जो product_id के आधार पर कुल मात्रा और राजस्व का समेकन करता है। DISTSTYLE KEY और DISTKEY(product_id) विकल्प यह सुनिश्चित करते हैं कि डेटा product_id के आधार पर नोड्स में वितरित हो, जिससे उन क्वेरियों का प्रदर्शन बेहतर होता है जो इस कॉलम पर join करती हैं।

-- Create a materialized view with key-based distribution for efficient joins
CREATE MATERIALIZED VIEW sales_summary
DISTSTYLE KEY
DISTKEY(product_id)
AS
SELECT product_id, 
       SUM(quantity) AS total_quantity, 
       SUM(price * quantity) AS total_revenue
FROM sales
GROUP BY product_id;

Azure Synapse के लिए राउंड-रॉबिन वितरण

यह क्वेरी sales_summary नाम का materialized view बनाती है, जो product_id के आधार पर कुल मात्रा और राजस्व का समेकन करता है। ROUND_ROBIN वितरण डेटा को नोड्स में समान रूप से फैलाता है, जो उन परिदृश्यों में उपयोगी है जहाँ joins पर भारी निर्भरता नहीं होती।

-- Create a materialized view with round-robin distribution for balanced data storage
CREATE MATERIALIZED VIEW sales_summary
WITH (DISTRIBUTION = ROUND_ROBIN)
AS
SELECT product_id, 
       SUM(quantity) AS total_quantity, 
       SUM(price * quantity) AS total_revenue
FROM sales
GROUP BY product_id;

SQL में Materialized View को Refresh करना

Materialized views में डेटा को आधार तालिकाओं के अनुरूप अपडेट रहने के लिए refresh किया जा सकता है। Refresh विधि का चुनाव संबंधित डेटाबेस की व्यावसायिक आवश्यकताओं और प्रदर्शन संबंधी विचारों पर निर्भर करता है। आइए materialized views की निम्न डेटा refresh विधियों पर नज़र डालते हैं।

Manual refresh

Manual refresh में, materialized view केवल तब refresh होता है जब उपयोगकर्ता स्पष्ट रूप से अनुरोध करता/करती है। यह तरीका डेटा कब अपडेट हो, इस पर सर्वाधिक नियंत्रण देता है, और उन स्थितियों के लिए उपयुक्त है जहाँ डेटा कम बदलता है या अपडेट ऑफ-पीक घंटों में किए जाते हैं।

निम्न क्वेरी PostgreSQL में manual refresh विधि दिखाती है।

REFRESH MATERIALIZED VIEW sales_summary;

Periodic refresh

Refresh अवधि के दौरान निर्दिष्ट अंतराल पर materialized view अपने आप refresh होता रहता है, जिससे उपयोगकर्ता के हस्तक्षेप के बिना डेटा अद्यतन बना रहता है। यह विधि समय-संवेदी अनुप्रयोगों के लिए उपयोगी है जहाँ डेटा को तुलनात्मक रूप से वर्तमान रखना आवश्यक होता है।

नीचे का उदाहरण दर्शाता है कि Oracle में किस प्रकार CREATE MATERIALIZED VIEW स्टेटमेंट में सीधे refresh schedules परिभाषित करके periodic refresh शामिल किए जा सकते हैं। यहाँ refresh समय को प्रति घंटा अंतराल पर सेट किया गया है।

-- Create a materialized view to aggregate sales data
-- Set to refresh completely every hour
CREATE MATERIALIZED VIEW sales_summary
REFRESH COMPLETE START WITH (SYSDATE) NEXT (SYSDATE + 1/24)
AS
SELECT product_id, 
       SUM(quantity) AS total_quantity, 
       SUM(price * quantity) AS total_revenue
FROM sales
GROUP BY product_id;

On-demand refresh

On-demand refresh तब होता है जब भी आधार डेटा बदलता है, आमतौर पर ट्रिगर मैकेनिज्म के माध्यम से। यह सुनिश्चित करता है कि materialized view में हमेशा अद्यतन डेटा हो। उदाहरण के लिए, PostgreSQL में, आधार तालिका में परिवर्तन होने पर view को refresh करने के लिए ट्रिगर्स सेट किए जा सकते हैं।

पूर्ण बनाम क्रमिक refresh

Materialized views में आप डेटा को पूर्ण (full) या क्रमिक (incremental) refresh के माध्यम से अपडेट कर सकते हैं। नीचे दी गई तालिका इन दोनों विधियों और उनके उपयोग-मामलों का सार प्रस्तुत करती है।

Refresh प्रकार	विवरण	फायदे	कमियाँ
Full Refresh	पूरे डेटासेट को फिर से लोड करता है, view में मौजूद सभी डेटा को प्रतिस्थापित करता है	- लागू करना सरल - पूरे view का पुनर्निर्माण	- बड़े डेटासेट के लिए संसाधन-गहन - अधिक समय लेने वाले refresh
Incremental Refresh	केवल बदले हुए भागों को अपडेट करता है	- अधिक कुशल, केवल संशोधित डेटा को प्रोसेस करता है - बार-बार परिवर्तन वाले बड़े डेटासेट के लिए उपयुक्त	- अतिरिक्त सेटअप की आवश्यकता (जैसे, परिवर्तनों को ट्रैक करने के लिए लॉग्स) - सभी क्वेरियों के लिए हमेशा समर्थित नहीं

Materialized Views के लिए सर्वश्रेष्ठ व्यवहार

Materialized views का उपयोग करते समय, इष्टतम उपयोग के लिए निम्न बातों पर विचार करना महत्वपूर्ण है।

Materialize करने के लिए सही क्वेरियों का चयन: जटिल, संसाधन-गहन क्वेरियों जैसे joins, aggregations, और subqueries को materialize करें। ऐसी क्वेरियों को पूर्व-गणित परिणामों का लाभ मिलता है, जिससे डेटाबेस पर लोड कम होता है।
डेटा की नवीनता और प्रदर्शन के बीच संतुलन: अपने उपयोग-मामले के अनुसार उपयुक्त refresh रणनीति चुनें, जैसे manual, periodic, या on-demand refresh। संगणनात्मक लोड कम करने के लिए जहाँ संभव हो incremental refresh का उपयोग करें, और refresh अंतराल निर्धारित करने हेतु डेटा परिवर्तन की आवृत्ति पर नज़र रखें।
Query-Heavy वर्कलोड के अनुकूलन हेतु materialized views का उपयोग: BI रिपोर्ट्स और डैशबोर्ड्स के लिए materialized views का लाभ उठाएँ जहाँ त्वरित प्रतिक्रिया समय आवश्यक है। तेज़ फ़िल्टरिंग और सॉर्टिंग के लिए materialized views में उपयोग होने वाले कॉलम पर इंडेक्स भी बना सकते हैं।

विभिन्न डेटाबेस सिस्टम्स में Materialized Views

जैसा कि आपने देखा, विभिन्न डेटाबेस सिस्टम्स materialized views के लिए अलग-अलग समर्थन प्रदान करते हैं। नीचे दी गई तालिका इन डेटाबेस में materialized views की विशिष्ट विशेषताओं और सीमाओं का सार देती है।

डेटाबेस सिस्टम	Refresh विधियाँ	Incremental Refresh	स्वचालित Refresh	विशेषताएँ/सीमाएँ
PostgreSQL	Manual (REFRESH MATERIALIZED VIEW)	नहीं	नहीं	नेटिव incremental refresh का अभाव। Manual scheduling आवश्यक।
SQL Server	स्वचालित (Indexed Views)	हाँ (Automatic Sync)	हाँ	`WITH SCHEMABINDING` आवश्यक। सीमित क्वेरी समर्थन।
Oracle	Manual, On Commit, Scheduled	हाँ (Fast Refresh)	हाँ	Fast refresh, partitioning, और parallelism को सपोर्ट करता है। View logs आवश्यक।
Amazon Redshift	Manual, Scheduled	हाँ	हाँ	हैश या राउंड-रॉबिन वितरण के साथ वितरित डेटा को सपोर्ट करता है।
MySQL	मूल रूप से समर्थित नहीं	नहीं	नहीं	Workarounds आवश्यक (जैसे, अस्थायी तालिकाएँ, थर्ड-पार्टी टूल्स)।
Azure Synapse	Manual, Scheduled	हाँ	हाँ	अनुकूलन के लिए विभिन्न वितरण रणनीतियों की अनुमति देता है।

यदि आप SQL Server को अपना पसंदीदा डेटाबेस उपयोग करते हैं, तो DataCamp का Introduction to SQL Server कोर्स लें ताकि आप Microsoft SQL Server की बुनियादें डेटा विश्लेषण के लिए सीख सकें। साथ ही हमारा SQL Server Developer करियर ट्रैक भी देखें ताकि आप SQL Server में क्वेरियों को अनुकूलित करना और समस्याओं का निदान करना समझ सकें।

अतिरिक्त विचारणीय बातें

जहाँ SQL materialized views क्वेरी अनुकूलन के लिए उपयोगी हैं, वहीं इनके साथ कुछ चुनौतियाँ और सीमाएँ भी आती हैं। नीचे materialized views की सामान्य समस्याएँ और उन्हें संबोधित करने के तरीके दिए गए हैं।

स्टोरेज ओवरहेड: Materialized views क्वेरी परिणामों को डिस्क पर भौतिक रूप से संग्रहीत करते हैं, जिससे स्टोरेज आवश्यकताएँ बढ़ती हैं। अनावश्यक स्टोरेज उपयोग से बचने के लिए केवल संसाधन-गहन क्वेरियों के लिए views को materialize करें और बड़े डेटासेट के लिए materialized views का partition करें।
अपडेट लागत और refresh ओवरहेड: Materialized views को आधार तालिकाओं के साथ सिंक में रखना संसाधन-गहन हो सकता है, खासकर जब बार-बार अपडेट या जटिल गणनाएँ आवश्यक हों। Refresh ओवरहेड से बचने के लिए जहाँ समर्थित हो वहाँ incremental refresh का उपयोग करें या कम डेटाबेस उपयोग के समय उपयुक्त refresh अंतराल निर्धारित करें।
डेटा स्थिरता और समकालिकरण: यदि आधार डेटा बार-बार बदलता है, तो materialized views पुराने हो सकते हैं, जिससे stale डेटा की समस्या हो सकती है। इससे बचने के लिए उपयुक्त refresh रणनीति चुनें और आवश्यकतानुसार रणनीति समायोजित करने हेतु डेटा परिवर्तनों की निगरानी करें।
रखरखाव ओवरहेड: Materialized views को सतत रखरखाव की आवश्यकता होती है, जैसे उपयुक्त refresh शेड्यूल सेट करना, स्टोरेज उपयोग की निगरानी करना, और आधार तालिकाओं पर निर्भरताओं को ट्रैक करना। इस चुनौती से निपटने के लिए हमेशा स्वचालित refresh शेड्यूल्स का उपयोग करें, सिस्टम प्रदर्शन की निगरानी करें, और विफल refresh के लिए अलर्ट सेट करें।

निष्कर्ष

Materialized views SQL डेटाबेस में क्वेरी प्रदर्शन को अनुकूलित करने के लिए उपयोगी होते हैं। ये क्वेरी के परिणामों को डिस्क पर भौतिक रूप से संग्रहीत करते हैं, जिससे पुनर्गणना कम होकर क्वेरी का प्रदर्शन तेज होता है। यह सुविधा materialized views को उन जटिल, संसाधन-गहन क्वेरियों को संभालने के लिए उपयोगी बनाती है जिनमें joins, aggregations, और बड़े डेटासेट शामिल होते हैं। विभिन्न डेटाबेस में materialized views को कैसे लागू किया जाए, यह समझना आपकी क्वेरी और डेटाबेस अनुकूलन कौशल को बेहतर करेगा।

यदि आप अपनी SQL कौशल को आगे बढ़ाना चाहते हैं, तो DataCamp का Associate Data Analyst in SQL करियर ट्रैक आज़माएँ ताकि आप एक दक्ष डेटा विश्लेषक बन सकें। Reporting in SQL कोर्स भी आपको प्रभावी डेटा प्रस्तुति के लिए जटिल रिपोर्ट्स और डैशबोर्ड बनाने में दक्ष बनने में मदद करेगा। अंत में, SQL Associate Certification अवश्य प्राप्त करें ताकि आप व्यावसायिक समस्याओं को हल करने में SQL के अपने कौशल को प्रदर्शित कर सकें और अन्य पेशेवरों के बीच अलग दिखें।

Author

Allan Ouko

डेटा एनालिटिक्स, बिज़नेस इंटेलिजेंस और डेटा साइंस में व्यावहारिक अनुभव रखने वाला डेटा साइंस तकनीकी लेखक। मैं SQL, Python, Power BI, Databricks और डेटा इंजीनियरिंग पर व्यावहारिक, उद्योग-केंद्रित सामग्री लिखता/लिखती हूँ, जो वास्तविक दुनिया की एनालिटिक्स कार्य से जुड़ी होती है। मेरी लेखनी तकनीकी गहराई और व्यावसायिक प्रभाव के बीच पुल का काम करती है, जिससे पेशेवरों को डेटा को आत्मविश्वासपूर्ण निर्णयों में बदलने में मदद मिलती है.