4 कॉलम में दुनिया भर में कॉलम भाग (1 भाग)

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

उदाहरणों में, मैं 52,608,000 रिकॉर्ड वाले डेटासेट का उपयोग करूंगा।

कठिन विश्लेषणात्मक आरक्षित न होने के उदाहरण का उपयोग करते हुए, मैं यह प्रदर्शित करूंगा कि एक कमजोर कंप्यूटर को बहुत प्रयास के बिना "सभ्य" डेटा का विश्लेषण करने के लिए एक अच्छे उपकरण में बदल दिया जा सकता है।

जटिल प्रयोगों की स्थापना नहीं करने के बाद, हम देखेंगे कि एक नियमित तालिका विश्लेषणात्मक प्रश्नों के लिए उपयुक्त स्रोत नहीं है।

यदि पाठक संक्षिप्त रूप से OLTP और OLAP को आसानी से समझ सकता है, तो यह सीधे Columnstore सेक्शन में जाने का अर्थ बना सकता है

डेटा के साथ काम करने के लिए दो दृष्टिकोण

यहाँ मैं संक्षिप्त हूँ, क्योंकि इंटरनेट पर इस विषय पर पर्याप्त से अधिक जानकारी है।

इसलिए, उच्चतम स्तर पर, डेटा के साथ काम करने के लिए केवल दो दृष्टिकोण हैं: OLTP और OLAP।

OLTP - तुरंत लेनदेन प्रसंस्करण के रूप में अनुवादित किया जा सकता है। वास्तव में, हम कम लेनदेन के ऑनलाइन प्रसंस्करण के बारे में बात कर रहे हैं जो कि कम मात्रा में डेटा के साथ काम करते हैं। उदाहरण के लिए, किसी ऑर्डर को रिकॉर्ड करना, अपडेट करना या हटाना। अधिकांश मामलों में, एक ऑर्डर बहुत कम मात्रा में डेटा है, जिसके प्रसंस्करण के दौरान आप आधुनिक आरडीबीएमएस द्वारा लगाए गए लंबे ताले से डर नहीं सकते।

OLAP - एक समय में बड़ी संख्या में लेनदेन के विश्लेषणात्मक प्रसंस्करण के रूप में अनुवादित किया जा सकता है। कोई भी रिपोर्ट इस विशेष दृष्टिकोण का उपयोग करती है, क्योंकि अधिकांश मामलों में, रिपोर्ट कुछ वर्गों के लिए सारांश, कुल आंकड़े का उत्पादन करती है।

प्रत्येक दृष्टिकोण की अपनी तकनीक है। उदाहरण के लिए, OLTP के लिए यह PostgreSQL है, और OLAP के लिए यह Microsoft SQL सर्वर विश्लेषण सेवाएँ है। जबकि PostgresSQL तालिकाओं में डेटा संग्रहीत करने के लिए एक प्रसिद्ध प्रारूप का उपयोग करता है, OLAP के लिए कई अलग-अलग स्वरूपों का आविष्कार किया गया था। ये बहुआयामी टेबल हैं, की-वैल्यू पेयर और मेरे पसंदीदा कॉलमस्टोर से भरी हुई बाल्टी। नीचे और अधिक विस्तार से उत्तरार्द्ध के बारे में।

दो दृष्टिकोणों की आवश्यकता क्यों है?

यह देखा गया कि कोई भी डेटा वेयरहाउस जल्द या बाद में दो प्रकार के लोड का सामना करता है: लगातार पढ़ना (लिखना और अपडेट करना, निश्चित रूप से, बहुत कम मात्रा में डेटा) और दुर्लभ रीडिंग, लेकिन बहुत बड़ी मात्रा में डेटा। वास्तव में, यह एक गतिविधि है, उदाहरण के लिए, बॉक्स ऑफिस और सिर की। कैश डेस्क, पूरे दिन काम करते हुए, स्टोरेज को डेटा की छोटी मात्रा के साथ भरता है, जबकि दिन के अंत में संचित की मात्रा, यदि व्यवसाय अच्छी तरह से चल रहा है, प्रभावशाली आकार तक पहुंचता है। बदले में, दिन के अंत में प्रबंधक जानना चाहता है कि बॉक्स ऑफिस प्रति दिन कितना पैसा कमाता है।

तो, ओएलटीपी में हमारे पास टेबल और इंडेक्स हैं। ये दो उपकरण सभी विवरणों के साथ बॉक्स ऑफिस गतिविधि की रिकॉर्डिंग के लिए महान हैं। अनुक्रमित पहले से रिकॉर्ड किए गए ऑर्डर के लिए त्वरित खोज प्रदान करते हैं, इसलिए ऑर्डर बदलना आसान है। लेकिन नेता की जरूरतों को पूरा करने के लिए, हमें प्रति दिन संचित डेटा की पूरी मात्रा पर विचार करने की आवश्यकता है। इसके अलावा, एक नियम के रूप में, प्रबंधक को सभी आदेशों के सभी विवरणों की आवश्यकता नहीं है। वह वास्तव में क्या जानना चाहता है कि बॉक्स ऑफिस पर सामान्य रूप से कितना पैसा है। इससे कोई फर्क नहीं पड़ता कि लंच ब्रेक होने पर टिकट ऑफिस कहां था, इसके लिए किसने काम किया आदि। ओएलएपी तब मौजूद है, ताकि कम समय की अवधि में प्रणाली इस सवाल का जवाब दे सके - प्रत्येक आदेश के क्रमिक पढ़ने के बिना और उसके सभी विवरणों के बिना कंपनी पूरी कमाई में कितनी है। क्या OLAP समान तालिकाओं और अनुक्रमितों का उपयोग OLTP के रूप में कर सकता है? जवाब नहीं है, कम से कम यह नहीं होना चाहिए। सबसे पहले, क्योंकि OLAP को तालिकाओं में दर्ज सभी विवरणों की आवश्यकता नहीं है। दो-आयामी तालिकाओं के अलावा अन्य स्वरूपों में डेटा संग्रहीत करके इस समस्या को हल किया जाता है। दूसरे, विश्लेषण की गई जानकारी अक्सर अलग-अलग तालिकाओं में बिखरी रहती है, जो उनके कई संघों को जोड़ती है, जिसमें स्व-शामिल प्रकार के संघ शामिल हैं। इस समस्या को हल करने के लिए, एक नियम के रूप में, वे एक विशेष डेटाबेस स्कीमा विकसित करते हैं। यह योजना ओएलएपी लोड के लिए अनुकूलित है, साथ ही ओएलटीपी लोड के लिए सामान्य सामान्यीकृत योजना है।

जब OLAP एक OLTP योजना का उपयोग करता है तो क्या होता है

वास्तव में, मैंने इस खंड को पेश किया ताकि यह लेख स्पष्ट रूप से ऐसी सामग्री के प्रारूप के लिए मेरी अपनी आवश्यकताओं को पूरा करे, अर्थात्। समस्या, समाधान, निष्कर्ष।

हम डेटा विश्लेषण के लिए OLTP योजनाओं का उपयोग करने के कई नुकसानों को सूचीबद्ध करते हैं।

• बहुत सारे सूचकांक।
  
  अक्सर, आपको रिपोर्ट का समर्थन करने के लिए विशेष सूचकांक बनाना होगा। ये इंडेक्स एक OLAP डेटा स्टोरेज स्कीम को लागू करते हैं। आवेदन के ओएलटीपी भाग द्वारा उनका उपयोग नहीं किया जाता है, जबकि उस पर एक भार बढ़ाते हुए, निरंतर समर्थन की आवश्यकता होती है और डिस्क स्थान लेती है।
• डेटा रीड की मात्रा आवश्यक से अधिक है।
• एक स्पष्ट डेटा योजना का अभाव।
  
  तथ्य यह है कि अक्सर एक ही रूप में रिपोर्ट द्वारा प्रस्तुत जानकारी अलग-अलग तालिकाओं में फैल जाती है। इस तरह की जानकारी के लिए मक्खी पर निरंतर परिवर्तन की आवश्यकता होती है। सबसे सरल उदाहरण राजस्व की राशि है, जिसमें नकद और गैर-नकद धन शामिल हैं। एक और महत्वपूर्ण उदाहरण डेटा पदानुक्रम है। क्योंकि अनुप्रयोग विकास प्रगतिशील है और यह हमेशा ज्ञात नहीं होता है कि भविष्य में क्या आवश्यकता होगी, अर्थ में समान पदानुक्रम को विभिन्न तालिकाओं में संग्रहीत किया जा सकता है। और जब ओएलएपी में ऑन-द-फ्लाई अधिग्रहण का सक्रिय रूप से उपयोग किया जाता है, तो ये थोड़ी अलग चीजें हैं।
• अत्यधिक क्वेरी जटिलता।
  
  क्योंकि एक ओएलटीपी योजना एक ओएलएपी से भिन्न होती है। दृढ़ता से संबंधित सॉफ़्टवेयर परत की आवश्यकता होती है जो ओएलटीपी डेटा योजना को सही रूप में लाती है।
• समर्थन, डिबगिंग और विकास की जटिलता।
  
  सामान्य तौर पर, हम यह कह सकते हैं कि कोड आधार जितना जटिल होगा, स्वस्थ अवस्था में उसे बनाए रखना उतना ही कठिन होगा। यह एक स्वयंसिद्ध है।
• परीक्षण कवरेज की जटिलता।
  
  सभी परीक्षण लिपियों से भरे डेटाबेस को कैसे प्राप्त किया जाए, इस पर विचार-विमर्श के कारण बहुत सारी प्रतियां तोड़ दी गईं, लेकिन यह कहना बेहतर होगा कि एक सरल डेटा योजना के परीक्षण के साथ कवर करने का कार्य कई बार सरल हो जाता है।
• अंतहीन प्रदर्शन डिबगिंग।
  
  एक उच्च संभावना है कि उपयोगकर्ता डेटाबेस सर्वर के लिए "भारी" एक रिपोर्ट का आदेश देगा। समय के साथ यह संभावना बढ़ जाती है। यह ध्यान दिया जाना चाहिए कि OLAP भी इस समस्या से ग्रस्त है, लेकिन OLTP के विपरीत, इस मामले में OLAP संसाधन बहुत अधिक है।

Columnstore

यह आलेख कॉलमस्टोर संग्रहण प्रारूप पर केंद्रित होगा, लेकिन निम्न-स्तरीय विवरण के बिना। ऊपर वर्णित अन्य प्रारूप भी ध्यान देने योग्य हैं, लेकिन यह एक अन्य लेख के लिए एक विषय है।

दरअसल, कॉलमस्टोर प्रारूप 30 वर्षों के लिए जाना जाता है। लेकिन इसे हाल ही में आरडीबीएमएस में लागू नहीं किया गया था। कॉलमस्टोर का सार यह है कि डेटा पंक्तियों में नहीं, बल्कि कॉलम में संग्रहीत किया जाता है। यानी एक पृष्ठ पर (सभी ज्ञात 8 Kb) सर्वर केवल एक क्षेत्र का डेटा रिकॉर्ड करता है। और इसलिए बदले में तालिका में प्रत्येक क्षेत्र के साथ। यह आवश्यक है ताकि आपको अतिरिक्त जानकारी न पढ़नी पड़े। आइए एक तालिका की कल्पना करें जिसमें 10 फ़ील्ड हैं और एक क्वेरी जिसमें केवल एक फ़ील्ड है जो कि SELECT स्टेटमेंट में निर्दिष्ट है। यदि यह एक पंक्ति-आधारित प्रारूप में सहेजी गई एक नियमित तालिका थी, तो सर्वर को सभी 10 फ़ील्ड पढ़ने के लिए मजबूर किया जाएगा, लेकिन एक ही समय में एक वापस आ जाएगी। यह पता चलेगा कि सर्वर ने आवश्यक जानकारी की तुलना में 9 गुना अधिक जानकारी पढ़ी। स्तंभकार पूरी तरह से इस समस्या को हल करता है, क्योंकि भंडारण प्रारूप आपको केवल एक ऑर्डर किए गए फ़ील्ड को पढ़ने की अनुमति देता है। यह सब इसलिए होता है क्योंकि RDBMS में स्टोरेज यूनिट एक पेज है। यानी सर्वर हमेशा लिखता है और कम से कम एक पृष्ठ पढ़ता है। एकमात्र सवाल यह है कि इस पर कितने क्षेत्र मौजूद हैं।

कैसे Columnstore वास्तव में मदद कर सकता है

इसका उत्तर देने के लिए सटीक संख्या होनी चाहिए। चलो उन्हें ले आओ। लेकिन कौन सी संख्या एक सटीक चित्र दे सकती है?

1. डिस्क स्थान की मात्रा।
2. क्वेरी प्रदर्शन।
3. दोष सहिष्णुता।
4. कार्यान्वयन में आसानी।
5. एक डेवलपर को नए ढांचे के साथ काम करने के लिए कौन से नए कौशल होने चाहिए।

डिस्क स्थान

आइए एक सरल तालिका बनाएं, इसे डेटा से भरें और जांचें कि यह कितना स्थान लेता है।

create foreign table cstore_table ( trd date, org int, op int, it int, wh int, m1 numeric(32, 2), m2 numeric(32, 2), m3 numeric(32, 2), m4 numeric(32, 2), m5 numeric(32, 2) ) server cstore_server options(compression 'pglz'); 

जैसा कि आपने देखा, मैंने एक बाहरी तालिका बनाई। तथ्य यह है कि PostgreSQL में बिल्ट-इन कॉलमस्टोर सपोर्ट नहीं है। लेकिन PostgreSQL में एक्सटेंशन के लिए एक शक्तिशाली सिस्टम है। उनमें से एक कॉलमस्टोर टेबल बनाना संभव बनाता है। लेख के अंत में लिंक।

• pglz - एक्सटेंशन को बताता है कि पोस्टग्रेएसक्यूएल में अंतर्निहित एल्गोरिथ्म का उपयोग करके डेटा को संपीड़ित किया जाना चाहिए;
• trd - लेनदेन का समय;
• op, it, wh - विश्लेषणात्मक अनुभाग या माप;
• एम 1, एम 2, एम 3, एम 4, एम 5 - संख्यात्मक संकेतक या उपाय;

आइए डेटा की "सभ्य" राशि डालें और देखें कि डिस्क पर कितना स्थान है। उसी समय, हम डालने के प्रदर्शन की जांच करते हैं। क्योंकि मैंने अपने प्रयोगों को एक होम लैपटॉप पर रखा है, मैं डेटा की मात्रा में थोड़ा सा जैविक हूं। इसके अलावा, जो और भी अच्छा है, मैं अतिथि ओएस फेडोरा 30 को चलाने वाले एचडीडी का उपयोग करूंगा। ओएस होस्ट - विंडोज 10 होम संस्करण। प्रोसेसर इंटेल कोर 7. गेस्ट ओएस में 4 जीबी रैम प्राप्त हुई। PostgreSQL संस्करण - x86_64-pc-linux-gnu पर PostgreSQL 10.10, gcc (GCC) द्वारा संकलित 9.1.1 20190503 (Red Hat 9.1.1-1), 64-बिट। मैं रिकॉर्ड ५० ६०। ००० के आंकड़ों के साथ प्रयोग करूंगा।

 explain (analyze) insert into cstore_table select '2010-01-01'::date + make_interval(days => d) as trd , op , org , wh , it , 100 as m1 , 100 as m2 , 100 as m3 , 100 as m4 , 100 as m5 from generate_series(0, 1) as op cross join generate_series(1, 2) as org cross join generate_series(1, 3) as wh cross join generate_series(1, 4000) as it cross join generate_series(0, 1095) as d; 

कार्यान्वयन योजना निम्नानुसार होगी

Cstore_table (लागत = 0.01..24902714242540.01 पंक्तियों = 1000000000000000 चौड़ाई = 150) पर डालें (वास्तविक समय = 119560.456..119560.456 पंक्तियाँ = 0 छोर = 1)
----> नेस्टेड लूप (लागत = 0.01..24902714242540.01 पंक्तियाँ = 1000000000000000 चौड़ाई = 150) (वास्तविक समय = 1.823..22339.976 पंक्तियाँ = 52608000 लूप = 1)
----------> जेनरेट_सेरीज डी पर फंक्शन स्कैन (लागत = 0.00..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 0.151..2.198 पंक्तियाँ = 1096 लूप = 1)
----------> भौतिक (लागत = 0.01..27284555030.01 पंक्तियाँ = 1000000000000 चौड़ाई = 16) (वास्तविक समय = 0.002..3.196 पंक्तियाँ = 48000 लूप = 1096)
----------------> नेस्टेड लूप (लागत = 0.01..17401742530.01 पंक्तियाँ = 1000000000000 चौड़ाई = 16) (वास्तविक समय = 1.461..15.072 पंक्तियाँ = 48000 लूप = 1)
----------------------> इसे जनरेट_सेज़ पर फंक्शन स्कैन (लागत = 0.00..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 1.159..2.007 पंक्तियाँ = 4000 लूप = 1)
----------------------> भौतिक (लागत = 0.01..26312333.01 पंक्तियाँ = १,०००,००० चौड़ाई = १२) (वास्तविक समय = ०.०००. ०.००.११ पंक्तियाँ = १२ लूप = 4000)
----------------------------> नेस्टेड लूप (लागत = 0.01..16429520.01 पंक्तियाँ = 1,000,000,000 चौड़ाई = 12) (वास्तविक समय = 0.257) ..0.485 पंक्तियों = 12 छोरों = 1)
----------------------------------> फंक्शन स्कैन जेनरेट_सरीज व्ह (लागत = 0.00..10.00 पंक्तियों = 1000) पर स्कैन करें चौड़ाई = 4) (वास्तविक समय = 0.046..0.049 पंक्तियों = 3 छोरों = 1)
----------------------------------> भौतिक (लागत = 0.01..28917.01 पंक्तियों = 1,000,000 चौड़ाई = 8) (वास्तविक समय = 0.070..0.139 पंक्तियों = 4 छोरों = 3)
---------------------------------------> नेस्टेड लूप (लागत = 0.01..20010.01 पंक्तियाँ) = 1000000 चौड़ाई = 8) (वास्तविक समय = 0.173..0.366 पंक्तियाँ = 4 छोर = 1)
-------------------------------------------> उत्पन्न करने पर कार्य स्कैन op_series सेशन ( लागत = 0.00..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 0.076..0.079 पंक्तियाँ = 2 छोरें = 1)
---------------------------------------------> जनरेट_सरीज पर फंक्शन स्कैन org (लागत = 0.00..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 0.043..0.047 पंक्तियाँ = 2 छोर = =)
योजना समय: 0.439 एमएस
निष्पादन समय: 119692.051 एमएस

कुल लीड समय - 1.994867517 मिनट

डेटासेट निर्माण समय - 22.339976 सेकंड

सम्मिलन का समय - 1.620341333 मिनट

मैंने PostgreSQL फ़ंक्शंस का उपयोग करके कब्जे वाले डिस्क स्थान का मूल्यांकन करने का प्रबंधन नहीं किया। यकीन नहीं क्यों, लेकिन दिखा रहा है 0. शायद यह बाहरी तालिकाओं के लिए मानक व्यवहार है। इस फ़ाइल प्रबंधक के लिए उपयोग किया जाता है। इसलिए, डिस्क स्थान पर कब्जा की मात्रा 226.2 एमबी है। बहुत या थोड़ा मूल्यांकन करने के लिए, आइए इसकी तुलना एक नियमित तालिका से करें।

 explain (analyze) create table rbstore_table as select '2010-01-01'::date + make_interval(days => d) as trd , op , org , wh , it , 100 as m1 , 100 as m2 , 100 as m3 , 100 as m4 , 100 as m5 from generate_series(0, 1) as op cross join generate_series(1, 2) as org cross join generate_series(1, 3) as wh cross join generate_series(1, 4000) as it cross join generate_series(0, 1095) as d; 

कार्यान्वयन योजना निम्नानुसार होगी

नेस्टेड लूप (लागत = 0.01..22402714242540.01 पंक्तियाँ = 1000000000000000 चौड़ाई = 44) (वास्तविक समय = 0.585..23781.942 पंक्तियाँ = 52608000 लूप = 1)
--- - फंक्शन स्कैन जनरेट_सरीज पर d (लागत = 0.00..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 0.091..2.130 पंक्तियाँ = 1096 छोर = 1)
--- - भौतिक (लागत = 0.01..27284555030.01 पंक्तियाँ = 1000000000000 चौड़ाई = 16) (वास्तविक समय = 0.001..3.574 पंक्तियाँ = 48000 लूप = 1096)
----------> नेस्टेड लूप (लागत = 0.01..17401742530.01 पंक्तियाँ = 1000000000000 चौड़ाई = 16) (वास्तविक समय = 0.489..14.044 पंक्तियाँ = 48000 लूप = 1)
----------------> फंक्शन स्कैन जेनरेट_सेज़ पर स्कैन (लागत = 0.00..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 0.477..1.352 पंक्तियाँ = 4000 लूप = 1 )
----------------> भौतिक (लागत = 0.01..26312333.01 पंक्तियों = 1000000000 चौड़ाई = 12) (वास्तविक समय = 0.000..0.001 पंक्तियों = 12 छोरों = 4000)
----------------------> नेस्टेड लूप (लागत = 0.01..16429520.01 पंक्तियाँ = 1,000,000,000 चौड़ाई = 12) (वास्तविक समय = 0.010..0.019 पंक्तियाँ = 12 छोरों = 1)
----------------------------> फंक्शन स्कैन जेनरेट_सरीज पर लागत (लागत = 0.00..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 0.003..0.003 पंक्तियों = 3 छोरों = 1)
----------------------------> भौतिक (लागत = 0.01..28917.01 पंक्तियों = 1,000,000 चौड़ाई = 8) (वास्तविक समय = 0.002)। .0.004 पंक्तियों = 4 छोरों = 3)
----------------------------------> नेस्टेड लूप (लागत = 0.01..20010.01 पंक्तियाँ = 1,000,000 चौड़ाई = 8 ) (वास्तविक समय = 0.006..0.009 पंक्तियाँ = 4 लूप = 1)
----------------------------------------> जनरेट ऑप्‍शन पर फंक्शन स्‍कैन ऑप (लागत = 0.00) ..10.00 पंक्तियाँ = 1000 चौड़ाई = 4) (वास्तविक समय = 0.002..0.002 पंक्तियाँ = 2 छोरें = 1)
----------------------------------------> फंक्शन स्कैन जनरेट_ऑर्ग ऑर्गन्स (लागत = 0.00) पर स्कैन करें ..10.00 पंक्तियों = 1000 चौड़ाई = 4) (वास्तविक समय = 0.001..0.001 पंक्तियों = 2 छोरों = 2)
योजना समय: 0.569 एमएस
निष्पादन समय: 378883.989 एमएस

इस योजना के क्रियान्वयन पर लगने वाला समय हमें ब्याज नहीं देता है, क्योंकि वास्तविक जीवन में इस तरह के आवेषण को माना नहीं जाता है। हम रुचि रखते हैं कि यह तालिका कितनी डिस्क स्थान पर है। सिस्टम फ़ंक्शंस के अनुरोध को पूरा करने के बाद, मुझे 3.75 जीबी प्राप्त हुआ।

तो, cstore_table - 226 MB, rbstore_table - 3.75 GB। 16.99 बार का अंतर हड़ताली है, लेकिन यह संभावना नहीं है कि उत्पादन में समान अंतर प्राप्त किया जा सकता है, मुख्य रूप से डेटा के वितरण के कारण। एक नियम के रूप में, यह अंतर कम होगा और लगभग 5 गुना होगा।

लेकिन रुको, कोई भी विश्लेषण उद्देश्यों के लिए एक पंक्ति-आधारित प्रारूप में कच्चे डेटा का उपयोग नहीं करता है। उदाहरण के लिए, वे रिपोर्टिंग के लिए अनुक्रमित डेटा का उपयोग करने का प्रयास करते हैं। और क्योंकि "रॉ" डेटा हमेशा रहेगा, आपको सूचकांकों के आकार के साथ आकारों की तुलना करने की आवश्यकता है। कम से कम एक इंडेक्स बनाएं। इसे दिनांक फ़ील्ड और ऑपरेशन के प्रकार पर एक इंडेक्स होने दें - trd + op।

इसलिए, मैंने केवल दो क्षेत्रों को अनुक्रमित किया, और सूचकांक में 1583 एमबी लिया, जो कि cstore_table की तुलना में बहुत अधिक है। लेकिन, एक नियम के रूप में, OLAP लोड के लिए एक से अधिक सूचकांक आवश्यक है। यहां यह ध्यान देना उचित होगा कि cstore_table को अतिरिक्त अनुक्रमण की आवश्यकता नहीं है। यह तालिका किसी भी प्रश्न को कवर करने वाले सूचकांक के रूप में कार्य करती है।

उपरोक्त सभी से, एक सरल निष्कर्ष बनाया जा सकता है - कॉलमस्टोर तालिकाओं का उपयोग करके, आप उपयोग की गई डिस्क स्थान की मात्रा को कम कर सकते हैं।

क्वेरी प्रदर्शन

प्रदर्शन का मूल्यांकन करने के लिए, आइए एक विशेष प्रकार के ऑपरेशन के लिए एक विशेष महीने के लिए सारांश डेटा लौटाते हुए एक क्वेरी चलाएँ।

 explain (analyze, costs, buffers) select sum(m1) from cstore_table where trd = '2011-01-01' and op = 1; 

कार्यान्वयन योजना निम्नानुसार होगी

एग्रीगेट (लागत = 793602.69..793602.70 पंक्तियाँ = 1 चौड़ाई = 32) (वास्तविक समय = 79.708..79.708 पंक्तियाँ = 1 छोर = 1)
- बफ़र्स: साझा हिट = 44226
--- - cstore_table (लागत = 0.00..793544.70 पंक्तियों = 23197 चौड़ाई = 5) पर विदेशी स्कैन (वास्तविक समय = 23.209..76.628 पंक्तियाँ = 24000 लूप = 1)
-------- फ़िल्टर: ((trd = '2011-01-01' :: दिनांक) और (op = 1) 1
-------- फ़िल्टर द्वारा हटाए गए पंक्तियों: 26000
-------- CStore फ़ाइल: / var / lib / pgsql / 10 / data / cstore_fdw / 14028/16417
-------- CStore फ़ाइल का आकार: 120818897
-------- बफर: साझा हिट = 44226
योजना समय: 0.165 एमएस
निष्पादन समय: 79.887 एमएस

और

 explain (analyze, costs, buffers) select sum(m1) from rbstore_table where trd = '2011-01-01' and op = 1; 

कार्यान्वयन योजना निम्नानुसार होगी

सकल (लागत = 40053.80..40053.81 पंक्तियाँ = 1 चौड़ाई = 8) (वास्तविक समय = 389.183..389.183 पंक्तियाँ = 1 छोर = 1)
- बफ़र: साझा पढ़ा = 545
--- - rbstore_table (लागत = 0.56..39996.70 पंक्तियों = 22841 चौड़ाई = 4) पर trd_op_ix का उपयोग करके सूचकांक स्कैन करें (वास्तविक समय = 55.955..385.283 पंक्तियों = 24000 लूप्स - 1)
-------- सूचकांक कंडोम: ((trd = '2011-01-01 00:00:00' :: समय क्षेत्र के बिना टाइमस्टैम्प) और (सेशन = 1))
-------- बफर: साझा पढ़ा = 545
योजना समय: 112.175 मि
निष्पादन समय: 389.219 एमएस

389.219 एमएस बनाम 79.887 एमएस। यहां हम देखते हैं कि कॉलमस्टोर डेटा की अपेक्षाकृत कम मात्रा पर भी, एक तालिका पंक्ति-आधारित तालिका पर एक इंडेक्स की तुलना में काफी तेज है।

आइए अनुरोध को बदलें और पूरे 2011 के लिए इकाई प्राप्त करने का प्रयास करें।

 explain (analyze, costs, buffers) select sum(m1) from cstore_table where trd between '2011-01-01' and '2011-12-31' and op = 1; 

कार्यान्वयन योजना निम्नानुसार होगी

सकल (लागत = 946625.58..946625.59 पंक्तियाँ = 1 चौड़ाई = 32) (वास्तविक समय = 3123.604..3123.604 पंक्तियाँ = 1 छोर = 1)
- बफ़र्स: साझा हिट = 44226
--- - cstore_table (लागत = 0.00..925064.70 पंक्तियों = 8624349 चौड़ाई = 5) पर विदेशी स्कैन (वास्तविक समय = 21.728..2100.665 पंक्तियों = 8760000 छोरों = 1)
-------- फ़िल्टर: ((trd> = '2011-01-01' :: दिनांक) और (trd <= '2011-12-31' :: दिनांक) और (op = 1))
-------- फ़िल्टर द्वारा निकाली गई पंक्तियाँ: 8760000
-------- CStore फ़ाइल: / var / lib / pgsql / 10 / data / cstore_fdw / 14028/16411
-------- CStore फ़ाइल का आकार: 120818897
-------- बफर: साझा हिट = 44226
योजना समय: 0.212 मि
निष्पादन समय: 3123.960 एमएस

और

 explain (analyze, costs, buffers) select sum(m1) from rbstore_table where trd between '2011-01-01' and '2011-12-31' and op = 1; 

कार्यान्वयन योजना निम्नानुसार होगी

अंतिम रूप दें (लागत = 885214.33..885214.34 पंक्तियाँ = 1 चौड़ाई = 8) (वास्तविक समय = 98512.560..98512.560 पंक्तियाँ = 1 छोर = 1)
- बफ़र: साझा हिट = 2565 पढ़ा = 489099
--- - इकट्ठा (लागत = 885214.12..885214.33 पंक्तियाँ = 2 चौड़ाई = 8) (वास्तविक समय = 98427.034..98523.194 पंक्तियाँ = 3 छोर = 1)
-------- श्रमिक नियोजित: २
-------- कार्यकर्ता लॉन्च किए गए: 2
-------- बफ़र्स: साझा हिट = 2565 पढ़ा = 489099
---------> आंशिक सकल (लागत = 884214.12..884214.13 पंक्तियाँ = 1 चौड़ाई = 8) (वास्तविक समय = 97907.608..97907.608 पंक्तियाँ = 1 छोर = 3)
-------------- बफर: साझा हिट = 2565 पढ़ा = 489099
---------------> rbstore_table (लागत = 0.00..875264.00 पंक्तियों = 3580047 चौड़ाई = 4) पर समानांतर Seq स्कैन (वास्तविक समय = 40820.004..97405.250 पंक्तियाँ = 292002 लूप = 3)
--------------------- फ़िल्टर: ((trd> = '2011-01-01 00:00:00' :: टाइमस्टैम्प बिना समय क्षेत्र) और Trd <= '2011-12-31 00:00:00' :: समय क्षेत्र के बिना टाइमस्टैम्प) और (सेशन = 1)
-------------------- फ़िल्टर द्वारा हटाए गए पंक्तियों: 14616000
-------------------- बफ़र्स: साझा हिट = 2565 पढ़ा = 489099
योजना समय: 7.899 मि
निष्पादन समय: 98523.278 एमएस

98523.278 एमएस बनाम 3123.960 एमएस। शायद एक आंशिक सूचकांक हमें मदद करेगा, लेकिन इसे जोखिम में न डालना और एक उपयुक्त पंक्तिबद्ध संरचना बनाना बेहतर होगा जिसमें तैयार मान संग्रहीत किए जाएंगे।

मैनुअल समुच्चय

मैनुअल समुच्चय के लिए एक उपयुक्त संरचना एक नियमित row_based तालिका हो सकती है जिसमें पूर्वगामी मूल्य होते हैं। उदाहरण के लिए, इसमें 1 के बराबर ऑपरेशन प्रकार के साथ 2011 से संबंधित एक रिकॉर्ड हो सकता है, जबकि खेतों में एम 1, एम 2, एम 3, एम 4 और एम 5 इन विश्लेषणात्मक वर्गों के लिए ठीक से संग्रहीत किया जाएगा। इस प्रकार, समुच्चय और सूचकांकों का पर्याप्त समूह होने से, विश्लेषणात्मक प्रश्न अभूतपूर्व प्रदर्शन प्राप्त करते हैं। दिलचस्प है, Microsoft SQL सर्वर विश्लेषण सेवाओं में एक विशेष विज़ार्ड है जो आपको पूर्व-परिकलित मानों की संख्या और गहराई को कॉन्फ़िगर करने की अनुमति देता है।

इस समाधान के निम्नलिखित फायदे हैं:

• वास्तविक समय विश्लेषण।
  
  कृपया "वास्तविक समय विश्लेषण" शब्द को भ्रमित न करें। यहां हम इस तथ्य के बारे में बात कर रहे हैं कि यूनिट का वेतन वृद्धि ज्यादातर मामलों में स्वीकार्य अवधि के दौरान होता है।
  
  वास्तव में, यह प्लस विवादास्पद है, लेकिन इसके बारे में बात नहीं करते हैं। तथ्य बना हुआ है। समाधान की वास्तुकला ऐसी है कि इकाइयां लगभग हमेशा "ताजा" रहती हैं।
• डेटा वॉल्यूम से पूर्ण स्वतंत्रता।
  
  यह बहुत गंभीर प्लस है। कोई फर्क नहीं पड़ता कि कितना डेटा संसाधित होता है, जितनी जल्दी या बाद में उन्हें संसाधित किया जाएगा, और प्राप्त किए गए कुल।
• सापेक्ष जटिलता।
  
  वास्तविक समय के एनालिटिक्स और डेटा वॉल्यूम स्वतंत्रता प्राप्त करने के लिए, समाधान को डीबीएमएस स्तर पर उन्नत तकनीकों जैसे मल्टीथ्रेडिंग और मैनुअल लॉक प्रबंधन का उपयोग करना चाहिए।
• परीक्षण में कठिनाई।
  
  यहां हम यूनिट परीक्षण और मैनुअल परीक्षण दोनों के बारे में बात कर रहे हैं। मुझे लगता है कि पाठक को यह नहीं समझाना चाहिए कि मल्टीथ्रेडिंग त्रुटियों की पहचान करना आसान काम नहीं है।
• डिस्क स्थान की आवश्यकताओं में वृद्धि।
  
  

कॉलमस्टोर का वास्तविक उपयोग

यहां हमें सिद्धांत में फिर से गोता लगाना चाहिए और इस सवाल का विश्लेषण करना चाहिए कि विश्लेषणात्मक डेटा अधिक विस्तार से क्या है।

उद्यम का औसत सिर लें। एक नियम के रूप में, वह दो वैश्विक सवालों के बारे में चिंतित है: "इस समय चीजें कैसे चल रही हैं?" और "हाल ही में क्या बदल गया है?"

इस सवाल का जवाब देने के लिए "इस समय चीजें कैसे चल रही हैं" हमें ऐतिहासिक डेटा की बिल्कुल जरूरत नहीं है। यानी कोई बात नहीं एक महीने पहले कैसे चला गया।

पल्स पर उंगली रखने के लिए, सवाल अक्सर पूछा जाता है। इस प्रकार के डेटा विश्लेषण को ऑपरेशनल कहा जाता है।

इस सवाल का जवाब देने के लिए "हाल ही में क्या बदल गया है", हमें सटीक ऐतिहासिक डेटा की आवश्यकता है। इसके अलावा, एक नियम के रूप में, विश्लेषण एक ही समय अंतराल पर किया जाता है। उदाहरण के लिए, एक महीने की तुलना महीने, साल से साल, आदि से की जाती है। बेशक, सिस्टम को उपयोगकर्ता को मनमाने अवधि की तुलना करने की क्षमता से सीमित नहीं करना चाहिए, लेकिन इस तरह के मामले को दुर्लभ माना जाना चाहिए, क्योंकि एक बंद वर्ष की तुलना आधे से बंद नहीं करने से कोई मतलब नहीं है। तुलनात्मक विश्लेषण की एक विशिष्ट विशेषता यह है कि इसे जितनी बार परिचालन की आवश्यकता होती है उतनी आवश्यकता नहीं होती है। हम इस प्रकार के विश्लेषण को ऐतिहासिक कहेंगे।

जाहिर है, परिचालन विश्लेषण जल्दी से होना चाहिए। तदनुसार, यह प्रदर्शन पर उच्च मांग रखता है। जबकि ऐतिहासिक विश्लेषण के लिए, ऐसी आवश्यकताओं को आगे नहीं रखा जा सकता है। यद्यपि ऐतिहासिक विश्लेषण का प्रदर्शन बहुत उच्च स्तर पर रहना चाहिए। कम से कम इतना है कि विश्लेषण प्रणाली ही प्रतिस्पर्धी बनी हुई है।

इसलिए, दो प्रकार के विश्लेषण के अनुसार, हम दो प्रकार के विश्लेषणात्मक डेटा को अलग कर सकते हैं: परिचालन डेटा और ऐतिहासिक। उपयोगकर्ता की ओर से यह ध्यान देने योग्य नहीं होना चाहिए कि वह वर्तमान में किस विशेष डेटा के साथ काम कर रहा है।

यह इन विचारों से है कि डेटाबेस सर्वरों में संभावना अलग-अलग वर्गों में तालिकाओं को विभाजित करने से उभरा है।

कॉलमस्टोर के संबंध में, पंक्ति-आधारित और कॉलमस्टोर स्वरूपों में अनुभागों को मिलाना संभव है। यह ज्ञात है कि परिचालन विश्लेषण डेटा अक्सर परिवर्तनों के अधीन होता है, जो कॉलमस्टोर प्रारूप में उनके भंडारण को रोकता है। और इस तथ्य को देखते हुए कि परिचालन डेटा बहुत अधिक नहीं होता है, उन्हें पंक्ति-आधारित प्रारूप में संग्रहीत किया जा सकता है।

ऐतिहासिक डेटा नहीं बदलता है। इस डेटा का एक बहुत कुछ है, और इसलिए कॉलमस्टोर प्रारूप उन्हें बेहतर सूट करता है। याद रखें कि स्तंभ के स्रोत पर बोल्ड प्रश्नों का प्रदर्शन पंक्ति-आधारित स्रोत की तुलना में अधिक है।

आइए उपरोक्त सभी का एक उदाहरण देखें।

नीचे मैं मुख्य गोदाम तालिका बनाता हूं और इसके संचालन और ऐतिहासिक विश्लेषण के खंड संलग्न करता हूं।

 create table warehouse ( trd date, org int, op int, it int, wh int, m1 numeric(32, 2), m2 numeric(32, 2), m3 numeric(32, 2), m4 numeric(32, 2), m5 numeric(32, 2) ) partition by range(trd); create foreign table historycal_data ( trd date, org int, op int, it int, wh int, m1 numeric(32, 2), m2 numeric(32, 2), m3 numeric(32, 2), m4 numeric(32, 2), m5 numeric(32, 2) ) server cstore_server options(compression 'pglz'); insert into historycal_data select '2010-01-01'::date + make_interval(days => d) as trd , op , org , wh , it , 100 as m1 , 100 as m2 , 100 as m3 , 100 as m4 , 100 as m5 from generate_series(0, 1) as op cross join generate_series(1, 2) as org cross join generate_series(1, 3) as wh cross join generate_series(1, 4000) as it cross join generate_series(0, (1095 - 31)) as d; analyze historycal_data; create table operational_data as select ('2012-12-01'::date + make_interval(days => d))::date as trd , op , org , wh , it , 100::numeric(32, 2) as m1 , 100::numeric(32, 2) as m2 , 100::numeric(32, 2) as m3 , 100::numeric(32, 2) as m4 , 100::numeric(32, 2) as m5 from generate_series(0, 1) as op cross join generate_series(1, 2) as org cross join generate_series(1, 3) as wh cross join generate_series(1, 4000) as it cross join generate_series(0, 30) as d; create index trd_op_ix on operational_data (trd, op); analyze operational_data; alter table warehouse attach partition operational_data for values from ('2012-12-01') to ('2112-01-01'); alter table warehouse attach partition historycal_data for values from ('2010-01-01') to ('2012-12-01'); 

सब कुछ तैयार है। आइए एक दो रिपोर्टों को क्रमबद्ध करने का प्रयास करें। आइए चालू महीने के एक दिन के लिए डेटा ऑर्डर करके शुरू करें।

 explain (analyze, costs, buffers) select sum(m1) from warehouse where trd = '2012-12-01' and op = 1; 

सकल (लागत = 15203.37..15203.38 पंक्तियाँ = 1 चौड़ाई = 32) (वास्तविक समय = 17.320..17.320 पंक्तियाँ = 1 छोर = 1)
- बफ़र्स: साझा हिट = 3 पढ़ा = 515
--- (परिशिष्ट = 532.59..15140.89 पंक्तियाँ = 24991 चौड़ाई = 5) (वास्तविक समय = 1.924..13.838 पंक्तियाँ = 24000 लूप = 1)
------- बफ़र्स: साझा हिट = 3 पढ़ा = 515
---------> ऑपरेशनल_डेटा पर बिटमैप हीप स्कैन (लागत = 532.59..15140.89 पंक्तियाँ = 24991 चौड़ाई = 5) (वास्तविक समय = 1.924..11.992 पंक्तियाँ = 24000 लूप = 1)
--------------- पुनः जाँच करें: ((trd = '2012-12-01' :: दिनांक) और (op = 1))
--------------- ढेर ब्लॉक: सटीक = 449
--------------- बफ़र्स: साझा हिट = 3 पढ़ा = 515
----------------> बिटमैप इंडेक्स स्कैन trd_op_ix (लागत = 0.00..526.34 पंक्तियों = 24991 चौड़ाई = 0) पर (वास्तविक समय = 1.877..1.877 पंक्तियों = 24000 छोरों = 1 )
--------------------- सूचकांक कंडोम: ((trd = '2012-12-01' :: दिनांक) और (op = 1))
--------------------- बफ़र्स: साझा हिट = 2 पढ़ा = 67
योजना समय: 0.388 एमएस
निष्पादन समय: 100.941 एमएस

अब हम पूरे 2012 के लिए डेटा ऑर्डर करेंगे, जिसमें लेनदेन की संख्या 8,784,000 है।

 explain (analyze, costs, buffers) select sum(m1) from warehouse where trd between '2012-01-01' and '2012-12-31' and op = 1; 

सकल (लागत = 960685.82..960685.83 पंक्तियाँ = 1 चौड़ाई = 32) (वास्तविक समय = 4124.681..4124.681 पंक्तियाँ = 1 छोर = 1)
- बफ़र: साझा हिट = 45591 पढ़ा = 11282
--- (परिशिष्ट = 0.00..938846.60 पंक्तियाँ = 8735687 चौड़ाई = 5) (वास्तविक समय = 66.581..3036.394 पंक्तियाँ = 8784000 लूप = 1)
--------- बफ़र्स: साझा हिट = 45591 पढ़ा = 11282
----------> Historycal_data (लागत = 0.00..898899.60 पंक्तियों = 7994117 चौड़ाई = 5) पर विदेशी स्कैन (वास्तविक समय = 66.579..2193.801 पंक्तियाँ = 8040000 लूप = 1)
--------------- फ़िल्टर: ((trd> = '2012-01-01' :: दिनांक) और (trd <= '2012-12-31' :: दिनांक) और (op = 1))
--------------- फ़िल्टर द्वारा निकाली गई पंक्तियाँ: 8040000
--------------- CStore फ़ाइल: / var / lib / pgsql / 10 / data / cstore_fdw / 14028/16448
--------------- CStore फ़ाइल का आकार: 117401470
--------------- बफ़र्स: साझा हिट = 42966
----------> ऑपरेशनल_डेटा पर सीक स्कैन (लागत = 0.00..39947.00 पंक्तियाँ = 741570 चौड़ाई = 5) (वास्तविक समय = 0.019..284.824 पंक्तियाँ = 744000 लूप = 1)
--------------- फ़िल्टर: ((trd> = '2012-01-01' :: दिनांक) और (trd <= '2012-12-31' :: दिनांक) और (op = 1))
--------------- फ़िल्टर द्वारा निकाली गई पंक्तियाँ: 744000
--------------- बफ़र्स: साझा हिट = 2625 पढ़ा = 11282
योजना समय: 0.256 मि
निष्पादन समय: 4125.239 एमएस

अंत में, आइए देखें कि उपयोगकर्ता क्या चाहता है, उदाहरण के लिए, दुर्भावनापूर्ण इरादे के बिना, सिस्टम में सभी लेनदेन पर एक रिपोर्ट का आदेश देने के लिए, जिसमें 52 608 000 हैं।

 explain (analyze, costs, buffers) select sum(m1) from warehouse 

एग्रीगेट (लागत = 672940.20..672940.21 पंक्तियाँ = 1 चौड़ाई = 32) (वास्तविक समय = 15907.886..15907.886 पंक्तियाँ = 1 छोर = 1)
- बफ़र: साझा हिट = 17075 पढ़ा = 11154
---> परिशिष्ट (लागत = ०.००. ५१४२०.२० पंक्तियाँ = ५२६० width००० चौड़ाई = ५) (वास्तविक समय = ०.१ ९ २.९ १.११५.४४ पंक्तियाँ = ५२६०000००० छोर = १)
--------- बफ़र्स: साझा हिट = 17075 पढ़ा = 11154
----------> Historycal_data (लागत = 0.00..512633.20 पंक्तियों = 51120000 चौड़ाई = 5) पर विदेशी स्कैन (वास्तविक समय = 0.191..5376.449 पंक्तियाँ = 51120000 लूप = 1)
--------------- CStore फ़ाइल: / var / lib / pgsql / 10 / data / cstore_fdw / 14028/16448
--------------- CStore फ़ाइल का आकार: 117401470
--------------- बफ़र्स: साझा हिट = 14322
----------> ऑपरेशनल_डेटा पर सीक स्कैन (लागत = 0.00..28787.00 पंक्तियाँ = 1488000 चौड़ाई = 5) (वास्तविक समय = 0.032..246.978 पंक्तियाँ = 1488000 लूप = 1)
--------------- बफ़र्स: साझा हिट = 2753 पढ़ा = 11154
योजना समय: 0.157 एमएस
निष्पादन समय: 15908.096 एमएस

कृपया ध्यान दें कि मैं अभी भी अपना लेख लिख रहा हूं, जैसे कि कुछ भी नहीं हुआ था। मुझे HDD और 4 GB RAM के साथ अपने नहीं-शक्तिशाली लैपटॉप को भी रिबूट करना पड़ा। हालांकि संसाधन खपत के मुद्दे पर अधिक सावधानीपूर्वक अध्ययन की आवश्यकता है।

दोष सहिष्णुता

भाग में, इस लेखन के समय दोष सहिष्णुता का सही परीक्षण किया गया था। मेरा लैपटॉप जीवित है, और, सामान्य तौर पर, मैंने सामान्य लोगों के अलावा, इसके काम में कोई मंदी नहीं देखी।

पाठक मुझे इस तथ्य के लिए क्षमा करें कि मेरे पास गलती सहिष्णुता के मुद्दे पर विस्तार से काम करने का समय नहीं था, लेकिन मैं कह सकता हूं कि प्रश्न में विस्तार में दोष सहिष्णुता है - बैकअप संभव है।

कार्यान्वयन में आसानी

जैसा कि यह पता चला है, एक स्तंभ बनाने वाली तालिका को स्तंभ के प्रारूप में डेटा संग्रहीत करते समय, संपीड़न एल्गोरिथम के अलावा कोई विकल्प नहीं होता है। कंप्रेशन अपने आप में नितांत आवश्यक है।

प्रारूप में एक निश्चित संरचना है। उपयुक्त पैरामीटर सेट करके, आप विश्लेषणात्मक प्रश्नों का एक निश्चित त्वरण प्राप्त कर सकते हैं, या सूचना के संपीड़न की डिग्री को समायोजित कर सकते हैं।

जैसा कि ऊपर दिखाया गया है, एक कॉलमस्टोर टेबल बनाना बिल्कुल भी परेशानी की बात नहीं है। एक्सटेंशन 40 PostgreSQL डेटा प्रकारों के साथ काम कर सकता है। वेबिनार ने PostgreSQL द्वारा समर्थित सभी प्रकारों के बारे में बात की।

एक डेवलपर को नई संरचनाओं के साथ काम करने के लिए कौन से नए कौशल होने चाहिए

SQL डेवलपर को कॉलमस्टोर तालिकाओं पर प्रश्न लिखने के लिए किसी विशेष कौशल की आवश्यकता नहीं होती है। ऐसी तालिका सभी प्रश्नों में दिखाई देती है, जैसे एक नियमित पंक्ति-आधारित तालिका। हालांकि यह क्वेरी ऑप्टिमाइज़ेशन की आवश्यकता को बाहर नहीं करता है।

निष्कर्ष

इस लेख में, मैंने दिखाया कि कॉलमस्टोर स्टोरेज फॉर्मेट के साथ एक टेबल कैसे उपयोगी हो सकती है। यह डिस्क स्थान और उच्च प्रदर्शन विश्लेषणात्मक प्रश्नों को बचाता है। तालिका के साथ काम करने में आसानी से एक पूर्ण विश्लेषणात्मक डेटा वेयरहाउस बनाने की लागत कम हो जाती है, क्योंकि इसके उपयोग से एल्गोरिदम को डिबग करने में मुश्किल जटिल के विकास की आवश्यकता नहीं होती है। परीक्षण सरल है।

इस तथ्य के बावजूद कि प्रयोगों ने आशावाद को प्रेरित किया है, कई मुद्दों पर काम नहीं किया गया है। उदाहरण के लिए, स्तंभ तालिका अन्य तालिकाओं में शामिल होने पर कौन सी क्वेरी योजना उत्पन्न होगी। मुझे उम्मीद है कि अगले भाग में यह काम जारी रहेगा। कितने भाग इस पर निर्भर करेंगे कि cstore_fdw अधिक या कम वास्तविक डेटा पर कैसा व्यवहार करता है।

अतिरिक्त सामग्री के लिए लिंक

लघु समीक्षा cstore_fdw

gstub पर cstore_fdw

रोडमैप cstore_fdw