फ़ील्ड स्केलेबिलिटी के संदर्भ में नए बनाए जाने वाले फ़ील्ड्स के पुन: उपयोग के बीच एक अच्छा संतुलन क्या है?

Question

मैंने एक वेबसाइट पर निम्नलिखित वाक्यांश पढ़ा है:

नए फ़ील्ड को सामग्री प्रकार में जोड़ने के बजाय, सिस्टम की जटिलता को कम करने और स्केलेबिलिटी में सुधार करने के लिए मौजूदा फ़ील्ड को जोड़ना बेहतर विकल्प है।

और कुछ संदेह पैदा होता है।

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

आर्किटेक्चर करते समय लक्ष्य के लिए कितनी पंक्तियाँ एक समझदार अधिकतम होगी? इस तरह हम तय कर सकते हैं कि खेतों का पुन: उपयोग कब करना है और कब नया बनाना है (भले ही पुन: उपयोग करने का मौका हो)।

Comments

मुझे वास्तविक मेट्रिक्स के साथ समर्थित उत्तर देखना अच्छा लगेगा।

— mpdonadio

सोचें कि हमने इस प्रश्न के आसपास बहुत रचनात्मक और सूचनात्मक टिप्पणियाँ एकत्र की हैं। हालाँकि, मैं उत्तर देने से एक या दो दिन पहले प्रतीक्षा करूंगा, क्योंकि मेरे अंदर कुछ इस बात पर जोर देता है कि एक या दो सबसे भारी क्षेत्रों को अलग रखने के बावजूद (उनका पुन: उपयोग किया जा सकता है) एक अच्छा विचार हो सकता है :) ... विशेष रूप से उन लोगों को जानना दायर आसानी से 5, 10 या 20 मिलियन आइटम प्रति वर्ष बढ़ सकती है।

— रफमद

Answer 1

किसी फ़ील्ड में डेटा की मात्रा आमतौर पर कोई समस्या नहीं है। यदि आप इसके बारे में चिंतित हैं, तो वैकल्पिक फ़ील्ड संग्रहण प्लग इन देखें या अपना स्वयं का लेख लिखें। उदाहरण के लिए MongoDB , जो आपके द्वारा इसमें डाली गई बहुत सारी चीज़ों से निपट सकता है। यह उदाहरण के लिए http://examiner.com पर उपयोग किया जाता है ।

हालांकि एक वास्तविक समस्या आपके पास फ़ील्ड्स की संख्या है। क्योंकि वर्तमान में Drupal 7 में, सभी फ़ील्ड्स का पूरा फ़ील्ड कॉन्फ़िगरेशन , चाहे वे लोड किए गए हों या नहीं, हर एक अनुरोध पर कैश से प्राप्त किया जाता है।

मैंने 250+ फ़ील्ड्स वाली साइटें देखी हैं, जहाँ फ़ील्ड कॉन्फ़िगरेशन को लोड करना और अनसुना करना 13MB + मेमोरी लेता है।

संपादित करें: Drupal 7.22 के साथ फ़ील्ड जानकारी कैश में सुधार किया गया है ( विवरण के लिए http://drupal.org/node/1040790 देखें), केवल एक निश्चित पृष्ठ पर प्रदर्शित होने वाले बंडल के फ़ील्ड कैश से लोड किए गए हैं और वे हैं अलग कैश प्रविष्टियाँ। यह तभी काम करता है जब कोई गलत एपीआई कॉल न हो जो कई बंडलों में अनुरोध करता है।

Comments

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

— रफामद

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

— बरादिर

उस ने कहा, एक मुट्ठी भर खेतों में कम या ज्यादा होने से वास्तव में फर्क नहीं पड़ेगा अगर आप इस तरह से अधिक सहज महसूस करते हैं, तो यह समस्या नहीं होनी चाहिए।

— बरदीर

राइट्स मुश्किल हिस्सा है, इसलिए टेस्ट करने के बारे में मेरी सिफारिश है। क्या हो सकता है कि काउंटरइन्युएक्टिव तथ्य यह है कि MySQL टेबल पर आधारित कैश्ड प्रविष्टियों को ड्रॉप करता है और न कि पंक्ति (पिछली बार जब मैंने जाँच की थी)। मैं अनिश्चित हूं जो एक प्रभाव से अधिक होगा, कई फ़ील्ड्स और टेबल या कैश-मिस की मेमोरी ओवरहेड एक ही टेबल पर लिखता है। यह निश्चित रूप से यातायात / उपयोग निर्भर है, हालांकि। मल्टीपल कैश (Drupal cache, APC opcode, APC user, MySQL query cache, memcached, varnish, आदि) के साथ सिस्टम प्रोफाइलिंग के बिना gut- आधारित निर्णय बहुत मुश्किल बनाता है।

— mpdonadio

यह अब मामला नहीं है: drupal.org/node/1040790

— jackbravo

Answer 2

मैं कुल मिलाकर बर्डिर से सहमत हूं। यहां कुछ नोड प्रकारों पर लाखों पंक्तियों और 30-40 फ़ील्ड वाली एक परियोजना के साथ मेरे अनुभव हैं।

1. फ़ील्ड तालिका में पंक्तियों की संख्या रीड प्रदर्शन के लिए एक बड़ी समस्या नहीं है, क्योंकि सभी फ़ील्ड प्राथमिक कुंजी द्वारा प्राप्त की जाती हैं।
2. नोड्स प्रति फ़ील्ड की संख्या नए नोड्स लिखते समय बड़ी प्रदर्शन समस्याओं में तेज़ी से बढ़ सकती है। जब आप एक नया नोड बनाते हैं, तो एक नोड प्रकार के लिए 30+ फ़ील्ड में 60+ INSERT स्टेटमेंट्स होते हैं। यह पूरा करने के लिए सेकंड लेता है। यदि आप बहुत अधिक डेटा बना रहे हैं, तो यह आपके प्रदर्शन को प्रभावित करेगा। 1000 नोड्स के थोक आवेषण में लगभग एक घंटा लगेगा। अगर आपको 100'000 नोड्स अपडेट करने हैं, तो यह एक बड़ी समस्या है।
3. यदि आपको लगता है कि फ़ील्ड की समस्या की संख्या आपको हिट करने वाली है, तो आपको अपने स्वयं के फ़ील्ड स्टोरेज को लिखने के बारे में गंभीरता से सोचना चाहिए या केवल फ़ील्ड का उपयोग नहीं करना चाहिए। (आप कुछ अतिरिक्त प्रयासों के साथ अपने नोड को अभी भी विचारों के साथ काम कर सकते हैं।)
4. MongoDB के बारे में एक शब्द। यह एक बहुत ही दिलचस्प परियोजना है और मुझे आशा है कि यह इसे बड़े DBs के ओलंपिक में बना रही है। दुर्भाग्य से MySql या PgSql की परिपक्वता की तुलना में यह एक बच्चा है। बहुत युवा उत्पाद से निपटने के लिए तैयार रहें।

Comments

हाय @BetaRide, आपकी जानकारी के लिए धन्यवाद। 2) के बारे में, हम पहले से ही प्रति सामग्री प्रकार के क्षेत्रों की संख्या को कम करने की कोशिश कर रहे हैं और यह बिल्कुल वैसा नहीं है जैसा हम यहां चर्चा कर रहे हैं। असली सौदा यह है: क्या मुझे जब भी संभव हो खेतों को अंधा कर देना चाहिए या (कम से कम) सबसे भारी एक या दो अलग रखने की कोशिश करनी चाहिए (भले ही वे आसानी से एक ही हो सकते हैं जैसे: वे वास्तव में एक ही नाम है, आदि)। हाँ, मोंगो अब हमारे लिए अंतिम विकल्प होना चाहिए :)

— rafamd

Answer 3

यदि आप वास्तव में चिंतित हैं कि क्या होगा, तो मुझे लगता है कि एक सिमुलेशन क्रम में है।

Rackspace Cloud, Amazon, Linode, या कहीं भी आप आसानी से VPS को स्पिन कर सकते हैं, पर एक खाता प्राप्त करें। दो समान उदाहरण बनाओ। प्रत्येक पर Drupal स्थापित करें। कुछ डमी सामग्री प्रकार बनाएं, और एक सिस्टम में फ़ील्ड्स को एक तरह से सेट करें, और दूसरे में अन्य तरीके से। सामग्री का बोट लोड बनाने के लिए डेवेल मॉड्यूल का उपयोग करें। यह सुनिश्चित करने के लिए प्रदर्शन सेटिंग समायोजित करें कि ड्रुपल आवश्यकतानुसार कैशिंग कर रहा है। Mysqltuner चलाएं और प्रत्येक पुनर्संयोजन पर MySQL समायोजित करें। डबल PHP और APC सेटिंग्स को चेक करें ताकि आप स्वैप को हिट न करें और आप APC कैश को मंथन नहीं कर रहे हैं।

एक बार जब आप प्रत्येक के लिए एक अच्छा आधारभूत विन्यास प्राप्त करते हैं, तो ट्रैफ़िक (सामान्य आगंतुकों और व्यवस्थापक अपडेट दोनों) को wget और drush, और फिर प्रोफ़ाइल के साथ अनुकरण करना शुरू करें।

सिमुलेशन कभी भी पूर्ण नहीं होते हैं, लेकिन वे आपको सही दिशा में जा सकते हैं।

Answer 4

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

Answer 5

एक और टिप: बहुत सारे फ़ील्ड होने से कई अलग-अलग मॉड्यूलों के साथ समस्याएं भी होंगी। उदाहरण के लिए टोकन GUI अगर आप उदाहरण के लिए url उपनामों को संपादित करने का प्रयास करते हैं तो यह आपके ब्राउज़र को मिनटों के लिए अंतराल बना देगा। यह व्यवहार उन सभी पृष्ठों पर देखा जा सकता है, जहाँ टोकन लोड किया और प्रदर्शित किया जाएगा (जिसमें devel - dpm () आदि)

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

यह समान नोड विशेषताओं के कारण टेम्प्लेट निर्माण को भी आसान बना सकता है।

Answer 6

बस अपनी कहानी साझा करते हुए, हम Drupal Commerce का उपयोग कर रहे हैं और हमारे उत्पाद में लगभग 40 क्षेत्र हैं (Sku) और फिर हमारे उत्पाद प्रदर्शन में 460 (हाँ, पागल) हैं। हमारे पास कुछ उत्पाद तुलनात्मक विचार थे जो इन सभी क्षेत्रों को देखेंगे। कैशिंग के बिना, कुछ पृष्ठ लोड एक मिनट तक ले सकते हैं!

हालाँकि, इसने काम किया। यदि आपने कैशिंग और वार्निश का उपयोग किया है, तो उपयोगकर्ता प्रतीक्षा समय उतना बुरा नहीं था।

मुख्य समस्या जो हम इतने सारे क्षेत्रों में करते हैं, वह डिस्प्ले सूट के साथ होती है, क्योंकि अगर हम एक क्षेत्र को फिर से व्यवस्थित या स्थानांतरित करने का प्रयास करते हैं तो यह बहुत धीमी गति से (कभी-कभी गैर-उत्तरदायी) हो जाएगा।

सौभाग्य से, हमने अपने उत्पादों को फिर से फ़ैक्टर करने का फैसला किया, ताकि हम अपने सबसे जटिल उत्पादों के लिए 200-250 रेंज में अपने अधिकतम क्षेत्रों को उम्मीद से कम कर सकें (हम वैज्ञानिक उपकरण में हैं, इसलिए जटिल माप और चश्मा की आवश्यकता है) ।

Answer 7

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

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

Comments

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

— rafamd

मुझे लगता है कि अन्य दो से टिप्पणी के बारे में यह बहुत मायने नहीं रखता है क्योंकि प्राथमिक कुंजी पर चयन अच्छे बिंदु हैं। मुझे लगता है कि मैं कहूंगा कि मैं अभी इसके लिए जाऊंगा, लेकिन सुनिश्चित करें कि आपने भविष्य के लिए अपने विकल्पों के बारे में कुछ पढ़ा है, खेतों के लिए मोंगो आदि। आप हमेशा अपनी साइट के भविष्य के बारे में सब कुछ अनुमान नहीं लगा सकते हैं

— joevallender

Answer 8

मैंने अब तक हमेशा खेतों का फिर से उपयोग किया है, लेकिन अब मैं एक नए प्रोजेक्ट के लिए प्रति नोड प्रकार अद्वितीय फ़ील्ड का उपयोग करने पर विचार कर रहा हूं। मैं वास्तव में प्रत्येक इकाई बंडल के लिए सब कुछ अच्छी तरह से अलग (फ़ील्ड, विचार, नियम, संदर्भ, आदि) रखना चाहता हूं। इसलिए इसने स्केलेबिलिटी पर सवाल उठाया जो मुझे यहां ले गया। मुझे बरदीर के संपादन से सुकून मिला है (Drupal 7.2 के साथ फ़ील्ड जानकारी कैश में सुधार हुआ है (देखें http://drupal.org/node/1040790 ) ड्रुपल 7.22 के साथ, केवल एक निश्चित पृष्ठ पर प्रदर्शित बंडलों के फ़ील्ड लोड किए गए हैं कैश और वे अलग-अलग कैश एंट्री हैं। यह केवल तभी काम करता है जब कोई गलत एपीआई कॉल न हो जो कई बंडलों में उदाहरण का अनुरोध करता हो)।

मैं केवल यह बताना चाहता हूं कि एक बहुत ही दिलचस्प मॉड्यूल है जिसे मैं कई, जटिल साइटों पर महीनों से उपयोग कर रहा हूं । https://www.drupal.org/project/render_cache । यह मेरी राय में छिपे हुए रत्नों में से एक है।

जैसा कि यह परियोजना पृष्ठ पर कहता है, टिप्पणियों का हिस्सा वास्तव में DO पर ही उपयोग किया जा रहा है।

तो, यह सब ध्यान में रखते हुए, क्या यह अलग-अलग क्षेत्रों के पक्ष में सर्वसम्मति को बदल देगा? डीएस के बारे में उल्लेख किया जा रहा है, हालांकि अभी भी एक bummer है। यह उदाहरण के बजाय, अजाक्स के माध्यम से सहेजने के तरीके से सुपर कष्टप्रद है, उदाहरण के लिए, कोर ब्लॉक प्रशासन इंटरफ़ेस फिर से ऑर्डर करने के तरीके को कैसे संभालता है। मुझे लगता है कि यह एक डीएस मुद्दा है, हालांकि ...

Answer 9

मेरे सुझाव के अनुसार अलग-अलग सामग्री प्रकार में समान फ़ील्ड का उपयोग करना अच्छा विचार है। क्योंकि यह आपकी साइट के प्रदर्शन में सुधार करेगा। Drupal 7 में, जब आप उस समय चुनिंदा ऑपरेशन का उपयोग कर रहे होते हैं, तो सामग्री प्रकार में समान फ़ील्ड का उपयोग करना वास्तव में आपकी Drupal7 साइट के लिए उपयोगी होता है।

Comments

Drupal 7 में, उन्होंने Doctrine ORM का उपयोग करना शुरू कर दिया ... नहीं। Drupal 8 भी सिद्धांत का उपयोग नहीं करता

— क्लाइव

"सिद्धांत हमेशा सभी मैप किए गए डेटा से वस्तु लौटाता है", एक गलत बयान भी है। सिद्धांत को इंगित करने के लिए ऑब्जेक्ट को एनोटेट किया जा सकता है कि डिफ़ॉल्ट व्यवहार उपयुक्त नहीं है। ऐसा नहीं है कि यह बहुत प्रासंगिक है, यह देखते हुए कि जैसा कि क्लाइव कहता है, द्रुपाल सिद्धांत का उपयोग नहीं करता है।

— लेथेरियन