वाह, आप इस समस्या के लिए कुछ भयानक मांसल हार्डवेयर है। Btree खोजों में से 20-50% बेहतर प्रदर्शन के लिए शायद सैंडी / आइवी ब्रिज सीपीयू को अपग्रेड करने के अपवाद के साथ, आप इसे हार्डवेयर के हिसाब से नहीं फेंक सकते।
कृपया ध्यान दें कि मेरा कांटा इनोडब है, इसलिए मैं जा रहा हूं
- इस बात पर ध्यान न दें कि आप मायसम हैं और ऐसा काम करते हैं जैसे कि इससे कोई फर्क नहीं पड़ेगा।
- यह मान लें कि आपको अपग्रेड करने के लिए पर्याप्त समस्या है। हाँ, यह एक उन्नयन है।
इनोडब अपने बफ़र पूल में इन अक्सर एक्सेस की गई पंक्तियों को संग्रहीत करके उस सभी मेमोरी का बहुत फायदा उठा सकता है। आप इसे जितना चाहें उतना बड़ा होने के लिए ट्यून कर सकते हैं (80% मेमोरी कह सकते हैं) और ताज़ा रीड / राइट मेमोरी में रहते हैं जब तक कि उन्हें नवीनतम एक्सेस किए गए डेटा के लिए अधिक जगह बनाने के लिए डिस्क पर पुश करने की आवश्यकता न हो। मेमोरी में आपके फ्यूजनियो की तुलना में तेजी से परिमाण का क्रम होता है।
कई और अधिक इनोडब विशेषताएं हैं, जैसे कि अनुकूली हैश, ऑटो-इंक लॉकिंग तंत्र, आदि जो आपके पर्यावरण के लिए एक वरदान हो सकते हैं। हालाँकि, आप अपने डेटा को मुझसे बेहतर जानते हैं।
निर्दोष दुनिया में, आपके दास को अनुकूलित करने के लिए एक अच्छा अल्पकालिक समाधान है - क्या आपको वास्तव में अपने दास पर हर सूचकांक की आवश्यकता है जो आपके स्वामी पर है? इंडेक्स आवेषण / अपडेट / डिलीट पर एक बॉल और चेन हैं, फ्यूजन IO कार्ड के साथ EVEN । IOPS यहाँ सब कुछ नहीं हैं। सैंडी / आइवी पुल प्रॉक्स में मेमोरी मेमोरी और कंप्यूटिंग प्रदर्शन बेहतर है - वे अब आपके पास वेस्टमेर्स का एक बड़ा अंतर बना सकते हैं। (चित्रा 20-50% समग्र)। उन सभी अनुक्रमणिकाओं को हटा दें जिनकी आपको दास पर आवश्यकता नहीं है!
दूसरा, और लगभग निश्चित रूप से केवल निर्दोष पर लागू होता है, यह है कि एमके-प्रीफैच पता कर सकता है कि कौन से अपडेट और इससे पहले कि दास उन्हें लिखते हैं। यह एमके-प्रीफैच को पहले एक रीड क्वेरी चलाने के लिए अनुमति देता है, जिससे डेटा को उस समय तक मेमोरी में रहने के लिए मजबूर किया जाता है जब तक कि सिंगल रिप्लाई राइट क्वेरी को चलाता है। इसका मतलब यह है कि डेटा मेमोरी में है और फ्यूजनियो में नहीं, परिमाण प्रदर्शन लाभ का एक त्वरित क्रम है। यह एक बड़ा अंतर बनाता है , एक से अधिक की उम्मीद कर सकते हैं। बहुत सारी कंपनियां इसका स्थायी समाधान के रूप में उपयोग करती हैं। पेरकोना टूलकिट की जाँच करके अधिक जानकारी प्राप्त करें ।
तीसरा, और सबसे महत्वपूर्ण बात, एक बार जब आप इनोडब में अपग्रेड हो जाते हैं, तो निश्चित रूप से टोकुटेक चेकआउट करें। इन लोगों के पास कुछ दुष्ट भयानक चीजें हैं जो लंबे शॉट द्वारा इनोडब के प्रदर्शन / अपडेट / डिलीट को पार कर जाते हैं। उन्होंने प्रमुख लाभों में से एक के रूप में प्रतिकृति गति में सुधार किया, और आप अपने बेंचमार्क से देख सकते हैं कि फ्यूज़्स पागल आईओपीएस अभी भी बीटीएस के मामले में आपकी मदद नहीं करेगा । (नोट: मेरे द्वारा स्वतंत्र रूप से सत्यापित नहीं किया गया है।) वे btree इंडेक्स की जगह एक ड्रॉप-इन का उपयोग करते हैं, जो कि अधिक जटिल होते हुए, btree इंडेक्स की एल्गोरिथम गति सीमाओं के कई को संशोधित करता है।
मैं टोकुटेक को अपनाने पर विचार करने की प्रक्रिया में हूं। यदि वे इतनी गति लिखते हैं, तो मुझे अधिक इंडेक्स जोड़ने की अनुमति मिलती है। चूंकि वे ऐसे अद्भुत अनुपात (25x वे बोली) पर डेटा और इंडेक्स को संपीड़ित करते हैं, आप बढ़े हुए डेटा के लिए एक (प्रदर्शन, रखरखाव) कीमत भी नहीं देते हैं। आप उनके इंजन के लिए ($) भुगतान करते हैं, $ 2500 / वर्ष प्रति प्री-कम्प्रेस्ड जीबी, IIRC। यदि आपके पास डेटा प्रतिकृति है, तो उनके पास छूट है, लेकिन आप बस अपने दास पर टोकुटेक स्थापित कर सकते हैं और अपने स्वामी को अपने पास रख सकते हैं। एमआईटी अल्गोरिटम्स ओपन कोर्टवेयर व्याख्यान में तकनीकी विवरण देखें । वैकल्पिक रूप से, उनके पास अपने ब्लॉग पर बहुत सारे तकनीकी सामान हैं और उन लोगों के लिए नियमित रूप से श्वेतपत्र हैं जिनके पास वीडियो देखने के लिए 1:20 नहीं है। मेरा मानना है कि यह वीडियो बिग-ओ का फॉर्मूला भी बताता है कि कितनी तेजी से पढ़ता है। मेरे पास हैयह मान लेना कि रीड धीमी हैं (हमेशा एक ट्रेडऑफ़ है!), लेकिन फॉर्मूला मेरे लिए बहुत जटिल है कि मुझे कितना गेज करना चाहिए। वे दावा करते हैं कि यह लगभग एक ही है, लेकिन मैं गणित को समझना चाहता हूँ (संभावना नहीं!)। आप इससे बेहतर स्थिति में हो सकते हैं कि मैं यह जान सकूं।
Ps मैं टोकुटेक से संबद्ध नहीं हूं, मैंने कभी भी उनके उत्पाद को नहीं चलाया है और वे यह भी नहीं जानते कि मैं उन्हें देख रहा हूं।
अपडेट :
मैं देख रहा हूँ कि आपके पास इस पृष्ठ पर कुछ अन्य प्रश्न हैं और मैंने सोचा कि मैं इसमें चिप लगाऊंगा:
सबसे पहले, गुलाम पूर्व-भ्रूण लगभग निश्चित रूप से मायसम के लिए काम नहीं करेगा जब तक कि आपके पास एक असाधारण वातावरण न हो। यह ज्यादातर इसलिए है क्योंकि प्रीफेचिंग आपके द्वारा लिखने का इरादा रखने वाले बहुत तालिकाओं को लॉक कर देगा, या गुलाम धागे में उस तालिका को बंद कर दिया गया है जो पूर्व-भ्रूण की आवश्यकता है। यदि आपकी टेबल प्रतिकृति के लिए बहुत अच्छी तरह से संतुलित हैं और एक गोल-रॉबिन फैशन में अलग-अलग तालिकाओं को लिखा जा रहा है, तो यह काम कर सकता है - लेकिन ध्यान रखें कि यह बहुत सैद्धांतिक है। "उच्च प्रदर्शन मैसकल" पुस्तक में "प्रतिकृति समस्याएं" अनुभाग में अधिक जानकारी है।
दूसरा, संभवतः आपका दास 1.0-1.5 का भार रखता है, यदि आपके पास अन्य प्रोक्स या क्वेरी चल रही हैं, लेकिन 1.0 की आधार रेखा है तो यह अधिक हो सकती है। इसका मतलब है कि आप सीपीयू से बंधे हुए हैं, जो कि बोर्ड पर आपके फ्यूजनियो के साथ होने की संभावना है। जैसा कि मैंने पहले उल्लेख किया है, सैंडी / आइवी ब्रिज थोड़ा अधिक ऑम्फ देने जा रहा है, लेकिन संभवतः आपको कम से कम अंतराल के माध्यम से प्राप्त करने के लिए पर्याप्त नहीं है। यदि इस गुलाम पर लोड ज्यादातर राइट-ओनली है (यानी बहुत पढ़े लिखे नहीं हैं), तो आपका सीपीयू लगभग निश्चित रूप से खर्च कर रहा है, यह समय बीट्री इंसर्शन / डिलीशन के लिए पोजिशन कैलकुलेट करने का है। यह गैर-महत्वपूर्ण अनुक्रमित को हटाने के बारे में ऊपर मेरी बात को सुदृढ़ करना चाहिए - आप बाद में उन्हें हमेशा जोड़ सकते हैं। हाइपरथ्रेडिंग को अक्षम करने से काम नहीं चलेगा, अधिक सीपीयू आपका दुश्मन नहीं है। एक बार जब आप 32GB रैम से ऊपर हो जाते हैं, तो 64GB बोलें, आपको रैम वितरण के बारे में चिंता करने की आवश्यकता है, लेकिन फिर भी लक्षण अलग हैं।
अंत में, और सबसे महत्वपूर्ण बात (इस भाग को छोड़ें; हालांकि - यहां और भी अधिक प्रदर्शन प्राप्त करने का एक तरीका हो सकता है। यदि आपके पास कोई प्राथमिक कुंजी नहीं है, तो मैसकल बग 53375 प्रकट हो सकता है। दास मूल रूप से कुछ भी, लेकिन एक प्राथमिक कुंजी का उपयोग करने के लिए पर्याप्त रूप से स्मार्ट नहीं है, इसलिए अनुपस्थिति प्रत्येक अद्यतन के लिए एक पूर्ण तालिका स्कैन करने के लिए प्रतिकृति थ्रेड को बाध्य करता है। एक फिक्स बस एक सौम्य जोड़ रहा है, सरोगेट autoincrementing प्राथमिक कुंजी। मैं केवल यह करूँगा यदि तालिका बड़ी थी (कई पंक्तियों को हजारों पंक्तियों या बड़े कहो)। यह निश्चित रूप से, मेज पर एक और सूचकांक होने की लागत पर आता है, जो सीपीयू में आपके द्वारा भुगतान की गई कीमत को लाता है। ध्यान दें कि इसके खिलाफ बहुत कम सैद्धांतिक तर्क हैं, जैसे कि यदि आप नहीं करते हैं, तो InnoDB दृश्यों के पीछे एक जोड़ देता है। प्रेत एक, तथापि, 53375. टंगस्टन के खिलाफ एक उपयोगी रक्षा भी इस समस्या को दूर कर सकते हैं नहीं है, लेकिन आप की जरूरत है जब टंगस्टन का उपयोग कर आप अपने एन्कोडिंग सीधे है सुनिश्चित करने के लिए। पिछली बार जब मैं इसके साथ खेलता था, तब यह बुरी तरह से मर जाता था जब किसी भी गैर-यूटीएफ 8 स्ट्रिंग की प्रतिकृति की आवश्यकता होती थी। यह उस समय के बारे में है जब मैंने उस पर ध्यान दिया।
