पढ़ें और लिखें) MyISAM सीधे

Dev.mysql.com पर MySQL के डॉक्यूमेंटेशन के बॉल्स में, मैंने किसी तरह एक उल्लेख पाया कि यदि MyISAM का उपयोग किया जाता है, तो आप तालिका से डेटा को पढ़ने की गति में 5-7 गुना वृद्धि कर सकते हैं यदि आप तालिका से डेटा स्वयं पढ़ते हैं। लंबे समय से मैं इस तथ्य को सत्यापित करना चाहता था, और अब, आखिरकार, मेरे हाथ इसे आज़माने के लिए पहुंच गए। यह क्या आया, कटौती के तहत पढ़ा

MyISAM से हम किस प्रकार का डेटा पढ़ेंगे?

MyISAM प्रारूप, वास्तव में, कई प्रारूप (अर्थात्, अनुक्रमणिका के लिए कई प्रारूप और डेटा संग्रहण के कई प्रकार, डेटा के लिए सबसे सामान्य निश्चित और गतिशील हैं)। मैं सबसे सरल मामले पर विचार करने में दिलचस्पी रखता था: जब किसी तालिका में एक निश्चित रिकॉर्ड लंबाई होती है, जिसमें NULL फ़ील्ड नहीं होते हैं, और हम जिस प्रकार के प्रश्नों का परीक्षण करने जा रहे हैं, वह अनुक्रमणिका और अन्य तालिकाओं की भागीदारी के बिना एक सरल चयन * FULL tbl WHERE (शर्त) है (तब, पूर्ण स्कैन कहा जाता है)।

क्यों?

मूल रूप से, मैं खेल रुचि से प्रेरित था। फिर भी, परिणाम काफी अच्छे निकले, इसलिए शायद मेरे अलावा कोई और इस पद्धति को व्यवहार में लाने की कोशिश करना चाहे।

हम कैसे पढ़ेंगे?

प्रारंभ में, मैंने अनुक्रमित का उपयोग करते हुए, MyISAM से डेटा पढ़ने के तरीके के लिए काफी कुछ विकल्पों पर विचार किया। इंडेक्स फ़ाइलों से सीधे पढ़ने के लिए, myisam.txt फ़ाइल में एक बहुत अच्छा वर्णन है, जिसे MySQL स्रोत कोड के साथ वितरित किया जाता था, लेकिन अब यह पाया जा सकता है, उदाहरण के लिए, MariaDB में । एक प्रोग्राम के लिए जो सूचकांक संरचनाओं के साथ MyISAM पढ़ना चाहता है, आपको संभवतः MySQL का एक ठोस भाग बनाने की आवश्यकता है। यह अच्छा है कि इसे केवल एक बार किया जाना चाहिए :)।

मैं एक स्टैंडअलोन एप्लिकेशन पर विचार करूंगा जो MySQL के स्रोत कोड पर निर्भर नहीं करता है और अनुक्रमित का उपयोग नहीं करता है, लेकिन केवल सबसे सरल, निश्चित, स्ट्रिंग प्रारूप में सीधे .MYD फ़ाइलों को पढ़ता है।

.MYD में संग्रहण प्रारूप

विभिन्न MyISAM संरचनाओं के लिए भंडारण प्रारूप यहाँ बहुत अच्छी तरह से वर्णित है: forge.mysql.com/wiki/MySQL_Internals_MyISAM । निश्चित रेखाओं का प्रारूप इतना सरल है कि इसे सीधे लेख के पाठ में सूचीबद्ध किया जा सकता है:

1) .MYD में लगातार लाइनें होती हैं, और उनमें से केवल। कोई ओवरहेड नहीं है .MYD
2) प्रत्येक पंक्ति में एक हेडिंग होती है जिसमें NULL फ़ील्ड्स के बारे में जानकारी होती है और यह दर्शाता है कि लाइन हटा दी गई है। यदि कोई NULL फ़ील्ड नहीं हैं, तो शीर्ष लेख की लंबाई 1 बाइट है
3) पंक्ति में, फ़ील्ड द्विआधारी प्रारूप में हैं, उस क्रम में जिसमें तालिका के क्षेत्र परिभाषित होते हैं, रिवर्स बाइट क्रम में (थोड़ा एंडियन), बिना अंतराल के

MySQL के विभिन्न प्रकारों के लिए, द्विआधारी प्रतिनिधित्व अलग है, और इसे उपरोक्त लिंक पर खूबसूरती से वर्णित किया गया है

कैसे .MYD से पढ़ें

यह मानते हुए कि आप C प्रोग्राम से .MYD का डेटा पढ़ने जा रहे हैं, यहाँ मेरे कार्यान्वयन से कुछ दिलचस्प बिंदु हैं जो प्रदर्शन से संबंधित हैं:

1) यदि एक पंक्ति की लंबाई छोटी है (कहो, 10 बाइट्स), तो फ़्रेड का उपयोग करते समय भी () यह केवल एक पंक्ति को पढ़ने के लायक नहीं है, लेकिन, कहते हैं, 100 - मेरे कार्यक्रम के लिए, इस फ़ाइल से 2 बार कहीं से पढ़ने में तेजी आई।
2) सबसे अधिक संभावना है, व्यक्तिगत क्षेत्रों तक पहुंच संरेखित नहीं की जाएगी, इसलिए, यदि आपकी वास्तुकला x86 (उदाहरण के लिए, पीपीसी) से अलग है, तो आपको एक विशिष्ट क्षेत्र को बाहर निकालने के लिए निम्नलिखित सरल निर्माण का उपयोग नहीं करना चाहिए: * (int *) ( ptr) (ptr क्षेत्र की शुरुआत के लिए एक संकेतक है, क्षेत्र एक ही समय में, प्रकार का है int)

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

क्या आपने रिकॉर्डिंग के बारे में कुछ कहा?

हां, एक निश्चित पंक्ति प्रारूप वाला MyISAM इतना सरल है कि हम खुद MySQL के लिए टेबल बना सकते हैं और उन्हें डेटा के साथ पॉप्युलेट कर सकते हैं। जब तक, सूचकांक के बिना। लेकिन उन्हें हमेशा ज़रूरत नहीं होती है, और अगर उनकी बहुत ज़रूरत है, तो आप बाद में MySQL से उन्हें ALTER TABLE के माध्यम से बनाने के लिए कह सकते हैं।

हमें क्या चाहिए?

जैसा कि आप जानते हैं, MyISAM तालिकाओं में 3 फाइलें होती हैं: .frm, .MYI और .MYD। हम जनरेट करना जानते हैं। यह .frm और .MYI उत्पन्न करने के लिए रहता है। आप शायद पूछते हैं: हमें इसकी आवश्यकता क्यों है। क्या अनुक्रमणिका वहां संग्रहीत नहीं हैं (जो हम योजना नहीं बनाते हैं)? वास्तव में, न केवल अनुक्रमित वहाँ संग्रहीत हैं। इसके बारे में बाद में।

जनरेट करने का सबसे आसान तरीका .frm और .MYI इन फाइलों को किसी तरह के "डोनर" यानी दूसरी टेबल से लेना है। इस तालिका में अनुक्रमित नहीं होना चाहिए, और इस तालिका में एक संरचना होनी चाहिए जो हमारी .MYD फ़ाइल से मेल खाती है, अन्यथा MySQL ऐसी तालिका को पढ़ने में सक्षम नहीं होगी :)।

यदि आप बस समाप्त तालिका से .frm और .MYI फ़ाइलों को कॉपी करते हैं और आवश्यक पंक्तियों को .MYD पर लिखते हैं, तो सबसे अधिक संभावना है कि आप देखेंगे कि MySQL का मानना ​​है कि नव-निर्मित तालिका में 0 पंक्तियाँ हैं। इससे हमें यह सोचना चाहिए कि MyISAM में सब कुछ इतना आसान नहीं है :)। वास्तव में, एक अच्छी तरह से ज्ञात तथ्य है - MyISAM तालिकाओं में उन पंक्तियों की संख्या के बारे में जानकारी है जो इस तालिका की संरचना के क्षेत्रों में से एक में है। यह इस क्षेत्र को खोजने के लिए बनी हुई है और बात टोपी में है :)! विचित्र रूप से पर्याप्त है, यह फ़ील्ड .mm फ़ाइल में नहीं है, लेकिन .MYI में है। हां, बहुत फाइल में जिसमें "इंडेक्स" हैं। उसी स्थान पर, एक और मेटा जानकारी है जो MyISAM के लिए विशिष्ट है और इसे .frm फ़ाइल में नहीं लिखा गया है (.frm कई प्रकार की तालिकाओं के लिए आम है)।

MyISAM प्रारूप के उपरोक्त विवरण में, MYI फ़ाइलों का वर्णन है। वास्तव में, हमारे लिए इस फ़ाइल में केवल 2 फ़ील्ड को फिर से लिखना है (MySQL संस्करण 5.1 के लिए):
1) राज्य-> State.records (फ़ाइल की शुरुआत के सापेक्ष ऑफसेट - 0x1C, लंबाई 8 बाइट्स, प्रत्यक्ष बाइट ऑर्डर (बड़ा एंडियन), कुल संख्या में से शून्य से हटाई गई लाइनें शामिल हैं)
2) स्थिति-> state.data_file_length (फ़ाइल की शुरुआत के सापेक्ष ऑफसेट - 0x44, लंबाई 8 बाइट्स, प्रत्यक्ष बाइट ऑर्डर (बड़ा एंडियन), बाइट्स में .MYD फ़ाइल का आकार शामिल है)।

यदि आप "नव निर्मित" तालिकाओं को पढ़ने में समस्याओं का सामना करते हैं, तो आपको पहले यह देखना चाहिए कि आप मौजूदा तालिका को फिर से नहीं लिख रहे हैं, लेकिन एक नया निर्माण कर रहे हैं। यदि आप पुराने के बजाय एक तालिका लिखना चाहते हैं, तो आपको पहले MySQL से सीधे इस तालिका का एक DROP टेबल बनाना होगा, और उसके बाद ही इस तालिका को फिर से बनाएं (ताकि MySQL गलती से खुली फ़ाइलों का कैश न खोले)। एक अन्य विकल्प इस तालिका के लिए एक फ्लश टेबल बनाना है और फिर वहां नया डेटा लिखना (उपयोगी है यदि आप टेबल पर APPEND कर रहे हैं)।

परिणाम

इसलिए, यदि आप लेख को अंत तक पढ़ते हैं (और यदि आप सी जानते हैं), तो आपके पास सी में एक कार्यक्रम लिखने के लिए पर्याप्त ज्ञान होना चाहिए जो स्वयं को सरल रूप से पढ़ता है और लिखता है। अपने प्रोग्राम का उपयोग करके जिन प्रश्नों को आप निष्पादित करना चाहते हैं, उनकी जटिलता के आधार पर, गति में वृद्धि 5-6 गुना तक हो सकती है। मैं एक कार्यक्रम लिखने में कामयाब रहा, जिसने कुछ उपयोगी किया, पूरे MyISAM तालिका को पढ़ने, एक समय में जो MySQL में सीधे उसी क्वेरी के निष्पादन का 1/4 था। मेरी राय में बुरा नहीं है। वैसे, प्रोग्राम केवल ~ 5 Kb और ~ 150 सी कोड की निकला।

तो, यदि आपको अचानक सुपर-उच्च प्रदर्शन पूर्ण स्कैन की आवश्यकता है, तो तालिका से पढ़ने के लिए MyISAM + अपने C प्रोग्राम को आज़माएं। आपको सुखद आश्चर्य होगा कि इसे लागू करना कितना आसान है, और कितना कम रक्त आप कई बार पठन प्रदर्शन को बढ़ा सकते हैं।

युपीडी
क्या आपने नंबर मांगे? यहाँ आपके लिए थोड़ा सा है:

1. संख्या कार्यान्वयन पर बहुत निर्भर होगी। मैंने पहले ही लिखा था कि मुझे 4 बार अनुरोध की गति बढ़ाने में कामयाबी मिली। 25 बाइट्स के आकार के साथ कुल रीड स्पीड 1 Gb / s थी
2. हैण्डलर या SELECT का उपयोग करने पर FULL SCAN के साथ कोई अंतर नहीं पाया गया।
MyISAM में FULL SCAN, मेरे अनुमान के अनुसार, रीड की गति देता है, InnoDB में FULL SCAN की तुलना में कम से कम 3-4 गुना अधिक।
3. अपने आप में, MyISAM में FULL SCAN समान संख्या में रिकॉर्ड के साथ इंडेक्स द्वारा स्कैनिंग की तुलना में 5-10 गुना तेजी से काम करता है (यदि आप चाहें, तो बैकलॉग को 2-3 बार तक कम किया जा सकता है)।
4. InnoDB में, एक प्राथमिक कुंजी स्कैन एक पूर्ण स्कैन के रूप में तेजी से काम करता है, किसी भी अन्य सूचकांक पर एक स्कैन लगभग 3-4 बार धीमी गति से काम करता है।

NoSQL के साथ तुलना करने से बहुत मतलब नहीं है अगर FULL SCAN एक बड़ी तालिका के लिए बनाया गया है:

1. Memcached को पूरा SCAN मैमोरी कैसे करना है पता नहीं है।
2. हैंडलरबोर्ड, हालांकि यह पूर्ण स्कैन कर सकता है, लेकिन SELECT / HANDLER की गति अलग नहीं है (यदि कई लाइनें हैं)। इसके अलावा, यह MySQL 5.1 में समर्थित नहीं है।
3. मानगो, रेडिस, आदि ने अधिक स्मृति / भंडारण के एक आदेश पर कब्जा कर लिया है, जो कई मामलों में बिल्कुल अस्वीकार्य है। वे जल्दी से काम करते हैं, कोई संदेह नहीं है। लेकिन उनका उद्देश्य अलग है