कॉलम-आधारित डीबीएमएस बनाम लोअरकेस, एक समझौते के बारे में कैसे?

स्तंभित DBMS सक्रिय रूप से शून्य वर्षों में विकसित हुए, इस समय उन्होंने अपने आला को पाया है और व्यावहारिक रूप से पारंपरिक लोअरकेस सिस्टम के साथ प्रतिस्पर्धा नहीं करते हैं। कटौती के तहत, लेखक समझता है कि क्या एक सार्वभौमिक समाधान संभव है और यह कितना व्यावहारिक है।

"हर चीज में प्रगति होती है ... डर नहीं है कि वे आपको कार्यालय में बुलाएंगे और कहेंगे:" हमने यहां परामर्श किया है, और कल आपको अपनी पसंद पर तिमाही या जला दिया जाएगा। "यह एक मुश्किल विकल्प होगा।" मुझे लगता है कि वह हम में से बहुत से चकित हो जाएगा। ”
यारोस्लाव हसेक। बहादुर सैनिक श्विक का एडवेंचर्स।

प्रागितिहास

कितने डेटाबेस मौजूद हैं, यह वैचारिक टकराव है। जिज्ञासा से बाहर, लेखक ने 1 9 75 में डिब्बे में जे। मार्टिन [1] से जे मार्टिन द्वारा एक पुस्तक पाई और तुरंत शब्दों पर ठोकर खाई (पृष्ठ 183): "द्विआधारी संबंधों का उपयोग कार्यों में किया जाता है [...], i.e. केवल दो डोमेन के संबंध। यह ज्ञात है कि द्विआधारी संबंध आधार को सबसे बड़ा लचीलापन देते हैं। हालांकि, वाणिज्यिक कार्यों में विभिन्न डिग्री के संबंध सुविधाजनक हैं। ” संबंधों को यहां संबंधपरक संबंधों के रूप में समझा जाता है। और उल्लिखित कृतियाँ 1967 ... 1970।

बता दें कि साइबेस आईक्यू पहली बार औद्योगिक रूप से इस्तेमाल किया गया कॉलम डीबीएमएस था, लेकिन कम से कम विचारों के स्तर पर, इसके 25 साल पहले सब कुछ बोल दिया गया था।

वर्तमान में, निम्नलिखित DBMS कॉलम या एक डिग्री या किसी अन्य में समर्थित हैं (यह मुख्य रूप से यहां लिया गया है ):

व्यावसायिक

• 1010data का टेनबेस डेटाबेस
• अल्टेरियन का इंजन
• Aster डेटा सिस्टम
• Calpont InfiniDB एंटरप्राइज संस्करण
• EXASOL
• प्रसिद्धि
• FluidDB
• Greenplum
• हाइव इंटेलिजेंस लिमिटेड हेक्स इंजन
• अव्यावहारिक उद्यम संस्करण
• KDB
• Kickfire
• Microsoft SQL Server 2012+ (एंटरप्राइज़ संस्करण)
• ओरेकल रिटेल प्रेडिक्टिव एप्लिकेशन सर्वर (RPAS)
• Paraccel विश्लेषणात्मक डेटाबेस
• SAND CDBMS
• SAP हाना
• SenSage
• साइबेस iq
• Vectorwise
• वर्टिका

मुक्त और खुला स्रोत

• Calpont InfiniDB सामुदायिक संस्करण
• ClickHouse
• अवगुण सामुदायिक संस्करण
• ग्रीनप्लम समुदाय संस्करण
• LucidDB
• Metakit
• MonetDB
• सी-स्टोर
• एस प्रोग्रामिंग भाषा और जीएनयू आर सांख्यिकीय विश्लेषण के लिए स्तंभ-उन्मुख डेटा संरचनाओं को शामिल करते हैं

मतभेद

एक संबंधपरक संबंध टुपल्स का एक संग्रह है, अनिवार्य रूप से एक दो-आयामी तालिका। तदनुसार, दो भंडारण विकल्प हैं - पंक्ति-वार या कॉलम-वार। पृथक्करण थोड़ा कृत्रिम, तार्किक है। ड्रम और ट्रैक रिकॉर्ड की योजना बनाने के लिए डेटाबेस डेवलपर्स लंबे समय से बंद हैं। DBMS व्यवस्थापकों का कार्य एक फाइल सिस्टम (सिस्टम) में DBMS डेटा को जानबूझकर विघटित करना है, और फाइल सिस्टम भौतिक डिस्क पर डेटा की व्यवस्था कैसे करता है, इसे मुख्य रूप से सिस्टम डेवलपर्स को फाइल करने के लिए जाना जाता है।

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

दुर्भाग्य से, कोई भी काल्पनिक DBMS डेटा स्टोर करने का सबसे अच्छा तरीका नहीं चुन सकता है। क्योंकि इस बात की समझ नहीं है कि हम इस डेटा का उपयोग कैसे करने जा रहे हैं। और इसके बिना, एक विकल्प बनाना असंभव है, हालांकि यह बहुत महत्वपूर्ण है।

DBMS का सबसे मूल्यवान गुण डेटा (और ACID आवश्यकताओं, निश्चित रूप से) को जल्दी से संसाधित करने की क्षमता है। DBMS की गति मुख्य रूप से डिस्क संचालन की संख्या से निर्धारित होती है। इससे दो चरम मामले सामने आते हैं:

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

लेकिन ये चरम मामले हैं, जीवन में सब कुछ इतना स्पष्ट नहीं है।

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

दूसरे शब्दों में, किसी भी परिस्थिति में हमारे काल्पनिक DBMS लाइन और कॉलम भंडारण विकल्पों के बीच चयन करने की जिम्मेदारी ग्रहण नहीं करेंगे, यह डेटाबेस डिजाइनर द्वारा किया जाना चाहिए।

हालाँकि, उपरोक्त को देखते हुए, डेटाबेस डिज़ाइनर भी बहुत मुश्किल विकल्प में होगा। वह हम में से कई लोगों को चकमा देगा।

क्या हुआ अगर

संक्षेप में, दोनों कॉलम-वार और लाइन-वार वेरिएंट - एक विचार के चरम मामले - तालिका को "रिबन" में काटें और प्रत्येक टेप के अंदर लाइन द्वारा डेटा लाइन स्टोर करें। बस एक मामले में टेप एक है, दूसरे में टेप एक स्तंभ को पतित करता है।

तो क्यों नहीं मध्यवर्ती विकल्पों की अनुमति दें - यदि कुछ स्तंभों का डेटा एक साथ आता / पढ़ता है, भले ही वे एक ही टेप पर हों। और अगर टेप में कोई डेटा (NULL) नहीं था, तो कुछ भी संग्रहीत करने की आवश्यकता नहीं है। उसी समय, अधिकतम पंक्ति आकार की समस्या को हटा दिया जाता है - आप तालिका को विभाजित कर सकते हैं जब कोई जोखिम होता है कि पंक्ति एक पृष्ठ पर फिट नहीं होगी।

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

हमने इसे अपने लिए इस प्रकार किया:

• तालिका बनाते समय, हमारी प्राथमिकताओं के बारे में जानकारी pragmas का उपयोग करके SQL प्रोसेसर को दी जाती है
• प्रारंभ में, एक तालिका बनाते समय, यह माना जाता है कि पूरी पंक्ति बी-पेड़ के एक पृष्ठ पर स्थित होगी
• हालाँकि, आप उपयोग कर सकते हैं - - # पेजमा पेज_ब्रेक
  एसक्यूएल प्रोसेसर को यह बताने के लिए कि निम्नलिखित कॉलम दूसरे पेज पर (दूसरे पेड़ में) स्थित होगा
• उपयोग - - #pragma column_based
  हमें स्पष्ट रूप से यह कहने की अनुमति देता है कि जो स्तंभ आगे बढ़ते हैं वे प्रत्येक अपने स्वयं के पेड़ पर स्थित हैं
• - - #pragma row_based
  रद्द करें कॉलम_बेड कार्रवाई
• इस प्रकार, तालिका में एक या अधिक बी-पेड़ होते हैं, जिनमें से पहला मुख्य तत्व एक छिपी पहचान क्षेत्र है। यह माना जाता है कि जिस क्रम में रिकॉर्ड बनाए जाते हैं (जिस क्रम में रिकॉर्ड पढ़े जाते हैं, उसी के साथ अच्छी तरह से संबंध स्थापित कर सकते हैं) भी मायने रखता है और इसकी उपेक्षा नहीं की जानी चाहिए। प्राथमिक कुंजी एक अलग पेड़ है, हालांकि, यह विषय पर लागू नहीं होता है।

यह व्यवहार में कैसे दिख सकता है?

उदाहरण के लिए, इस तरह:

CREATE TABLE twomass_psc ( ra double precision, decl double precision, … -- #pragma page_break j_m real, j_cmsig real, j_msigcom real, j_snr real, h_m real, h_cmsig real, h_msigcom real, h_snr real, k_m real, k_cmsig real, k_msigcom real, k_snr real, -- #pragma page_break … coadd_key integer, coadd smallint ); 

उदाहरण के लिए, एटलस 2MASS की मुख्य तालिका ली गई है, यहां और यहां की पौराणिक कथा।
जे , एच , के - इंफ्रारेड सब-बैंड, यह उन पर एक साथ डेटा स्टोर करने के लिए समझ में आता है, क्योंकि शोध में उन्हें एक साथ संसाधित किया जाता है। यहाँ, उदाहरण के लिए :


पहली तस्वीर जो सामने आई।

या यहाँ , और भी सुंदर:

यह पुष्टि करने का समय है कि यह कुछ व्यावहारिक समझ में आता है।

परिणाम

नीचे प्रस्तुत है:

• चरण आरेख (रिकॉर्ड किए गए पृष्ठ की एक्स-संख्या, पहले दर्ज किए गए अंतिम-वाई की संख्या) दो संस्करणों में तालिका बनाते समय डिस्क को लिखने के लिए पृष्ठ (तार्किक संख्या) के लिए प्रक्रिया।
• एक कॉलम में, इसे by_1 के रूप में निर्दिष्ट किया गया है
• और 16 स्तंभों में कटौती की गई तालिका के लिए, इसे by_16 के रूप में निर्दिष्ट किया गया है
• कुल कॉलम 181

आइए देखें कि यह कैसे काम करता है:

• By_16 विकल्प काफ़ी अधिक कॉम्पैक्ट है, जो तार्किक है, अंतिम - लाइन विकल्प सिर्फ एक सीधी रेखा (आउटलेयर के साथ) देगा।
• त्रिकोणीय आउटलेर - बी-पेड़ों के रिकॉर्ड मध्यवर्ती पृष्ठ।
• डेटा रिकॉर्ड दिखाया गया है, जाहिर है, रीडिंग कुछ इस तरह दिखाई देगी।
• ऊपर कहा गया था कि सभी विकल्प समान मात्रा में जानकारी दर्ज करते हैं और जिस स्ट्रीम को घटाया जाना चाहिए, वह लगभग एक ही (all दक्षता दक्षता) है।
  लेकिन यहां यह बहुत स्पष्ट रूप से दिखाया गया है कि एक कॉलम-वार संस्करण में डेटा की बारीकियों के कारण पेड़ अलग-अलग गति से बढ़ते हैं (एक कॉलम में वे अक्सर दोहराते हैं और बहुत अच्छी तरह से संपीड़ित करते हैं, दूसरे कॉलम में - कंप्रेसर के दृष्टिकोण से शोर)। नतीजतन, कुछ पेड़ आगे बढ़ते हैं, अन्य देर से होते हैं; पढ़ते समय, हम उद्देश्यपूर्ण रूप से एक "फाड़ा" रीडिंग मोड प्राप्त करते हैं जो फ़ाइल सिस्टम के लिए बहुत अप्रिय है।
• इसलिए, स्तंभ_ की तुलना में पढ़ने के लिए by_16 बहुत अधिक बेहतर है, यह लाइन-वार के लिए आराम में लगभग बराबर है।
• लेकिन एक ही समय में, by_16 वेरिएंट में कॉलम-वार वेरिएंट का मुख्य लाभ होता है, जब कॉलम की एक छोटी संख्या की आवश्यकता होती है। खासकर यदि आप तालिका को 16 टुकड़ों के लिए यांत्रिक रूप से विभाजित नहीं करते हैं, लेकिन सार्थक रूप से, उनके संयुक्त उपयोग की संभावनाओं का विश्लेषण करने के बाद।

सूत्रों का कहना है

[१] जे। मार्टिन कंप्यूटिंग सिस्टम में डेटाबेस का संगठन। द वर्ल्ड, 1978
[२] कॉलम इंडेक्स, उपयोग की विशेषताएं
[३] डैनियल जे। अबदी, सैमुअल मैडेन, नबील हचेम। ColumnStores बनाम RowStores: वे वास्तव में कितने अलग हैं? , डेटा, वैंकूवर, ई.पू., कनाडा, जून 2008 के प्रबंधन पर ACM SIGMOD अंतर्राष्ट्रीय सम्मेलन की कार्यवाही
[४] माइकल स्टोनब्रेकर, उउर elंटिनेमेल। "एक आकार सभी फिट बैठता है": एक आइडिया जिसका समय आ गया है और चला गया है , 2005