आपका स्वागत है! मेरा नाम Maxim Matyukhin है, मैं PHP में PHP प्रोग्रामर हूँ । हमारे काम में, हम सक्रिय रूप से MySQL का उपयोग करते हैं। लेकिन कभी-कभी हमें इसके प्रदर्शन की कमी होती है, इसलिए हम लगातार इसके काम को गति देने के तरीकों की तलाश कर रहे हैं।

2010 में, Yoshinori Matsunobu ने हैंडलर सॉकेट नामक NoSQL MySQL प्लगइन पेश किया। यह दावा किया गया था कि यह प्लगइन आपको प्रति सेकंड 750,000 से अधिक अनुरोध करने की अनुमति देता है। हम उत्सुक हो गए, और लगभग तुरंत हमने इस समाधान का उपयोग करना शुरू कर दिया। हमें परिणाम इतना पसंद आया कि हमने प्रस्तुतियाँ करना शुरू कर दिया और हैंडलरकेट को बढ़ावा देने वाले लेख लिखने लगे।

जाहिरा तौर पर, हम इस प्लगइन के कुछ उपयोगकर्ताओं में से एक थे - MySQL 5.7 के बाद से इसने काम करना बंद कर दिया। लेकिन इस संस्करण में ओरेकल से एक और प्लगइन दिखाई दिया - इनोबीडी मेमेकैच्ड प्लगइन, जिसने समान कार्यक्षमता का वादा किया था।

इस तथ्य के बावजूद कि 2013 में MySQL 5.6 में मेम्केच्ड प्लगइन दिखाई दिया था, इसके बारे में बहुत सारे लेख नहीं हैं और अधिकांश भाग के लिए वे दस्तावेज़ीकरण दोहराते हैं: एक साधारण लेबल बनाया गया है और इसके लिए अनुरोध किए गए क्लाइंट के माध्यम से किया जाता है।

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

MySQL हैंडलर सॉकेट

इस लेख में, हम एक नए तरीके से पुराने हैंडलर सॉकेट के साथ नए मेमेक किए गए प्लगइन की तुलना करेंगे। इसलिए, मुझे याद है कि यह उत्तरार्द्ध था।

हैंडलर सॉकेट प्लगइन स्थापित करने के बाद, MySQL ने दो अतिरिक्त पोर्ट सुनना शुरू किया:

पहला पोर्ट डेटा पढ़ने के लिए क्लाइंट अनुरोध प्राप्त करता है।
दूसरा पोर्ट डेटा रिकॉर्डिंग के लिए क्लाइंट अनुरोध प्राप्त करता है।

क्लाइंट को इनमें से किसी एक पोर्ट पर एक सामान्य टीसीपी कनेक्शन स्थापित करना था (कोई प्रमाणीकरण समर्थित नहीं था), और उसके बाद "ओपन इंडेक्स" कमांड (एक विशेष कमांड जिसके साथ क्लाइंट ने सूचित किया था कि किस इंडेक्स में हम किस फील्ड में जा रहे हैं। पढ़ें (या लिखें)।

यदि "ओपन इंडेक्स" कमांड सफलतापूर्वक काम करता है, तो आप उस पोर्ट के आधार पर GETs या INSERT / UPDATE / DELETE कमांड भेज सकते हैं जिससे कनेक्शन स्थापित किया गया था।

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

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

एक ही समय में, यह अभी भी एक साधारण MySQL सर्वर है - हमारे लिए परिचित एक तकनीक। हम जानते हैं कि इसे कैसे दोहराया और मॉनिटर किया जाए। हैंडलर सॉकेट की निगरानी करना मुश्किल है क्योंकि यह कोई विशिष्ट मैट्रिक्स प्रदान नहीं करता है; हालाँकि, कुछ मानक MySQL और InnoDB मैट्रिक्स उपयोगी हैं।

बेशक, असुविधाएं थीं, विशेष रूप से, यह प्लगइन टाइमस्टैम्प प्रकार के साथ काम करने का समर्थन नहीं करता था। खैर, हैंडलरसॉकेट प्रोटोकॉल पढ़ना मुश्किल है और इसलिए डीबग करना कठिन है।

हैंडलरसॉकेट के बारे में यहाँ और पढ़ें। आप हमारी एक प्रस्तुति भी देख सकते हैं।

InnoDB मेमस्कैल्ड प्लगइन

नया मेमॉक्ड प्लगइन हमें क्या प्रदान करता है?

जैसा कि नाम से ही स्पष्ट है कि उनका विचार MySQL के साथ काम करने के लिए और मेमॉक्ड कमांड्स के माध्यम से डेटा प्राप्त करने और सहेजने के लिए मेम्केड क्लाइंट का उपयोग करना है।

आप यहां प्लगइन के मुख्य लाभों के बारे में पढ़ सकते हैं ।

हम निम्नलिखित में सबसे अधिक रुचि रखते हैं:

सीपीयू की कम खपत।
डेटा को InnoDB में संग्रहीत किया जाता है, जो कुछ गारंटी देता है।
आप मेमकाटेड और एसक्यूएल के माध्यम से डेटा के साथ काम कर सकते हैं; उन्हें MySQL बिल्ट-इन टूल्स का उपयोग करके दोहराया जा सकता है।

आप इस सूची में ऐसे प्लस जोड़ सकते हैं:

तेज और सस्ता कनेक्शन। एक नियमित MySQL कनेक्शन को एक थ्रेड द्वारा संसाधित किया जाता है, और थ्रेड्स की संख्या सीमित होती है, और मेम्केच्ड प्लगइन में, एक थ्रेड इवेंट लूप में सभी कनेक्शनों को संसाधित करता है।
एक GET अनुरोध के साथ कई कुंजियों का अनुरोध करने की क्षमता।
यदि MySQL HandlerSocket के साथ तुलना की जाती है, तो मेमस्कैलेटेड प्लगइन में "ओपन टेबल" कमांड का उपयोग करना आवश्यक नहीं है और सभी पढ़ने और लिखने के संचालन एक ही पोर्ट पर होते हैं।

प्लगइन के बारे में अधिक जानकारी आधिकारिक दस्तावेज में पाई जा सकती है। हमारे लिए, सबसे उपयोगी पृष्ठ थे:

प्लगइन स्थापित करने के बाद, MySQL पोर्ट 11211 (मानक मेमेकटेड पोर्ट) पर कनेक्शन स्वीकार करना शुरू कर देता है। एक विशेष डेटाबेस (स्कीमा) innodb_memcache भी दिखाई देता है, जिसमें आप अपनी तालिकाओं तक पहुंच को कॉन्फ़िगर करेंगे।

सरल उदाहरण है

मान लीजिए कि आपके पास पहले से ही एक मेज है जिसे आप मेमेकैल्ड प्रोटोकॉल के माध्यम से काम करना चाहते हैं:

CREATE TABLE `auth` (  `email` varchar(96) NOT NULL,  `password` varchar(64) NOT NULL,  `type` varchar(32) NOT NULL DEFAULT '',  PRIMARY KEY (`email`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

और आप प्राथमिक कुंजी पर डेटा प्राप्त करना और संशोधित करना चाहते हैं।

आपको पहले छोड़ी गई कुंजी और SQL तालिका के बीच निर्दोष_memcache.container तालिका के बीच पत्राचार का वर्णन करने की आवश्यकता है। यह तालिका कुछ इस तरह दिखती है (मैंने इसे पढ़ने के लिए आसान बनाने के लिए एन्कोडिंग विवरण हटा दिया):

 CREATE TABLE `containers` ( `name` varchar(50) NOT NULL, `db_schema` varchar(250) NOT NULL, `db_table` varchar(250) NOT NULL, `key_columns` varchar(250) NOT NULL, `value_columns` varchar(250) DEFAULT NULL, `flags` varchar(250) NOT NULL DEFAULT '0', `cas_column` varchar(250) DEFAULT NULL, `expire_time_column` varchar(250) DEFAULT NULL, `unique_idx_name_on_key` varchar(250) NOT NULL, PRIMARY KEY (`name`) ) ENGINE=InnoDB DEFAULT

सबसे महत्वपूर्ण क्षेत्र:

नाम - आपकी Memcached कुंजी का उपसर्ग;
db_schema - आधार (सर्किट) का नाम;
db_table आपकी तालिका है;
key_columns - तालिका में फ़ील्ड का नाम जिसके द्वारा हम खोज करेंगे (आमतौर पर यह आपकी प्राथमिक कुंजी है);
value_columns - तालिका से फ़ील्ड की एक सूची जो कि मेमस्कैल्ड प्लगइन के लिए उपलब्ध होगी;
unique_idx_name_on_key इंडेक्स है जिसे देखने के लिए (हालाँकि आपने पहले से ही key_columns को निर्दिष्ट किया है, वे अलग-अलग इंडेक्स में हो सकते हैं और आपको इंडेक्स को स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता है)।

शेष क्षेत्र एक शुरुआत के लिए बहुत महत्वपूर्ण नहीं हैं।

हमारी तालिका का विवरण innodb_memcache.containers में जोड़ें:

 INSERT INTO innodb_memcache.containers SET   name='auth',   db_schema='test',   db_table='auth',   key_columns='email',   value_columns='password|type',   flags='0',   cas_column='0',   expire_time_column='0',   unique_idx_name_on_key='PRIMARY';

इस उदाहरण में, नाम = 'विशेषाधिकार' हमारी स्वीकृत कुंजी का उपसर्ग है। प्रलेखन में इसे अक्सर टेबल_ड कहा जाता है, और बाद में लेख में मैं इस शब्द का उपयोग करूंगा।

अब TELNET मेमेकटेड प्लगइन से कनेक्ट होता है और डेटा को बचाने और पाने की कोशिश करता है:

 [21:26:22] maxm@localhost: ~> telnet memchached-mysql.dev 11211 Trying 127.0.0.1... Connected to memchached-mysql.dev. Escape character is '^]'. get @@auth.max@example.com END set @@auth.max@example.com 0 0 10 1234567|89 STORED get @@auth.max@example.com VALUE @@auth.max@example.com 0 10 1234567|89 END

पहले हमने एक GET अनुरोध भेजा, इससे हमें कुछ भी वापस नहीं मिला। फिर हमने SET अनुरोध के साथ डेटा को सहेजा, जिसके बाद हमने इसे GET के साथ वापस कर दिया।

GET ने निम्न पंक्ति लौटा दी: 1234567 | 89 | ये "पासवर्ड" और "टाइप" फ़ील्ड के मान हैं, जिन्हें "|" प्रतीक द्वारा अलग किया गया है। फ़ील्ड्स उस क्रम में लौटाए जाते हैं जो उन्हें innodb_memcache.containers.value_columns में वर्णित किया गया था।

शायद आप अब सोच रहे हैं: "क्या होगा अगर प्रतीक" | "" पासवर्ड "में मिला है?" मैं इसके बारे में नीचे बात करूंगा।

SQL के माध्यम से, यह डेटा भी उपलब्ध है:

 MySQL [(none)]> select * from auth where email='max@example.com'; +-----------------+----------+------+ | email      | password | type | +-----------------+----------+------+ | max@example.com | 1234567  | 89 | +-----------------+----------+------+ 1 row in set (0.00 sec)

डिफ़ॉल्ट तालिका_द

इस तरह के ऑपरेशन का एक तरीका भी है:

 get @@auth VALUE @@auth 0 21 test/auth END get max@example.com VALUE max@example.com 0 10 1234567|99 END set ivan@example.com 0 0 10 qwerty|xxx STORED get ivan@example.com VALUE ivan@example.com 0 10 qwerty|xxx END

इस उदाहरण में, get@@ Cort के साथ, हम इस कनेक्शन के लिए डिफ़ॉल्ट उपसर्ग table_id को बनाते हैं। उसके बाद, सभी बाद के प्रश्नों को टेबल_आईडी निर्दिष्ट किए बिना किया जा सकता है।

अब तक, सब कुछ सरल और तार्किक है। लेकिन अगर आप समझना शुरू करते हैं, तो कई बारीकियां हैं। हम आपको बताएंगे कि हमने क्या पाया।

बारीकियों

कैशिंग innodb_memcache.containers तालिका

स्‍पष्‍ट किए गए प्‍लग इनबॉक्स में एक बार innodb_memcache.containers तालिका पढ़ता है। इसके अलावा, यदि कोई अज्ञात table_id मेमकेच्ड प्रोटोकॉल के माध्यम से आता है, तो प्लगइन तालिका में इसे खोजता है। इसलिए, आप आसानी से नई कुंजियाँ जोड़ सकते हैं (table_id), लेकिन यदि आप किसी मौजूदा table_id की सेटिंग बदलना चाहते हैं, तो आपको मेमस्कैलेट किए गए प्लगइन को पुनः आरंभ करना होगा:

 mysql> UNINSTALL PLUGIN daemon_memcached; mysql> INSTALL PLUGIN daemon_memcached soname "libmemcached.so";

इन दो अनुरोधों के बीच, Memcached इंटरफ़ेस काम नहीं करेगा। इस वजह से, मौजूदा एक को बदलने और प्लगइन को पुनरारंभ करने की तुलना में एक नया टेबल_आईडी बनाना अक्सर आसान होता है।

यह हमारे लिए एक आश्चर्य की बात थी कि प्लग-इन ऑपरेशन की इतनी महत्वपूर्ण बारीकियों का वर्णन इनोफ़ीडी मेमेकैड प्लगिन पृष्ठ के लिए एक मेमेकैच्ड एप्लिकेशन को अपनाने पर किया गया है, जो इस तरह की जानकारी के लिए बहुत तार्किक जगह नहीं है।

झंडे, कैस_कूल, expire_time_column

Memcached की कुछ विशेषताओं का अनुकरण करने के लिए इन क्षेत्रों की आवश्यकता है। उनके लिए प्रलेखन असंगत है। इसमें ज्यादातर उदाहरण उन तालिकाओं के साथ काम करने को चित्रित करते हैं जिनमें ये क्षेत्र हैं। एक चिंता हो सकती है कि आपको उन्हें अपनी तालिकाओं में जोड़ने की आवश्यकता होगी (और ये कम से कम तीन INT फ़ील्ड हैं)। लेकिन नहीं। यदि आपके पास तालिकाओं में ऐसे फ़ील्ड नहीं हैं और आप ऐसे Memcached कार्यक्षमता का उपयोग CAS, समाप्ति या ध्वज के रूप में नहीं करने जा रहे हैं, तो आपको इन फ़ील्ड्स को तालिकाओं में जोड़ने की आवश्यकता नहीं है।

Innodb_memcache.containers में तालिका को कॉन्फ़िगर करते समय, आपको इन क्षेत्रों में '0' दर्ज करने की आवश्यकता होती है, बिल्कुल शून्य के साथ रेखा बनाएं:

 INSERT INTO innodb_memcache.containers SET   name='auth',   db_schema='test',   db_table='auth',   key_columns='email',   value_columns='password|type',   flags='0',   cas_column='0',   expire_time_column='0',   unique_idx_name_on_key='PRIMARY';

यह कष्टप्रद है कि cas_column और expire_time_column में NULL का डिफ़ॉल्ट मान होता है, और यदि आप INSERT INTO innodb_memcache.containers पर अमल करते हैं, तो इन क्षेत्रों के लिए '0' का मान निर्दिष्ट किए बिना, NULL उनमें संग्रहीत किया जाएगा और यह memcache उपसर्ग बस काम नहीं करेगा।

डेटा प्रकार

प्रलेखन से यह बहुत स्पष्ट नहीं है कि प्लगइन के साथ काम करते समय किस प्रकार के डेटा का उपयोग किया जा सकता है। कई स्थानों पर यह कहा जाता है कि प्लगइन केवल पाठ फ़ील्ड (CHAR, VARCHAR, BLOB) के साथ काम कर सकता है। यहाँ: InnoDB मेमेकटेड प्लगइन के लिए एक मौजूदा MySQL स्कीमा को अपनाना स्ट्रिंग क्षेत्रों में संख्याओं को संग्रहीत करने की पेशकश करता है, और यदि आपको SQL से इन नंबर फ़ील्ड्स के साथ काम करने की आवश्यकता है, तो एक व्यू बनाएं जिसमें संख्याओं के साथ VARCHAR फ़ील्ड्स को INTEGER फ़ील्ड में कनवर्ट किया जाएगा :

 CREATE VIEW numbers AS SELECT c1 KEY, CAST(c2 AS UNSIGNED INTEGER) val FROM demo_test WHERE c2 BETWEEN '0' and '9999999999';

हालांकि, प्रलेखन में कुछ स्थानों पर यह अभी भी लिखा है कि आप संख्याओं के साथ काम कर सकते हैं। अब तक, हमारे पास केवल टेक्स्ट फ़ील्ड के साथ वास्तविक उत्पादन अनुभव है, लेकिन प्रयोगात्मक परिणाम बताते हैं कि प्लगइन संख्याओं के साथ भी काम करता है:

 CREATE TABLE `numbers` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `counter` int(10) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB INSERT INTO innodb_memcache.containers SET name='numbers', db_schema='test', db_table='numbers', key_columns='id', value_columns='counter', flags='0', cas_column='0',expire_time_column='0',unique_idx_name_on_key='PRIMARY';

उसके बाद, Memcached प्रोटोकॉल के माध्यम से:

 get @@numbers.1 END set @@numbers.1 0 0 2 12 STORED get @@numbers.1 VALUE @@numbers.1 0 2 12 END

हम देखते हैं कि मेमकाटेड प्लगइन किसी भी प्रकार के डेटा को लौटा सकता है। लेकिन यह उन्हें उस रूप में लौटाता है जिसमें वे इनोबीडी में झूठ बोलते हैं, इसलिए, उदाहरण के लिए, टाइमस्टैम्प / डेटाइम / फ्लोट / दशमलव / जेएसएन के मामले में, एक द्विआधारी स्ट्रिंग वापस आ जाता है। लेकिन पूर्णांक वापस आ जाते हैं क्योंकि हम उन्हें SQL के माध्यम से देखते हैं।

Multiget

प्रचलित प्रोटोकॉल आपको एक ही अनुरोध के साथ कई कुंजियों का अनुरोध करने की अनुमति देता है:

 get @@numbers.2 @@numbers.1 VALUE @@numbers.2 0 2 12 VALUE @@numbers.1 0 2 13 END

तथ्य यह है कि मल्टीगेट काम करता है पहले से ही अच्छा है। लेकिन यह एक table_id के ढांचे के भीतर काम करता है:

 get @@auth.ivan@example.com @@numbers.2 VALUE @@auth.ivan@example.com 0 10 qwerty|xxx END

इस बिंदु का वर्णन यहाँ प्रलेखन में किया गया है: https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-multiple-get-range-query.html । यह पता चला है कि मल्टीगेट में आप केवल पहली कुंजी के लिए table_id निर्दिष्ट कर सकते हैं, यदि अन्य सभी चाबियाँ डिफ़ॉल्ट table_id (प्रलेखन से उदाहरण) से ली गई हैं:

 get @@aaa.AA BB VALUE @@aaa.AA 8 12 HELLO, HELLO VALUE BB 10 16 GOODBYE, GOODBYE END

इस उदाहरण में, दूसरी कुंजी डिफ़ॉल्ट table_id से ली गई है। हम डिफ़ॉल्ट टेबल_आईडी से बहुत अधिक कुंजी निर्दिष्ट कर सकते हैं, और पहली कुंजी के लिए हमने एक अलग टेबल_आईडी निर्दिष्ट किया है, और यह केवल पहली कुंजी के मामले में ही संभव है।

हम कह सकते हैं कि मल्टीगेट एक तालिका के ढांचे के भीतर काम करता है, क्योंकि आप ऐसा महसूस नहीं करते हैं कि उत्पादन कोड में इस तरह के तर्क पर भरोसा करते हैं: यह स्पष्ट नहीं है, इसके बारे में भूलना, गलती करना आसान है।

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

INCR, DEL

मैंने पहले ही GET / SET अनुरोधों के उदाहरण दिए हैं। INCR और DEL प्रश्नों में एक विशेषता है। यह इस तथ्य में निहित है कि वे केवल डिफ़ॉल्ट table_id का उपयोग करते समय काम करते हैं:

 DELETE @@numbers.1 ERROR get @@numbers VALUE @@numbers 0 24 test/numbers END delete 1 DELETED

झिल्लीदार प्रोटोकॉल सीमाएँ

मेम्केड में एक पाठ प्रोटोकॉल है, जो कुछ सीमाएं लगाता है। उदाहरण के लिए, मेम्केड कीज़ में व्हाइट स्पेस कैरेक्टर (स्पेस, लाइन फीड) नहीं होना चाहिए। यदि आप हमारे उदाहरण से तालिका के विवरण को फिर से देखते हैं:

 CREATE TABLE `auth` ( `email` varchar(96) NOT NULL, `password` varchar(64) NOT NULL, `type` varchar(32) NOT NULL DEFAULT '', PRIMARY KEY (`email`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

इसका मतलब यह है कि "ईमेल" क्षेत्र में ऐसे अक्षर नहीं होने चाहिए।

इसके अलावा, मेम की गई चाबियां 250 बाइट्स (बाइट्स, न कि अक्षर) से कम होनी चाहिए। यदि आप अधिक भेजते हैं, तो आपको एक त्रुटि मिलती है:

 "CLIENT_ERROR bad command line format"

इसके अलावा, किसी को इस तथ्य को ध्यान में रखना चाहिए कि मेमेकैच्ड प्लगइन मेमैक्टेड प्रोटोकॉल में अपना सिंटैक्स जोड़ता है। उदाहरण के लिए, यह चरित्र का उपयोग करता है "|" प्रतिक्रिया में क्षेत्र विभाजक के रूप में। आपको यह सुनिश्चित करने की आवश्यकता है कि यह प्रतीक आपकी तालिका में उपयोग नहीं किया गया है। विभाजक को कॉन्फ़िगर किया जा सकता है, लेकिन सेटिंग्स पूरे MySQL सर्वर पर सभी तालिकाओं पर लागू होंगी।

फ़ील्ड सीमांकक value_columns

यदि आपको हमारे पहले उदाहरण में, मेमोरैक्ड प्रोटोकॉल के माध्यम से कई कॉलम वापस करने की आवश्यकता है:

 get @@auth.max@example.com VALUE @@auth.max@example.com 0 10 1234567|89 END

तब स्तंभ मान मानक विभाजक द्वारा अलग हो जाते हैं "" | सवाल उठता है: "क्या होगा यदि, उदाहरण के लिए, चरित्र" | "पंक्ति में पहले क्षेत्र में है?" इस मामले में मेमेकैच्ड प्लगइन स्ट्रिंग को वापस लौटा देगा, कुछ इस तरह से है: 1234 | 567 | 89 | सामान्य मामले में, यह समझना असंभव है कि कोई क्षेत्र कहाँ है।

इसलिए, सही विभाजक को तुरंत चुनना महत्वपूर्ण है। और चूंकि यह सभी तालिकाओं की सभी कुंजियों के लिए उपयोग किया जाएगा, इसलिए यह एक सार्वभौमिक चरित्र होना चाहिए जो किसी भी क्षेत्र में नहीं मिलेगा, जिसके साथ आप मेमस्कैल्ड प्रोटोकॉल के माध्यम से काम करेंगे।

सारांश

यह कहने के लिए नहीं है कि मेमेकैच्ड प्लगइन खराब है। लेकिन ऐसा लगता है कि यह काम की एक विशिष्ट योजना के लिए लिखा गया था: एक मेज के साथ एक MySQL सर्वर जिसे मेमस्कैल्ड प्रोटोकॉल का उपयोग करके एक्सेस किया जा सकता है, और यह टेबल_आईडी डिफ़ॉल्ट रूप से बनाई गई है। ग्राहक मेमकैच्ड प्लगइन के साथ एक स्थायी संबंध स्थापित करते हैं और डिफ़ॉल्ट table_id के लिए अनुरोध करते हैं। शायद, ऐसी योजना में, सब कुछ निर्दोष रूप से काम करेगा। यदि आप इससे दूर जाते हैं, तो आप विभिन्न असुविधाओं में आते हैं।

आप कुछ प्लगइन प्रदर्शन रिपोर्ट देखने की उम्मीद कर सकते हैं। लेकिन हमने अभी तक इसे अत्यधिक भरी हुई जगहों पर उपयोग करने का निर्णय नहीं लिया है। हमने इसे केवल कुछ ही नहीं भरी हुई प्रणालियों में उपयोग किया है और यह हैंडलरसॉकेट के समान गति के बारे में काम करता है, लेकिन हमने ईमानदार बेंचमार्क नहीं बनाया है। लेकिन फिर भी, प्लगइन एक ऐसा इंटरफ़ेस प्रदान करता है जिसके साथ प्रोग्रामर आसानी से गलती कर सकता है - आपको बहुत सारी बारीकियों को ध्यान में रखने की आवश्यकता है। इसलिए, हम अभी तक बल्क में इस प्लगइन का उपयोग करने के लिए तैयार नहीं हैं।

हमने MySQL बग ट्रैकर में कुछ फ़ीचर अनुरोध किए हैं:

https://bugs.mysql.com/bug.php?id=95091
https://bugs.mysql.com/bug.php?id=95092
https://bugs.mysql.com/bug.php?id=95093
https://bugs.mysql.com/bug.php?id=95094

चलो आशा करते हैं कि मेमस्कैल्ड प्लगइन डेवलपमेंट टीम अपने उत्पाद में सुधार करेगी।

Memcached plugin: MySQL में NoSQL