कॉलम स्टोर: कॉलम आधारित डेटाबेस की तुलना

Question

मैं वास्तव में कुछ ऐसा करने में SQL सर्वर बनाने के लिए संघर्ष कर रहा हूं, जो स्पष्ट रूप से कभी नहीं होगा। मुझे अपने विश्लेषणात्मक काम के लिए डेटाबेस इंजन की आवश्यकता है। डीबी को तेज़ होने की आवश्यकता है और सामान्य डेटाबेस (SQL सर्वर, ओरेकल, डीबी 2, आदि) में पाए गए सभी लॉगिंग और अन्य ओवरहेड की आवश्यकता नहीं है

कल मैंने Michael Stonebraker speak at the Money:Tech conference की बात सुनी और मैंने सोचा, "मैं नहीं हूं वास्तव में पागल। एक बेहतर तरीका है! " वह पंक्ति उन्मुख डेटाबेस के बजाय column stores का उपयोग करने के बारे में बात करता है। मैं column stores के लिए विकिपीडिया पेज पर गया और मुझे कुछ ओपन सोर्स प्रोजेक्ट्स (जो मुझे पसंद है) और कुछ वाणिज्यिक/ओपन सोर्स प्रोजेक्ट्स (जो मैं पूरी तरह समझ नहीं पा रहा हूं) देखता हूं।

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

मैं अंततः विश्लेषण के लिए आर में डेटा खींच रहा हूं।

संपादित करें: मुझे कुछ स्पष्टीकरण के लिए अनुरोध किया गया था कि मैं वास्तव में क्या करने की कोशिश कर रहा हूं। तो, यहां एक उदाहरण दिया गया है कि मैं क्या करना चाहता हूं: ऐसी तालिका बनाएं जिसमें 4 मिलियन पंक्तियां और 20 कॉलम हों (5 dims, 15 तथ्यों)। 5 समेकन सारणी बनाएं जो प्रत्येक तथ्यों के लिए अधिकतम, न्यूनतम और औसत की गणना करें। शुरुआती तालिका में उन 5 समेकन में शामिल हों। अब औसत से प्रतिशत विचलन, न्यूनतम का विचलन, और प्रत्येक पंक्ति के लिए अधिकतम से प्रतिशत विचलन की गणना करें और इसे मूल तालिका में जोड़ें। इस तालिका डेटा को हर दिन नई पंक्तियां नहीं मिलती हैं, यह पूरी तरह से बदल जाती है और प्रक्रिया दोहराई जाती है। अगर प्रक्रिया को रोका जाना चाहिए तो स्वर्ग मना कर दें। और लॉग ... ओह, लॉग! :)

Answer 1

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

एक पंक्ति स्टोर, पारंपरिक डेटाबेस आर्किटेक्चर, पंक्तियों की छोटी संख्या डालने, पंक्तियों को अद्यतन करने और पंक्तियों की छोटी संख्या पूछने में अच्छा है। एक पंक्ति स्टोर में, इन परिचालनों को एक या दो डिस्क ब्लॉक I/Os के साथ किया जा सकता है।

विश्लेषणात्मक डेटाबेस आमतौर पर एक समय में हजारों रिकॉर्ड लोड करते हैं; कभी-कभी, आपके मामले में, वे सब कुछ पुनः लोड करते हैं। वे denormalized होते हैं, तो बहुत सारे कॉलम हैं। और क्वेरी समय पर, वे अक्सर तालिका में पंक्तियों का एक उच्च अनुपात पढ़ते हैं, लेकिन इन कॉलम में से केवल कुछ ही। इसलिए, यह एक ही कॉलम के मूल्यों को एक साथ स्टोर करने के लिए I/O दृष्टिकोण से समझ में आता है।

यह पता चला है कि यह डेटाबेस को मूल्य संपीड़न करने का एक बड़ा अवसर प्रदान करता है। उदाहरण के लिए, यदि एक स्ट्रिंग कॉलम की औसत लंबाई 20 बाइट्स है लेकिन इसमें केवल 25 विशिष्ट मान हैं, तो डेटाबेस प्रति मान के बारे में 5 बिट्स को संपीड़ित कर सकता है। कॉलम स्टोर डेटाबेस अक्सर डेटा को डिकंप्रेस किए बिना संचालित कर सकते हैं।

अक्सर कंप्यूटर विज्ञान में एक आई/ओ बनाम सीपीयू टाइम ट्रेडऑफ होता है, लेकिन कॉलम स्टोर्स में आई/ओ सुधार अक्सर संदर्भ की स्थानीयता में सुधार करते हैं, कैश पेजिंग गतिविधि को कम करते हैं, और अधिक संपीड़न कारकों की अनुमति देते हैं, ताकि सीपीयू लाभ भी प्राप्त हो सके ।

कॉलम स्टोर डेटाबेस में अन्य विश्लेषणात्मक उन्मुख विशेषताएं भी हैं जैसे कि बिटमैप इंडेक्स (फिर भी एक और मामला जहां बेहतर संगठन बेहतर संपीड़न की अनुमति देता है, I/O को कम करता है, और एल्गोरिदम को अधिक CPU-कुशल बनाता है), विभाजन, और भौतिककृत देखा गया।

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

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

Answer 2

यह एक इंटरफ़ेस परिवर्तन की बजाय एक कार्यान्वयन परिवर्तन (पंक्ति-प्रमुख क्रम के बजाय कॉलम-प्रमुख क्रम में 2-डी सरणी) जैसा दिखता है।

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

Answer 3

यदि आप [1] अपने विशिष्ट लक्ष्य और [2] उन समस्याओं को वर्णित करते हैं जो आप SQL सर्वर के साथ चल रहे हैं, तो हम आपको एक सूचित निर्णय तक पहुंचने में मदद कर सकते हैं।

Answer 4

मुझे इन्फोब्राइट समुदाय संस्करण --- कॉलम-या के साथ कुछ अनुभव है। डीएसबी, mysql पर आधारित है।

प्रो:

• आप mysql इंटरफेस/ODBC mysql ड्राइवरों, आर से उपयोग कर सकते हैं भी
• डेटा चयन के बड़ा हिस्सा पर काफी तेजी से प्रश्नों (क्योंकि KnowledgeGrid & डेटा पैक का)
• बहुत तेजी से ईटीएल (प्रतिभा, केटल) के लिए मूल डेटा लोडर और कनेक्टर
• ठीक उसी ऑपरेशन को अनुकूलित करता है जो मैं (और मुझे लगता है कि हम में से अधिकांश) (कारक स्तरों से चयन, इत्यादि) द्वारा चयन
• विशेष "देखने" अनुकूलित भंडारण आर कारक चर के लिए विकल्प;) (ठीक है, अपेक्षाकृत छोटे स्तरों संख्या/पंक्तियों संख्या के साथ चार/varchar चर)
• FOSS
• भुगतान किया समर्थन विकल्प
• ?

विपक्ष:

• कोई समुदाय संस्करण में सम्मिलित/अपडेट परिचालन (अभी तक?), केवल के माध्यम से डेटा लोड हो रहा है देशी डेटा लोडर/ईटीएल कनेक्टर्स
• कोई utf-8 आधिकारिक समर्थन (मिलान/प्रकार आदि), q3 200
• के लिए योजनाबद्ध कुल प्रश्नों में कोई फ़ंक्शन नहीं महीने (दिनांक) का चयन करें ...) फिर भी, जुलाई (?) 200 9 के लिए योजना बनाई गई है, लेकिन कॉलम स्टोरेज की वजह से, मैं बस प्रत्येक समेकन स्तर (सप्ताह संख्या, महीना, ...) के लिए दिनांक कॉलम बनाना पसंद करता हूं मुझे
की आवश्यकता है
• मौजूदा mysql सर्वर पर स्टोरेज इंजन के रूप में स्थापित नहीं किया जा सकता है (अपने ऑप्टिमाइज़र की वजह से, अगर मैं सही ढंग से समझता हूं), लेकिन अगर आपको
• की आवश्यकता है तो आप विभिन्न बंदरगाहों पर इन्फोबराइट & mysql इंस्टॉल कर सकते हैं?

फिर से शुरू करें: दैनिक विश्लेषणात्मक कार्यों के लिए अच्छा एफओएसएस समाधान, और, मुझे लगता है कि आपके कार्य भी।

Answer 5

4 मिलियन पंक्तियों के समय 20 कॉलम टाइम्स 8 बाइट्स डबल के लिए 640 एमबी है। अंगूठे के नियम के बाद कि आर प्रत्येक वस्तु के लिए तीन अस्थायी प्रतियां बनाता है, हम लगभग 2 जीबी तक पहुंचते हैं। यह आज के मानक से बहुत कुछ नहीं है।

तो यह उचित 64-बिट मशीन पर मेमोरी में 'सभ्य' राशि के साथ मेमोरी में करने योग्य होना चाहिए (8 जीबी या उससे अधिक कहें)। उबंटू या डेबियन (संभवतः सर्वर संस्करण में) को स्थापित करना कुछ ही मिनटों में किया जा सकता है।

Answer 6

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

नीचे पंक्ति: यदि आप बहुत सारे डेटा (> 1 जीबी) को स्टोर करने की योजना बना रहे हैं तो आपको कुछ ठीक से स्केल करने की ज़रूरत है, और शायद इसका मतलब कॉलम डेटाबेस है।