क्या सामान्यीकरण उच्च ट्रैफिक साइटों में प्रदर्शन को वास्तव में नुकसान पहुंचाता है?

Question

मैं डेटाबेस तैयार कर रहा हूं और मैं डेटाबेस को सामान्य बनाना चाहता हूं। एक प्रश्न में मैं लगभग 30-40 टेबल में शामिल हो जाऊंगा। क्या यह वेबसाइट प्रदर्शन को चोट पहुंचाएगा यदि यह कभी भी बेहद लोकप्रिय हो जाता है? यह मुख्य प्रश्न होगा और इसे 50% समय कहा जाएगा। अन्य प्रश्न मैं दो टेबल में शामिल हो जाऊंगा।

मेरे पास सामान्यीकरण करने के लिए अभी सामान्य विकल्प है या नहीं, लेकिन अगर सामान्यीकरण भविष्य में कोई समस्या बन जाता है तो मुझे सॉफ़्टवेयर का 40% फिर से लिखना पड़ सकता है और यह मुझे काफी समय ले सकता है। क्या इस मामले में सामान्यीकरण वास्तव में चोट पहुंचाता है? क्या मुझे समय होने पर अब denormalize करना चाहिए?

Answer 1

मैं बोली: "शुद्धता के लिए सामान्य, गति के लिए denormalize - और केवल जब आवश्यक"

मैं तुम्हें का संदर्भ लें: In terms of databases, is "Normalize for correctness, denormalize for performance" a right mantra?

HTH।

Answer 2

प्रारंभिक अनुकूलन न करें। वेबसाइट को गति देने का एकमात्र तरीका नहीं है denormalization। आपकी कैशिंग रणनीति भी काफी महत्वपूर्ण है और यदि 30-40 टेबल की वह क्वेरी काफी स्थिर डेटा है, तो परिणाम कैश करना बेहतर अनुकूलन साबित हो सकता है।

साथ ही, पढ़ने की संख्या में लिखने की संख्या को ध्यान में रखें। यदि आप प्रत्येक सम्मिलन या अद्यतन के लिए लगभग 10 पढ़ रहे हैं, तो आप कह सकते हैं कि डेटा काफी स्थिर है, इसलिए आपको इसे कुछ समय तक कैश करना चाहिए।

यदि आप अपनी स्कीमा को denormalizing समाप्त होता है, तो आपके लेखन भी अधिक महंगा और संभावित रूप से धीमी चीजें भी बन जाएंगे।

बहुत अधिक अनुकूलन करने से पहले अपनी समस्या का विश्लेषण करें और यह भी देखने के लिए प्रतीक्षा करें कि सिस्टम में आपकी बाधाएं वास्तव में कहां से हो सकती हैं क्योंकि आप आश्चर्यचकित हो सकते हैं कि आपको पहले स्थान पर क्या अनुकूलित करना चाहिए।

Answer 3

जब प्रदर्शन चिंता का विषय है, वहाँ असमान्यीकरण से आमतौर पर बेहतर विकल्प हैं:

• उचित अनुक्रमित और शामिल टेबल पर आँकड़े बनाना
• कैशिंग
• materialized दृश्य (एमएस एसक्यूएल सर्वर में अनुक्रमित views)
• अधिकांश मामलों में उपयोग की जाने वाली सामान्यीकृत सारणी के अतिरिक्त (आपके लिए आवश्यक प्रश्नों के लिए विशेष रूप से उपयोग की जाने वाली क्वेरी के लिए उपयोग किया जाता है) (सिंक्रनाइज़ेशन कोड लिखने की आवश्यकता होती है, जो एक त्रि के रूप में चला सकता है) आपको आवश्यक डेटा सटीकता के आधार पर गेजर या अनुसूचित नौकरी)

Answer 4

सामान्यीकरण प्रदर्शन को नुकसान पहुंचा सकता है। हालांकि यह समय से पहले denormalize करने का कोई कारण नहीं है।

पूर्ण सामान्यीकरण के साथ शुरू करें और फिर आप देखेंगे कि आपके पास कोई प्रदर्शन समस्या है या नहीं। जिस दर पर आप वर्णन कर रहे हैं (प्रति दिन 1000 अपडेट/इन्सर्ट) मुझे नहीं लगता कि जब तक टेबल बड़ी नहीं हो जाती तब तक आप समस्याओं में भाग लेंगे।

और यहां तक ​​कि यदि डेटाबेस ऑप्टिमाइज़ेशन विकल्प (इंडेक्स, तैयार संग्रहित प्रक्रियाएं, भौतिक दृश्य, ...) का उपयोग किया जा सकता है, तो भी आप इसका उपयोग कर सकते हैं।

Answer 5

शायद मुझे यहां कुछ याद आ रहा है। लेकिन अगर आपके आर्किटेक्चर के लिए आपको एक ही प्रश्न में 30 से 40 टेबल में शामिल होने की आवश्यकता है, तो वह प्रश्न आपकी साइट का मुख्य उपयोग है, तो आपको बड़ी समस्याएं हैं।

मैं मानता हूँ अन्य लोगों के साथ, समय से पहले ही अपनी साइट का अनुकूलन नहीं है। हालांकि, आपको अपने आर्किटेक्चर को मुख्य उपयोग के मामले में खाते में अनुकूलित करना चाहिए। 50% से अधिक समय तक चलने वाली क्वेरी के लिए 40 टेबल शामिल है आईएमओ अनुकूलित नहीं है।