मेरे स्टॉक विश्लेषण रिपॉज़िटरी के पहले संस्करण ने विश्लेषण एक OLTP इंजन पर चलाया था, और दूसरा संस्करण वही वर्कलोड एक OLAP स्टैक पर चलाता है। मैंने एक ही अनुकूलन के लिए OLAP स्टैक चुना, लेकिन उसका लाभ उठाने के लिए मुझे पूरे लेकहाउस को समझना पड़ा।
InnoDB का डिज़ाइन तीन गारंटियाँ देता है, जिन्होंने मेरे शुरुआती निर्णयों को आकार दिया। यह किसी पंक्ति के सभी कॉलम एक साथ संग्रहीत करता है, इसलिए किसी एक सिंबल का एक बार लाने के लिए डिस्क पर एक ही स्थान तक पहुँच होती है, जो इनजेशन के लिए उपयुक्त है। हालाँकि, जिस इंडिकेटर को केवल दो कॉलम चाहिए, वह भी बफ़र पूल के माध्यम से सभी कॉलम पढ़ता है। इंडेक्स पढ़ने को तेज़ करते हैं, पर लिखने को धीमा करते हैं, क्योंकि हर लिखाई में तालिका के हर B-tree को अपडेट करना पड़ता है। यह चयनात्मक रीड के लिए बढ़िया है, लेकिन लिखने-भारी इनजेशन के लिए बहुत बुरा है, इसीलिए मेरी Raw* तालिकाओं में केवल प्राइमरी की है।
InnoDB एक undo log भी उपयोग करता है, जो समवर्ती रीड और राइट की अनुमति देता है। जब कोई पंक्ति अपडेट या डिलीट होती है, तो पुराना मान सहेजा जाता है ताकि दूसरे सेशन अब भी उसे पढ़ सकें। इंसर्ट के लिए छोटा undo log बनता है, जो कमिट होने पर हटा दिया जाता है। अपडेट और डिलीट के undo log एक वैश्विक इतिहास सूची में जुड़ते हैं, जिसे InnoDB तब साफ़ करता है जब कमिट से पहले शुरू हुए सभी सेशन समाप्त हो जाते हैं। इस तंत्र को Multi-Version Concurrency Control, या MVCC, कहते हैं, जो इंसर्ट और अपडेट को रीड को रोके बिना होने देता है।
मुझे इसका एहसास नहीं था, पर मैंने अपना InnoDB डेटाबेस एक OLAP बुनियाद पर डिज़ाइन कर दिया था। मेरी financialdata तालिका में तारीख-समय के साथ OHLC कीमतें थीं, और हर तकनीकी इंडिकेटर को तारीख खोजने के लिए उस पर join करना पड़ता था। यह मेरे सबसे खराब डेटा डिज़ाइनों में से एक था, और मुझे तब पता चला जब डेटाबेस में 100GB से अधिक डेटा हो गया। इसे ठीक करना बहुत कठिन था।
स्रोत: Hacker News · HeadlinesBriefing द्वारा सारांशित