Magento में अनुक्रमण कैसे काम करता है

Question

1. Magento में अनुक्रमण कैसे काम करता है
2. वास्तव में यह क्या करता है?
3. इसकी आवश्यकता क्यों है?

Comments

इस कड़ी: stackoverflow.com/questions/4945307/... आप मदद करनी चाहिए

— TBI इन्फोटेक

यहाँ Magento 2 magento.stackexchange.com/questions/90510/…

— योगेश त्रिवेदी

Magento के किस संस्करण का उपयोग कर रहे हैं? V1.13 में काफी बदलाव किए गए हैं - इसलिए उस संस्करण से पहले के संस्करण में अंतर की उम्मीद करें। यहाँ एक अच्छा ब्लॉग पोस्ट है जो mView मॉड्यूल को समझाता है और Magento के संस्करण 1.13 में अनुक्रमण करता है: eschrade.com/page/…

— पिट

Answer 1

Magento में विभिन्न प्रकार के सूचकांक हैं।
सभी इंडेक्सर्स चीजें तेजी से चलाने के लिए हैं।
मैं उनमें से केवल कुछ को यहां कवर करूंगा।

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

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

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

कैटलॉग यूआरएल रिवाइराइट्स
यह यूआरएल रीराइट नियमों को साफ करके सेट करता है कि कौन सा यूआरएल किस उत्पाद या श्रेणी से मेल खाता है। Url प्रबंधन आंतरिक प्रणाली के लिए यह तय करना आसान है कि आपको गैर-मानक url कहते समय किस पृष्ठ को देखना चाहिए। सभी उत्पाद और श्रेणियों URL कुंजी के माध्यम से खोजने के बजाय यह सिर्फ एक तालिका में खोज करता है।

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

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

उत्पाद विशेषताओं ।
यह एक ही कारण के लिए स्तरित नेविगेशन में इस्तेमाल किया जा सकता है कि सभी विशेषताओं को एकत्र करता है। तेजी से पढ़ने के लिए उन सभी को एक स्थान पर रखना।

टैग एकत्रीकरण
मुझे नहीं पता कि यह क्या करता है। मैंने कभी भी वास्तविक लाइव प्रोजेक्ट में टैग का उपयोग नहीं किया है।

Comments

धन्यवाद marius यह अब तक का सबसे अच्छा जवाब है ... मुझे मिल गया है

— सोनम

जब आपने कहा था कि फ्लैट टेबल का उपयोग केवल दृश्यपटल में किया जाता है (और बैकेंड अभी भी ईएवी संरचना का उपयोग करता है)? मैं एक नौसिखिया हूं, और जो मैंने समझा था, जब हम उत्पादों की तरह संस्थाओं का निर्माण / अद्यतन करते हैं, तो यह अभी भी इन कार्यों को करने के लिए ईएवी तालिकाओं का उपयोग करता है और हम बचत या मैन्युअल रूप से उन्हें अपडेट करने के लिए फ्लैट तालिकाओं को अपडेट करने का विकल्प निर्धारित करते हैं। ये परिवर्तन फ्लैट टेबल में परिलक्षित होते हैं। जब आपने कहा कि क्या आप इस प्रक्रिया का जिक्र कर रहे हैं? आप इस पर विस्तार से बता सकते हैं? धन्यवाद!

— भारद्वाज श्रीगिरिराजु

@ मार्स: रि-इंडेक्सिंग के दौरान, मुझे टेबल फुल एरर मिल रहा है। कृपया मदद करे। है त्रुटि हो रही है मेज 'catalog_product_index_price_bundle_sel_tmp' भरा हुआ है

— जेड ब्लैकबीयर्ड

@ इस जवाब के 3 साल बाद अब आपको टैग एग्रीगेशन के बारे में कुछ पता है, क्या यह उत्पाद टैग से संबंधित है ??

— मुर्तुज़ा ज़बुआवाला

@काली। इंडेक्स के लिए आपके पास 2 सेटिंग्स हैं। "सेव ऑन अपडेट" और "मैनुअल"। जब आप उत्पाद को बचाते हैं तो सब कुछ बचाने के लिए अद्यतन स्वचालित रूप से होना चाहिए। लेकिन इससे प्रदर्शन संबंधी समस्याएं हो सकती हैं। उदाहरण के लिए यदि आप एक साथ कई उत्पाद बदलते हैं। मैनुअल मोड के लिए, कोई भी reindexing को बचाने के बाद imediately ट्रिगर नहीं किया जाता है, लेकिन आपको मैन्युअल रूप से पुनर्निर्माण किया जाता है जब आप किया जाता है।

— मेरियस

Answer 2

इसके लिए श्रेय नहीं लिया जा सकता क्योंकि यह मूल पोस्ट से लिया गया है: https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-dadail

Magento के इंडेक्सिंग केवल आत्मा में डेटाबेस-लेवल इंडेक्सिंग के समान है। जैसा कि एंटोन बताता है, किसी साइट के तेजी से संचालन की अनुमति देने के लिए यह अपभ्रंश की प्रक्रिया है। मुझे Magento डेटाबेस संरचना के पीछे के कुछ विचारों को समझाने की कोशिश करें और यह गति में संचालित करने के लिए अनुक्रमण को आवश्यक क्यों बनाता है।

अधिक "विशिष्ट" MySQL डेटाबेस में, कैटलॉग उत्पादों को संग्रहीत करने के लिए एक तालिका को कुछ इस तरह संरचित किया जाएगा:

PRODUCT:
    product_id INT
    sku        VARCHAR
    name       VARCHAR
    size       VARCHAR
    longdesc   VARCHAR
    shortdesc  VARCHAR
    ... etc ...

यह पुनर्प्राप्ति के लिए तेज़ है, लेकिन यह ईकामर्स सॉफ़्टवेयर के एक टुकड़े के लिए एक मूलभूत समस्या छोड़ देता है: जब आप अधिक विशेषताओं को जोड़ना चाहते हैं तो आप क्या करते हैं? यदि आप खिलौने बेचते हैं, और आकार के कॉलम के बजाय, आपको age_range की आवश्यकता है? ठीक है, आप एक और कॉलम जोड़ सकते हैं, लेकिन यह स्पष्ट होना चाहिए कि एक बड़े स्टोर में (उदाहरण के लिए वॉलमार्ट, उदाहरण के लिए), इसका परिणाम उन पंक्तियों में होगा जो 90% खाली हैं और नई विशेषताओं के रखरखाव का प्रयास करना असंभव है।

इस समस्या से निपटने के लिए, Magento ने छोटी इकाइयों में तालिकाओं को विभाजित किया। मैं इस उत्तर में पूरे EAV सिस्टम को फिर से बनाना नहीं चाहता, इसलिए कृपया इस सरलीकृत मॉडल को स्वीकार करें:

PRODUCT:
    product_id INT
    sku        VARCHAR

PRODUCT_ATTRIBUTE_VALUES
    product_id   INT
    attribute_id INT
    value        MISC

PRODUCT_ATTRIBUTES
    attribute_id
    name

अब product_attributes में नए मान दर्ज करके और फिर product_attribute_values ​​में आसन्न रिकॉर्ड डालकर विशेषताओं को जोड़ना संभव होगा। यह मूल रूप से मैगेंटो करता है (डेटाटाइप के लिए थोड़ा अधिक सम्मान के साथ जो मैंने यहां प्रदर्शित किया है)। वास्तव में, अब दो उत्पादों के लिए समान क्षेत्र होने का कोई कारण नहीं है, इसलिए हम विभिन्न गुणों के साथ पूरे उत्पाद प्रकार बना सकते हैं!

हालाँकि, यह लचीलापन एक लागत पर आता है। अगर मैं अपने सिस्टम में एक शर्ट का रंग खोजना चाहता हूं (एक तुच्छ उदाहरण), मुझे खोजने की आवश्यकता है:

1. आइटम का product_id (उत्पाद तालिका में)
2. Color_id रंग के लिए (विशेषता तालिका में)
3. अंत में, वास्तविक मूल्य (विशेषता_ तालिका में)

Magento इस तरह से काम करता था, लेकिन यह धीमी गति से मृत था। इसलिए, बेहतर प्रदर्शन की अनुमति देने के लिए, उन्होंने एक समझौता किया: एक बार दुकान के मालिक ने उन विशेषताओं को परिभाषित किया जो वे चाहते हैं, आगे बढ़ें और शुरुआत से बड़ी तालिका बनाएं। जब कुछ बदलता है, तो इसे अंतरिक्ष से nuke और फिर से उत्पन्न करें। इस तरह, डेटा मुख्य रूप से हमारे अच्छे लचीले प्रारूप में संग्रहीत होता है, लेकिन एक ही तालिका से क्वेरी की जाती है।

ये परिणामी लुकअप टेबल Magento के "अनुक्रमित" हैं। जब आप पुन: सूचकांक करते हैं, तो आप पुरानी तालिका को उड़ा रहे हैं और इसे फिर से बना रहे हैं।

आशा है कि चीजों को थोड़ा स्पष्ट करता है!

Comments

nuke it from space, अच्छा :)

— Wietse

Answer 3

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

डिफ़ॉल्ट रूप से, कोर सिस्टम प्रत्येक आइटम के सेव पर इंडेक्स अपडेट करता है। लेकिन कुछ मामलों में आपको इसे मैन्युअल रूप से करने की आवश्यकता होती है, उदाहरण के लिए कुछ प्रकार की सामूहिक क्रियाएं आदि। आप किसी भी समय एडमिन बैकएंड से अपडेट कर सकते हैं (एडमिन-> सिस्टम-> इंडेक्स मैनेजमेंट)। लेकिन कभी-कभी यह समस्याओं का कारण बनता है।

उदाहरण के लिए, यदि आपके पास 10k + उत्पाद और बहुत सी श्रेणियां हैं, तो 'कैटलॉग url rewrite' इंडेक्स के पुनर्निर्माण में घंटों लग सकते हैं। तब php स्क्रिप्ट सिर्फ ज्यादा से ज्यादा max_execution_time की वजह से टूट सकती है। कमांड लाइन से reindex प्रक्रिया चलाकर कई समस्याओं को हल करने का एक तरीका है।