MySQL प्रदर्शन: बड़े डेटासेट के लिए एकल तालिका या एकाधिक टेबल

मैं 200,000+ पंजीकृत उपयोगकर्ताओं का समर्थन करने के लिए एक ऐप बना रहा हूं, और प्रत्येक उपयोगकर्ता के लिए अपने स्वयं के संपर्क आयात करने के लिए एड्रेसबुक कार्यक्षमता जोड़ना चाहता हूं (उदा। नाम, पता, ईमेल इत्यादि)। प्रत्येक उपयोगकर्ता के पास प्रत्येक रिकॉर्ड के लिए 10-15 फ़ील्ड के साथ सी .150 अलग-अलग संपर्क होंगे।

मेरा सवाल सरल है: उपयोगकर्ताओं की मात्रा और प्रत्येक उपयोगकर्ता के लिए संपर्कों की संख्या दी गई है, क्या यह प्रत्येक उपयोगकर्ता की एड्रेसबुक के लिए अलग-अलग टेबल बनाने के लिए बेहतर है, या उस संबंधित उपयोगकर्ता खाते के लिए user_id लुकअप वाला एक एकल टेबल?

यदि आप एक प्रदर्शन परिप्रेक्ष्य से क्यों समझा सकते हैं, तो इसकी सराहना की जाएगी।

अद्यतन: निर्दिष्टीकरण

टिप्पणियों में सवालों के जवाब में, यहां विनिर्देश दिए गए हैं: मैं एडब्ल्यूएस आरडीएस पर डेटाबेस होस्ट कर रहा हूं ( http://aws .amazon.com/आरडीएस )। यह मुख्य रूप से लिखने के बजाय भारी पढ़ने वाला भार होगा। जब लेखन का उपयोग किया जाता है, तो यह कुछ डिलीटों के साथ INSERT और UPDATE के बीच संतुलन होगा। कल्पना करें कि आप अपनी खुद की एड्रेसबुक बनाम बनाम कितनी बार देखते हैं।

धन्यवाद

1
@RaymondNijland धन्यवाद, कृपया अद्यतन उत्तर देखें।
जोड़ा लेखक alias51, स्रोत
@ N.B। यह अमेज़ॅन आरडीएस है, तो मुझे कम प्रासंगिक लगता है?
जोड़ा लेखक alias51, स्रोत
यहां एक सरल सवाल है कि आपको खुद से पूछना होगा: क्या आप एक यांत्रिक एचडीडी या एसएसडी का उपयोग कर रहे हैं? अंतर विशाल है। लेकिन, एक साधारण उत्तर के लिए - एक टेबल का प्रबंधन करना आसान है। यह प्रति उपयोगकर्ता एक टेबल रखने के लिए कई (तार्किक भी) नियमों का उल्लंघन भी है। यह मूल रूप से 0 भावना बनाता है। यह एक बड़ी दौड़ से 5 मिनट पहले पैर में खुद को शूटिंग की तरह है और पूछ रहा है कि यह एक अच्छा कदम था या नहीं।
जोड़ा लेखक N.B., स्रोत
एक टेबल रखना बहुत बेहतर है क्योंकि इसे पुनर्प्राप्त करना और बनाए रखना आसान है। हालांकि आप बाद में अपनी तालिका का विभाजन कर सकते हैं। MySQL के लिए कई मिलियन रिकॉर्ड इतना नहीं है
जोड़ा लेखक Sam D, स्रोत
इसके बाद अधिक जानकारी चाहिए ... MySQL संस्करण क्या है? क्या भंडारण इंजन? टेबल विवरण अच्छा होगा .. क्या यह एक भारी लेखन या भारी पढ़ने वाला आवेदन होगा या दोनों? और यह प्रदर्शन परिप्रेक्ष्य यह इंसर्ट्स, अपडेट या डिलीट्स पर आधारित है ??
जोड़ा लेखक Raymond Nijland, स्रोत

3 उत्तर

Specific answer in response to specifications One table for contacts' data, with an indexed foreign key column back to user. Finding a particular user's contacts will require about 3 seeks, a relatively small number. Use a SSD if seeks are bottlenecking you.

यदि आपके 15 कॉलम में प्रत्येक 100 बाइट हैं, और आपके पास उनमें से 150 हैं, तो प्रति उपयोगकर्ता आपका अधिकतम डेटा स्थानांतरण 256k ऑर्डर का है। मैं एप्लिकेशन को केवल संपर्क संपर्क डेटा दिखाने के लिए डिज़ाइन करता हूं (शीर्ष 3 सबसे उपयोगी संपर्क बिंदु - नाम, ईमेल, फोन) कहें, फिर विशेष संपर्कों के लिए अनुरोध किए जाने पर अधिक विशिष्टताओं को खींचने के लिए। (संभवतः) दुर्लभ मामलों में जब आपको सभी संपर्कों की जानकारी की आवश्यकता होती है (उदाहरण के लिए सीएसवी को निर्यात करें) पर विचार करें आउटपुट में चुनें । vCard आउटपुट कम प्रदर्शनकारी होगा: आपको सभी डेटा प्राप्त करने की आवश्यकता होगी, फिर सही प्रारूप में सामान डालना होगा। यदि आपको अक्सर vCard की आवश्यकता होती है, तो डेटाबेस अद्यतन होने पर vCard लिखने पर विचार करें (कैशिंग दृष्टिकोण)।

यदि प्रदर्शन आवश्यकताओं को अभी भी पूरा नहीं किया गया है, तो उपयोगकर्ता आईडी पर विभाजन करना

सामान्य उत्तर

स्केलेबिलिटी प्लान को दस्तावेज करते समय, अपनी स्कीमा कोआईआईएसएस और अपनी प्रदर्शन आवश्यकताओं के आसपास डिज़ाइन करें।

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

वैसे भी, यदि कार्यान्वयन के बाद आपको लगता है कि प्रदर्शन आवश्यकताओं को पूरा नहीं किया गया है, तो मैं सुझाव दूंगा कि आप तेजी से हार्डवेयर, विभिन्न इंजन (उदाहरण के लिए MyISAM बनाम InnoDB - स्केलिंग के बारे में सोचें) - अपने विशेष MySQL संस्करण के लिए मतभेद क्या हैं!), भौतिक दृश्य , या विभाजन (उदाहरण के लिए संबंधित उपयोगकर्ता नाम के पहले अक्षर के आसपास - मान लीजिए कि आपके पास एक है)।

1
जोड़ा
"तेज़" एक भारित शब्द है। चाहे यह आपके मामले में तेज़ हो या नहीं, आप जो कर रहे हैं उस पर निर्भर करता है। उदाहरण के लिए देखें यह पोस्ट MySQL पर प्रदर्शन ब्लॉग । (और मुझे नहीं लगता कि एक -1 उचित है, पेशेवरों और विपक्ष के लिए उस पोस्ट को पढ़ें - मैं सामान्य रूप से नहीं कह रहा हूं कि माईसाम तेज है: मैंने "मेरे पास सभी तथ्यों नहीं हैं" के साथ गुफा किया।)
जोड़ा लेखक bishop, स्रोत
@ N.B। समझा और बिंदु लिया। मेरे मूल उत्तर में मेरा शब्द पसंद गलत था। मैंने अपने जवाब में "तेज़" हटा दिया। यह गलत शब्द है। मैंने "अलग" के साथ प्रतिस्थापित किया, जैसा कि MyISAM/हो सकता है/इस/विशेष/स्थिति में एक/अच्छा/पसंद हो सकता है।
जोड़ा लेखक bishop, स्रोत
@RaymondNijland: मैंने इस स्थिति में चलाया है , और मैं इसे दूर करने के लिए माईसाम का उपयोग करता हूं।
जोड़ा लेखक bishop, स्रोत
@ रेमंड निजलैंड: सहमत मैंने पढ़ा है (लेकिन परीक्षण नहीं किया है) कि 5.7 इनओडीबी पर COUNT के लिए WHERE और INDEX ऑप्टिमाइज़ेशन का समर्थन कर सकता है, लेकिन मेरे विशेष मामले में मुझे और बाधा है: मैं अब के लिए पिछले v5.5 को अपग्रेड नहीं कर सकता। संयोग से, इनओएसबीबी पर माईसाम के लिए एक और उदाहरण यह है कि v5.7 से पहले, इनो डीबी के पास स्थानिक प्रकार नहीं थे - मुझे इच्छित प्रश्न पूछने के लिए अंतर्निहित ब्लॉब हैकिंग का सहारा लेना पड़ा।
जोड़ा लेखक bishop, स्रोत
-1 InnoDB पर MyISAM के लिए (नहीं, यह वास्तव में तेज़ नहीं है)।
जोड़ा लेखक N.B., स्रोत
-1 उत्तर के लिए एक अच्छा जवाब नहीं है। MyISAM/InnoDB इतनी सारी चीजों में भिन्न है, और चूंकि आप परकोना ब्लॉग पढ़ रहे हैं, तो मुझे यकीन है कि आप अंतर से परिचित हैं। इस दिन और उम्र में वस्तुतः कोई कारण नहीं है कि क्यों कोई मायिसम का उपयोग करेगा, जिसने वास्तव में अब तक अपना सर्वश्रेष्ठ दिया है। एक इंजन पर पुराने इंजन का सुझाव देना जो वास्तव में वास्तव में अच्छी तरह से बनाया गया है, एक बुरा सुझाव है और कोई शायद आपके उत्तर को Google करेगा और लगता है कि माईसाम वास्तव में तेज़ या बेहतर विकल्प है। संपादित करें: डाउनवोट हटा दिया गया।
जोड़ा लेखक N.B., स्रोत
InnoDB कई तरीकों से MyISAM से बहुत बेहतर है इस vimeo.com/20990641
जोड़ा लेखक Sam D, स्रोत
MyISAM तेजी से InnoDB? हां साल 2000 में शायद ..
जोड़ा लेखक Raymond Nijland, स्रोत
आपको वास्तव में यह पढ़ना चाहिए "माईसाम की तुलना में, इनओडीबी ने 36 सीपीयू कोरों में 9 0% स्केलेबिलिटी के साथ रीड-ओनली टेस्ट पर 35x उच्च थ्रूपुट और रीड-ओनली टेस्ट पर 5x उच्च थ्रूपुट दिया।" ... oracle.com/partners/en/knowledge-zone/& hellip; और blogs.oracle.com/MySQL/entry/…
MyISAM प्रत्येक सम्मिलन/अद्यतन पर लॉक करेगा ... इस प्रश्न के लिए अच्छा नहीं है .. InnoDB वास्तव में इस मामले में सबसे अच्छा विकल्प है और हां ऐसे मामले हैं जब आप MyISAM का उपयोग करना चाहते हैं (अभी एक नहीं सोच सकता ...)
जोड़ा लेखक Raymond Nijland, स्रोत
@ बिशप हां इनो डीबी एक लेनदेन आधारित इंजन है, इसलिए एक पूर्ण टेबल स्कैन की आवश्यकता है .. MyISAM MyISAM फ़ाइलों के भीतर रिकॉर्ड COUNT संग्रहीत करके धोखा देती है (यह जवाब देने के लिए एक सस्ता क्वेरी बनाता है) .. लेकिन यह वास्तव में एक अच्छा उदाहरण है लेकिन सबसे अधिक संभावना InnoDB इंजन MyISAM इंजन को बेहतर प्रदर्शन करेगा जब COUNT को प्राथमिक या किसी माध्यमिक अनुक्रमणिका के साथ संयोजन में उपयोग किया जाता है
जोड़ा लेखक Raymond Nijland, स्रोत

मैं एक डीबीए नहीं हूं, लेकिन मेरा सुझाव है कि आप डेटाबेस को सामान्य रूप से सामान्यीकृत करें, इंडेक्स जोड़ें, आदि और संभावित गैर-प्रदर्शन प्रदर्शन समस्या को पूरा करने के लिए इसे खराब नहीं करें। यदि संभव हो, तो एक डीबीए अपनी स्कीमा की समीक्षा करें। मुझे नहीं लगता कि 20,000 उपयोगकर्ता अत्यधिक हैं। सभी 200,000 उपयोगकर्ता एक ही व्यक्ति के इनपुट को संसाधित करने के लिए एक ही एक्स मिलीसेकंड में अपडेट बटन हिट करने की संभावना नहीं रखते हैं। केवल कुछ ही लॉग इन होंगे और उनमें से अधिकतर डेटा अपडेट कर रहे हैं या उस अपडेट बटन को मारने के बजाय वेब पेज पर मौजूदा डेटा पर देख रहे होंगे। यदि मौके से उन्हें एक गुच्छा एक ही समय में मारा जाता है, तो शायद दुर्घटना के बजाय प्रदर्शन प्रतीक्षा होगी। यहां आपकी स्कीमा के लिए एक मोटा लेआउट है (माइलेज भिन्न हो सकता है):

User
long userID primary key
String firstName
String lastName

Contact
long contactID primary key
long userID foreign key
String firstName
String lastName

Address
long addressID primary key
long contactID foreign key

0
जोड़ा

एक तालिका है, लेकिन तालिका के विभाजन तालिका के उपयोगकर्ता के प्रारंभिक वर्णमाला द्वारा तालिका को सभी ए के साथ शुरू होने वाले अंतिम नाम 1 विभाजन में लोड किया जाएगा। बी से शुरू होने वाले सभी नाम दूसरे विभाजन में लोड किए जाएंगे।

सही वितरण कुंजी खोजने के लिए आप कुछ प्रोफाइलिंग भी कर सकते हैं।

0
जोड़ा