यदि आपके प्लगइन में डेटा की बहुत कमी है, तो wp_postmetaनीचे दिखाए अनुसार एक अच्छा विचार नहीं है:
WooCommerce को एक उदाहरण के रूप में, ~ 30,000 उत्पादों के साथ एक स्टोर में, औसतन कहा जाएगा, ~ 40 पोस्ट मेटा (गुण और सब कुछ) प्रति उत्पाद, उत्पाद के प्रति 5 उत्पाद चित्र, जिसका अर्थ है ~ 4 छवि मेटा प्रत्येक छवि के लिए:
30,000 उत्पादों x 40 मेटा प्रत्येक = 1,200,000 पंक्तियों में wp_postmeta
+
30,000 उत्पाद x 5 चित्र प्रत्येक x 4 छवि मेटा प्रत्येक = 600,000 पंक्तियों के लिए wp_postmeta
तो केवल 30,000 उत्पादों के साथ आप 1,800,000 पंक्तियों में देख रहे हैं wp_postmeta।
यदि आप अपने उत्पादों या अपने उत्पाद चित्रों में अधिक गुण जोड़ते हैं, तो यह संख्या कई गुना बढ़ जाएगी।
इसके साथ समस्या दुगुनी है:
- MySQL के साथ Self Joins बहुत महंगे हैं
wp_postmetaजब तक आप बाद के mysql संस्करणों (यानी के लिए कोई पूर्ण सूचकांक meta_value) का उपयोग नहीं कर रहे हैं तब तालिका अनुक्रमित नहीं होती है
वास्तविक मामले से एक उदाहरण देने के लिए:
SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'
यह सभी ऑर्डर विवरणों से शिपिंग शहर का चयन करता है, एक एंट्री लेवल समर्पित सर्वर पर ~ 3 सेकंड में आता है, भले ही 5-10 ऑर्डर हों । ऐसा इसलिए है क्योंकि क्वेरी को किसी wp_postmetaतालिका के बीच से चलाया जाता है जिसमें लाइव इंस्टॉलेशन में ~ 3 मिलियन पंक्तियाँ होती हैं।
यहां तक कि होम पेज काफी धीमा आता है, क्योंकि थीम विभिन्न तत्वों को खींचती है wp_postmeta- स्लाइडर्स, कुछ समीक्षा आवेषण, कुछ अन्य मेटा। सामान्य उत्पाद सूची में बहुत धीमी है, उत्पादों को सूचीबद्ध करते समय खोज समान रूप से धीमी होती है।
आप इसे किसी भी सामान्य साधन के माध्यम से ठीक नहीं कर सकते। आप अपने सर्वर में इलास्टिक सर्च डाल सकते हैं और Wordpress में Elastic Search plugin का उपयोग कर सकते हैं, आप redis / memcached का उपयोग कर सकते हैं, आप एक अच्छे पेज कैश प्लगइन का उपयोग कर सकते हैं, लेकिन अंत में मूलभूत मुद्दा रहेगा - एक फूला हुआ कोई भी डेटा प्राप्त करना। wp_postmetaतालिका जब भी होगी, धीमी होगी। सर्वर पर जहां मैंने नीचे लागू किए गए समाधान का परीक्षण किया था, इन सभी को ठीक से और अनुकूलित करके स्थापित और कॉन्फ़िगर किया गया था, और साइट ने उपयोगकर्ताओं को या आमतौर पर किए गए प्रश्नों के लिए ठीक से काम किया क्योंकि कैशिंग प्लग इन में किकिंग हुई।
लेकिन जिस क्षण उपयोगकर्ता में लॉग इन किया गया वह कुछ ऐसा करने की कोशिश करता है जो आमतौर पर नहीं किया गया था या क्रोन, कैशिंग प्लगइन्स, या कोई अन्य उपयोगिता db से वास्तविक डेटा प्राप्त करना चाहती थी ताकि उसे कैश किया जा सके या कुछ और किया जा सके, चीजें धीमी हो गईं।
इसलिए मैंने कुछ और कोशिश की:
मैंने सभी उत्पाद मेटा (पोस्ट टाइप उत्पाद के लिए पोस्टमेटा ) को कोड द्वारा उत्पन्न कस्टम टेबल पर ले जाने के लिए एक छोटा प्लगइन कोडित किया। इस प्लगइन ने प्रत्येक पोस्ट के लिए सभी मेटा लिया और प्रत्येक मेटा को कॉलम के रूप में जोड़कर और प्रत्येक पंक्ति में मान डालकर एक टेबल बनाया। मैंने ईएवी प्रारूप को एक क्षैतिज, सपाट संबंधपरक प्रारूप में बदल दिया। मेरे पास मेज से सभी स्थानांतरित उत्पादों से पोस्टमेट को हटाने का प्लगइन भी था wp_postmeta।
जब मैं उस पर होता हूं, तो मैं अपने सभी तालिकाओं में अनुलग्नक पोस्टमेटा और अन्य सभी पोस्ट प्रकार के मेटा को स्थानांतरित कर देता हूं ।
फिर मैं get_(post_type)_metaनए कस्टम टेबल से उनकी सेवा करने के लिए मेटाडेटा की पुनर्प्राप्ति को ओवरराइड करने के लिए फ़िल्टर में झुका ।
अब वही क्वेरी पहले से, जिसमें wp_postmeta~ 0.006 सेकंड लगने में ~ 3 सेकंड का समय लगता था। साइट अब व्यवहार करती है जैसे कि यह एक ताजा WP इंस्टॉलेशन था।
....................
स्वाभाविक रूप से, Wordpress तरीका बेहतर है। यह वास्तव में आदर्श है।
हालांकि , यह भी स्पष्ट ज्ञान है कि ईएवी तालिका स्केलिंग में बहुत अक्षम है। यह असीम रूप से लचीला है और आपको किसी भी डेटा को स्टोर करने देता है, लेकिन इसके लिए आप जो कीमत अदा करते हैं, वह प्रदर्शन है। इसका एक मौलिक व्यापार बंद है।
उस संदर्भ में, किसी को यह बताना मुश्किल है कि डेटा के ढेर टन का इरादा है और - यह wp_postmetaसुनिश्चित करने के लिए तालिका का उपयोग करने के लिए उस डेटा पर भगवान ना करें / खोज करें। प्रदर्शन हिट बहुत अच्छा होगा।
अपने कस्टम तालिकाओं का उपयोग करने से आपका डेटा ढेर हो जाएगा और अभी भी काफी तेजी से बना रहेगा।
जैसे कैसे पिपिन विलियम्स, ईज़ी डिजिटल डाउनलोड प्लगइन के निर्माता ने उल्लेख किया कि यदि वह अपने प्लगइन को कोड करना शुरू कर रहा है तो वह कस्टम तालिकाओं का उपयोग करेगा, यदि आप कुछ ऐसा बनाने जा रहे हैं जिसका उपयोग लंबे समय तक किया जाएगा या बहुत अधिक डेटा का ढेर होगा, यदि आप उन्हें अच्छी तरह से डिज़ाइन करते हैं तो अपने कस्टम टेबल का उपयोग करना अधिक कुशल है।
आपको यह सुनिश्चित करना होगा कि किसी भी अन्य प्लगइन / एडऑन डेवलपर के पास डेटा को पुनः प्राप्त करने से पहले और बाद में अपने डेटा को हेरफेर करने के लिए अपने प्लगइन में हुक करने का मतलब है। यदि आप ऐसा करते हैं, तो आप बहुत ठोस हैं।