लाखों उपयोगकर्ताओं का प्रबंधन कैसे करें?

17

मैं वास्तव में कुछ बड़ा लॉन्च करने वाला हूं। मुझे अपना सर्वर और डेटाबेस तैयार करना होगा।

मैं 100,000 उपयोगकर्ता के प्रत्येक सेट को अलग-अलग उपयोगकर्ता तालिकाओं में समूहित करना चाहूंगा लेकिन मुझे नहीं पता कि उपयुक्त उपयोगकर्ता तालिका में लॉग इन करने की कोशिश कर रहे एक उपयोगकर्ता को कैसे जोड़ा जाए।

उदाहरण के लिए, मुझे कैसे पता चलेगा कि उपयोगकर्ता jay@mail.comउपयोगकर्ता तालिका # 36 से संबंधित है?

क्या एक उपयोगकर्ता तालिका या 100,000 में से 100 में 10 करोड़ उपयोगकर्ता होना समान होगा?

फेसबुक कैसे करता है? मुझे विश्वास नहीं हो रहा है कि उनके पास 950 मिलियन प्रविष्टियों के साथ एक वैश्विक उपयोगकर्ता तालिका होगी।

mysql users

— JNK
स्रोत

I can't believe they would have one global user table with 950 million entries.मैं कर सकता हूँ, यह इतना बड़ा नहीं है । मैंने बड़ी तालिकाओं के साथ काम किया है। यह बहुत आम है। यदि आपके पास बहुत अधिक अन्य डेटा है तो दूसरा विकल्प मैं एक NoSQL डेटाबेस होगा।

— निमचिम्प्सकी

5

यदि आप बड़ी संख्या में उपयोगकर्ताओं और बड़ी मात्रा में डेटा रखने की योजना बना रहे हैं, तो आपको इसे डिजाइन करने के लिए एक डेटाबेस विशेषज्ञ को नियुक्त करना होगा। मैं किसी ऐसे व्यक्ति को नहीं देखूंगा जिसके पास कम से कम दस साल का डेटाबेस अनुभव और कम से कम 5 साल के बड़े डेटाबेस डिजाइन का अनुभव नहीं है। यह एक जटिल उपक्षेत्र है जिसमें व्यापक ज्ञान की आवश्यकता होती है।

— HLGEM

30

आपके पास कल एक बिलियन उपयोगकर्ता नहीं होंगे और MySQL बिना किसी समस्या के कई मिलियन पंक्तियों को संभाल सकता है। मेरी उपयोगकर्ता तालिका में 5 मिलियन उपयोगकर्ता हैं और मुझ पर भरोसा करते हैं, यह चिंता करने वाली चीजों के मेरे रडार पर भी नहीं है।

जब तक आपको इसे करने की आवश्यकता नहीं है, तब तक इसे तेज करने की चिंता न करें । आप एक समस्या के लिए समय से पहले अनुकूलन करने का प्रयास कर रहे हैं जो कभी मौजूद नहीं हो सकती है या इस प्रक्रिया में, आप गंभीर रूप से उस दर को अपंग कर सकते हैं जिस पर आप नया कर सकते हैं। लॉन्च करने और समस्याओं को खोजने के लिए तेजी से रहें जैसे वे आते हैं। आप पहले से अनुमान नहीं लगा सकते हैं कि आपकी स्केलिंग चुनौतियाँ क्या होंगी।

जब और यदि आप कभी इस पैमाने पर पहुंचते हैं, तो आपके पास इस तरह की समस्या को फेंकने के लिए बहुत पैसा और संसाधन होंगे।

— हारून ब्राउन
स्रोत

4

Be fast to launch and find the problems as they comeयह हिस्सा उत्कृष्ट है। यह सच है। यदि हमें समस्याएँ आती हैं, क्योंकि वे आते हैं तो बाद के समय में कोई गंभीर समस्या नहीं होगी। +1

— ALH

16

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

एक टेबल में 10M टुपल्स के बारे में, अगर आपके पास अच्छी इंडेक्सिंग है तो यह ठीक रहेगा। हमें यहां (बेची गई वस्तुएं) एक टेबल में कई 100 मीटर ट्यूपल स्टोर करने की जरूरत है, जो एक बड़े ओरेकल 11 जी पर ठीक काम करता है

यहाँ फेसबूक डीबी डिज़ाइन के फ़ेसबुक : फेसबुक डेटाबेस डिज़ाइन के साथ 2010 से एक पोस्टिंग है

आप इस तरह के विभाजन प्रकारों के बारे में mysql प्रलेखन को पढ़ना चाह सकते हैं: MySQL दस्तावेज़ीकरण: पार्टीइनिंग

MySQL इन प्रकारों का समर्थन करता है:

रेंज विभाजन। इस प्रकार का विभाजन किसी दिए गए सीमा के भीतर गिरने वाले स्तंभ मानों के आधार पर विभाजन को पंक्तियाँ प्रदान करता है। धारा 18.2.1, "श्रेणी विभाजन" देखें।

सूची विभाजन। RANGE द्वारा विभाजन के समान, सिवाय इसके कि विभाजन को असतत मानों के एक सेट से मेल खाते स्तंभों के आधार पर चुना जाता है। धारा 18.2.2, "सूची विभाजन" देखें।

एचएएसएच विभाजन। इस प्रकार के विभाजन के साथ, एक विभाजन को उपयोगकर्ता-परिभाषित अभिव्यक्ति द्वारा लौटाए गए मूल्य के आधार पर चुना जाता है जो तालिका में सम्मिलित किए जाने वाली पंक्तियों में स्तंभ मानों पर काम करता है। फ़ंक्शन में MySQL में मान्य कोई भी अभिव्यक्ति शामिल हो सकती है जो एक nonnegative पूर्णांक मान प्राप्त करता है। इस प्रकार का एक विस्तार लाइनर एचएएसएच भी उपलब्ध है। धारा 18.2.3, "एचएएसएच विभाजन" देखें।

कुंजी विभाजन। इस प्रकार का विभाजन एचएएसएच द्वारा विभाजन के समान है, सिवाय इसके कि मूल्यांकन किए जाने वाले केवल एक या अधिक स्तंभों की आपूर्ति की जाती है, और MySQL सर्वर अपना स्वयं का हैशिंग फ़ंक्शन प्रदान करता है। इन स्तंभों में पूर्णांक मानों के अलावा अन्य हो सकते हैं, क्योंकि MySQL द्वारा आपूर्ति की गई हैशिंग फ़ंक्शन स्तंभ डेटा प्रकार की परवाह किए बिना पूर्णांक परिणाम की गारंटी देता है। इस प्रकार का एक विस्तार, LINEAR KEY भी उपलब्ध है। धारा 18.2.4, "कुंजी विभाजन" देखें।

— बत्तख
स्रोत

7

सबसे पहले, उपयोगकर्ताओं को अलग-अलग तालिकाओं में अलग न करें। यह चीजों को जटिल और व्यर्थ बना देगा। MySQL और अन्य जैसे डेटाबेस किसी भी समस्या के बिना एक ही तालिका में लाखों रिकॉर्ड के डेटाबेस के साथ काम कर सकते हैं (सही प्राथमिक कुंजी सेट होने पर)। प्रत्येक उपयोगकर्ता (मुख्य उपयोगकर्ता तालिका में) के लिए डेटाबेस AUTO_INCREMENT और PRIMARY अद्वितीय कुंजी फ़ील्ड का उपयोग करें, इसलिए प्रत्येक रिकॉर्ड अद्वितीय (UID) है। फिर अन्य तालिकाओं में आप उस विशिष्ट आईडी का उपयोग करके संदर्भित कर रहे हैं। फिर सुनिश्चित करें कि आपने जो प्रत्येक तालिका PRIMARY KEY के रूप में सेट की है, वह डेटाबेस सर्वर में सूचना के प्रसंस्करण को गति प्रदान करेगी। आप Drupal CMS से सीख सकते हैं कि यह उपयोगकर्ता की जानकारी को कैसे संग्रहीत कर रहा है। लाखों उपयोगकर्ताओं और बहुत बड़ी कंपनियों (बड़ी मीडिया कंपनियों, सरकार, यहां तक कि दुनिया के सबसे बड़े बैंकों द्वारा उपयोग किए गए) द्वारा 10 से अधिक वर्षों में परीक्षण किया गया। Www.drupal पर। org आपको एक ही तालिका में संग्रहीत 1,6 मिलियन से अधिक पृष्ठ (नोड) मिलेंगे और इसमें प्रति माह मिलियन से अधिक अद्वितीय आगंतुक हैं और वेबसाइट बिना किसी गड़बड़ के काम करती है। सब कुछ उचित अनुकूलन और विन्यास के बारे में है।

10 लाख रिकॉर्ड के बाद, यदि आप प्रदर्शन से खुश नहीं हैं (उचित अनुकूलन और डीबी कॉन्फ़िगरेशन में बदलाव के बाद), तो आप तय कर सकते हैं कि क्या आप वास्तव में अलग-अलग तालिकाओं द्वारा उपयोगकर्ताओं को अलग करना चाहते हैं। तो आप वास्तव में नई तालिका जोड़कर कार्यक्षमता का विस्तार कर सकते हैं, जिसमें उपयोगकर्ताओं के रिकॉर्ड रखने के बारे में जानकारी है: UID और table_name। फिर किसी भी अन्य तालिका में इन सूचनाओं का अनुरोध किया जाता है, यह तालिका सही तालिका की तलाश करेगी। लेकिन मैं वास्तव में आपको उपयोगकर्ताओं के लिए एक बड़ी तालिका रखने की सलाह देता हूं, जब तक कि आपके पास 10-100 लाख से अधिक रिकॉर्ड न हों। लेकिन यह प्रदर्शन में बहुत सुधार नहीं करेगा (डेटाबेस विशाल डेटा से निपटने के लिए डिज़ाइन किया गया है)। जानकारी को सरल रखना बेहतर है। आमतौर पर कंपनियां सिर्फ एक और डेटाबेस सर्वर (मास्टर और दास), और दूसरे के लिए तय करती हैं, फिर वे ' लोड संतुलन कार्यक्षमता के साथ मिलकर काम करना। यदि आपके पास उन 10 लाखों उपयोगकर्ता हैं, तो आप दूसरे db सर्वर के लिए भुगतान कर सकते हैं, है ना?

User.install फ़ाइल userमें टेबल स्कीमा का उदाहरण देखें ।

— kenorb
स्रोत

3

जैसा कि अन्य उत्तर बताते हैं, उपयोगकर्ताओं को कई तालिकाओं में विभाजित करने के लिए यह एक अच्छा विचार नहीं है। उपयोगकर्ता पर अनुक्रमित वाले अधिकांश डेटाबेस, लाखों पंक्तियों को संभाल सकते हैं। हालाँकि, अनुक्रमणिका की कुल संख्या के आधार पर प्रति प्रश्न विलंबता बढ़ सकती है। जब तक डाटासेट छोटा है, तब तक आप सामान्य डेटाबेस में एकल तालिका के साथ प्रबंधन कर सकते हैं।

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

एक महत्वपूर्ण बात यह है कि आप ध्यान दें कि आप nosql डेटाबेस के साथ शामिल नहीं कर सकते हैं। इसलिए, अपने usecase के लिए योजना बनाएं और निर्णय लें। यदि जॉइन और मल्टी-रिकॉर्ड लेनदेन आपके लिए एक आवश्यकता है तो नोसक्ल डेटाबेस आपके लिए नहीं हैं।

— सुनील
स्रोत

-3

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

— mnmnc
स्रोत

9

यह एक सुपर बुरा विचार है। उदाहरण के लिए, आपके सॉफ़्टवेयर को पंक्तियों को स्वचालित रूप से माइग्रेट करना होगा यदि उपयोगकर्ता अंतिम नाम बदलते हैं .... जब तक आप स्थिरता के बारे में देखभाल करना बंद नहीं करते हैं। यह रणनीति उन प्रकार की आकस्मिकताओं को आमंत्रित करती है।

— रैंडमक्स