स्तंभ विज्ञान डेटा विज्ञान के लिए उपयुक्त डेटाबेस क्या बनाता है?
जवाबों:
एक स्तंभ-उन्मुख डेटाबेस (= स्तंभ डेटा-स्टोर) डिस्क पर स्तंभ द्वारा तालिका स्तंभ का डेटा संग्रहीत करता है, जबकि एक पंक्ति-उन्मुख डेटाबेस पंक्ति द्वारा तालिका पंक्ति के डेटा को संग्रहीत करता है।
पंक्ति-उन्मुख डेटाबेस की तुलना में स्तंभ-उन्मुख डेटाबेस का उपयोग करने के दो मुख्य लाभ हैं। पहला लाभ डेटा की राशि से संबंधित है जिसे पढ़ने की जरूरत है कि हम केवल कुछ सुविधाओं पर एक ऑपरेशन करते हैं। एक साधारण प्रश्न पर विचार करें:
SELECT correlation(feature2, feature5)
FROM records
एक पारंपरिक निष्पादक संपूर्ण तालिका (अर्थात सभी सुविधाएँ) पढ़ेगा:
इसके बजाय, हमारे कॉलम-आधारित दृष्टिकोण का उपयोग करके हमें केवल उन कॉलमों को पढ़ना होगा जो इसमें रुचि रखते हैं:
दूसरा लाभ, जो बड़े डेटाबेस के लिए भी बहुत महत्वपूर्ण है, यह है कि कॉलम-आधारित संग्रहण बेहतर संपीड़न की अनुमति देता है, क्योंकि एक विशिष्ट कॉलम में डेटा वास्तव में सभी स्तंभों की तुलना में सजातीय है।
स्तंभ-उन्मुख दृष्टिकोण का मुख्य दोष यह है कि संपूर्ण दी गई पंक्ति में हेरफेर (लुकअप, अपडेट या डिलीट) अक्षम है। हालांकि स्थिति को एनालिटिक्स ("वेयरहाउसिंग") के लिए डेटाबेस में शायद ही कभी होना चाहिए, जिसका अर्थ है कि अधिकांश ऑपरेशन केवल-पढ़ने के लिए होते हैं, शायद ही कभी एक ही तालिका में कई विशेषताओं को पढ़ा जाता है और लिखता है केवल एपेंडेस।
कुछ RDMS एक कॉलम-ओरिएंटेड स्टोरेज इंजन विकल्प प्रदान करते हैं। उदाहरण के लिए, PostgreSQL में मूल रूप से स्तंभ-आधारित फैशन में तालिकाओं को संग्रहीत करने का कोई विकल्प नहीं है, लेकिन ग्रीनप्लम ने एक बंद-स्रोत एक (DBMS2, 2009) बनाया है। दिलचस्प बात यह है कि, स्केलेबल-इन-डेटाबेस एनालिटिक्स, मैडलिब (हेलरस्टीन एट अल।, 2012) के लिए ग्रीनप्लम भी ओपन-सोर्स लाइब्रेरी के पीछे है, जो कोई संयोग नहीं है। अभी हाल ही में, साइटसडीबी, एक स्टार्टअप जो कि उच्च गति, विश्लेषणात्मक डेटाबेस पर काम कर रहा है, ने पोस्टग्रैसक्यूएल, सीएसटीओआर (मिलर, 2014) के लिए अपने स्वयं के ओपन-सोर्स स्तंभ स्टोर एक्सटेंशन को जारी किया। बड़े पैमाने पर मशीन सीखने के लिए Google की प्रणाली सिबिल कॉलम-उन्मुख डेटा प्रारूप (चंद्र एट अल।, 2010) का भी उपयोग करती है। यह प्रवृत्ति बड़े पैमाने पर एनालिटिक्स के लिए कॉलम-ओरिएंटेड स्टोरेज के आसपास बढ़ती रुचि को दर्शाती है। Stonebraker एट अल। (2005) आगे कॉलम-ओरिएंटेड डीबीएमएस के फायदों पर चर्चा करते हैं।
दो ठोस उपयोग के मामले: बड़े पैमाने पर मशीन सीखने के लिए सबसे अधिक डेटासेट कैसे संग्रहीत किए जाते हैं?
(: जवाब के अधिकांश के परिशिष्ट C से आता है BeatDB: बड़े पैमाने पर संकेत डेटा सेट से saliencies अनावरण करने के लिए एक अंत से अंत दृष्टिकोण फ़्रैंक Dernoncourt, एसएम, थीसिस, EECS एमआईटी विभाग। )
यह निर्भर करता है कि आप क्या करते हैं।
कॉलम स्टोर के दो प्रमुख लाभ हैं:
- पूरे कॉलम को छोड़ दिया जा सकता है
- रन-लेंथ कम्प्रेशन कॉलम पर कुछ विशेष प्रकार के (विशेष रूप से कुछ विशिष्ट मानों के लिए) बेहतर काम करता है
हालाँकि उनमें भी कमियां हैं:
- कई एल्गोरिदम को सभी स्तंभों की आवश्यकता होगी, और केवल एक समय में रिकॉर्ड करना होगा (उदाहरण के-साधन) या एक जोड़ीदार दूरी की गणना करने की आवश्यकता हो सकती है
- संपीड़न तकनीक केवल विरल डेटा प्रकारों और कारकों पर अच्छी तरह से काम करती है, लेकिन दोहरे-मूल्यवान निरंतर डेटा पर अच्छी तरह से नहीं
- कॉलम स्टोर पर एप्स महंगे हैं, इसलिए यह स्ट्रीमिंग / डेटा बदलने के लिए आदर्श नहीं है
OLAP उर्फ "बेवकूफ एनालिटिक्स" (माइकल स्टोनब्रेकर) और निश्चित रूप से प्रीप्रोसेसिंग के लिए जहां आप वास्तव में पूरे कॉलम को छोड़ने में दिलचस्पी ले सकते हैं (लेकिन आपको पहले संरचित डेटा की आवश्यकता होगी - कॉलम में JSONs नहीं है) प्रारूप)। क्योंकि स्तंभ का लेआउट वास्तव में उदाहरण के लिए अच्छा है कि आपने पिछले सप्ताह कितने सेब बेचे हैं।
अधिकांश वैज्ञानिक / डेटा विज्ञान उपयोग के मामलों के लिए, सरणी डेटाबेस जाने का तरीका प्रतीत होता है (प्लस, निश्चित रूप से, असंरचित इनपुट डेटा)। जैसे SciDB और RasDaMan।
कई मामलों में (उदाहरण के लिए गहरी शिक्षा), मैट्रिक्स और सरणियाँ आपके लिए आवश्यक डेटा प्रकार हैं, न कि कॉलम। MapReduce आदि अभी भी प्रीप्रोसेसिंग में उपयोगी हो सकते हैं। हो सकता है कि स्तंभ डेटा (लेकिन सरणी डेटाबेस आमतौर पर स्तंभ जैसी संपीड़न का समर्थन करता है, भी)।
मैंने एक स्तंभ डेटाबेस का उपयोग नहीं किया है, लेकिन मैंने एक खुला स्रोत स्तंभ फ़ाइल का उपयोग किया है जिसे Parquet कहा जाता है, और मुझे लगता है कि लाभ संभवतः समान हैं - डेटा का तेजी से प्रसंस्करण जब आपको केवल बड़े के एक छोटे उपसमूह को क्वेरी करने की आवश्यकता होती है स्तंभों की संख्या। मेरे पास 673 स्तंभों के साथ एवरो फ़ाइलों (एक पंक्ति उन्मुख फ़ाइल प्रारूप) के लगभग 50 टेराबाइट्स पर चलने वाली एक क्वेरी थी जो 140 नोड हडोप क्लस्टर पर लगभग एक घंटे और आधा लेती थी। Parquet के साथ, उसी क्वेरी में लगभग 22 मिनट लगे क्योंकि मुझे केवल 5 कॉलम की आवश्यकता थी।
यदि आपके पास बहुत कम संख्या में कॉलम थे या आप अपने कॉलम का एक बड़ा हिस्सा इस्तेमाल कर रहे थे, तो मुझे नहीं लगता कि एक कॉलम डेटाबेस एक पंक्ति बनाम एक अंतर से बहुत कुछ बना देगा क्योंकि आपको अभी भी मूल रूप से अपने सभी डेटा को स्कैन करना होगा। मेरा मानना है कि स्तंभ डेटाबेस अलग से कॉलम संग्रहीत करते हैं जबकि पंक्ति उन्मुख डेटाबेस अलग से पंक्तियों को संग्रहीत करते हैं। जब भी आप डिस्क से कम डेटा पढ़ने में सक्षम होते हैं, तो आपकी क्वेरी अधिक तेज़ होगी।
यह लिंक अधिक विवरण की व्याख्या करता है।
नोट: यह मेरा सवाल है, और मैं वास्तव में यहाँ अद्भुत उत्तरों के लिए आभारी हूं, जिसने मुझे अवधारणा को समझने में मदद की।
इसलिए, मैं उस अवधारणा को समझाऊंगा जिस तरह से मैंने समझा है:
आम तौर पर, डेटाबेस में डेटा मेमोरी में निम्न प्रारूपों में संग्रहीत किया जाता है:
इस डेटम पर विचार करें:
X1 X2
1 0.7091409 -1.4061361
2 -1.1334614 -0.1973846
3 2.3343391 -0.4385071
एक संबंधपरक पंक्ति-आधारित स्टोर में, इसे इस तरह संग्रहीत किया जाता है:
1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071
पंक्तियों के रूप में।
स्तंभ स्टोर में, इसे इस तरह संग्रहीत किया जाएगा:
1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071
कॉलम के रूप में।
अच्छा तो इसका क्या मतलब है?
इसका मतलब यह है कि प्रविष्टि (और अपडेट) और विलोपन पंक्ति-आधारित कॉलम स्टोर में तेज़ हैं क्योंकि यह पिछले कुछ मानों या पहले कुछ मानों को हटा रहा है। हालांकि, स्तंभ स्टोर में ऐसा नहीं है क्योंकि प्रत्येक ब्लॉक स्टोर में मूल्य को हटाने की आवश्यकता है।
हालाँकि, जब स्तंभ समुच्चय और संचालन की आवश्यकता होती है, तो स्तंभ भंडार अपने पंक्ति-आधारित समकक्षों पर बढ़त रखते हैं, क्योंकि वे कॉलम-वार संग्रहीत होते हैं, और परिणामस्वरूप, व्यक्तिगत कॉलम तक पहुंचना बहुत आसान होता है।