फेसबुक जैसी संदेशों के लिए डेटाबेस डिज़ाइन

Question

मैं वर्तमान में PHP/MySQL में एक नई प्रणाली की योजना बना रहा हूं और यह सुनिश्चित करना चाहता हूं कि मेरा डेटाबेस उस डेटा की मात्रा को संभाल सके जो मैं स्टोर करने की योजना बना रहा हूं। मेरी नई परियोजना की विशेषताओं में से एक फेसबुक जैसी "संदेश" सुविधा है। मैं यह सुनिश्चित करना चाहता हूं कि मैं अंतिम उपयोगकर्ता के लिए सबसे अच्छा संभव अनुभव बनाएं। वेबसाइट अंततः संभावित रूप से लाखों संदेशों के सामूहिक रूप से 1000 उपयोगकर्ताओं को संभालती है। डेटाबेस डिजाइन के लिए सबसे अच्छा तरीका क्या होगा? क्या MySQL भी उपयोग करने के लिए सही डेटाबेस है?

Answer 1

MySQL को लाखों या लाखों रिकॉर्ड के साथ कोई समस्या नहीं है जब तक कि आप सही ढंग से डेटाबेस डिज़ाइन करते हैं।

कहा जा रहा है कि, "फेसबुक जैसी संदेश सुविधा" एक बहुत व्यापक परिभाषा है। आम तौर पर, आप messages तालिका को परिभाषित करेंगे जो प्रत्येक संदेश को उस उपयोगकर्ता को लिंक करता है जिसने इसे बनाया है (यानी, संदेश तालिका में userId कॉलम है)। यदि आप संदेशों को एकाधिक उपयोगकर्ताओं पर जाना चाहते हैं, तो आपके पास तालिका है जो messageId और recipientId से युक्त कई रिकॉर्ड संग्रहीत करके 1 से कई रिश्ते को परिभाषित करती है। इन तालिकाओं में उचित अनुक्रमणिका जोड़ें और आप वहां से 80% रास्ते हैं।

कहा जा रहा है कि शेष 20% एक हत्यारा हो सकता है। दुर्भाग्यवश, आप अपने डेटाबेस का उपयोग कैसे करते हैं यह निर्धारित करने जा रहा है कि आपको और क्या करना है, और आपको उन निर्णयों से पहले अपने आवेदन के बारे में बहुत अधिक जानकारी प्रदान करनी होगी। उदाहरण के लिए, आप ऑटो-संग्रहण समाधान रखने पर विचार करना चाहेंगे जो मुख्य तालिका को अपेक्षाकृत छोटा रखता है, और पुराने डेटा को बैकअप टेबल पर ले जाता है जिसे आवश्यक होने पर एक्सेस किया जा सकता है। आपको शायद इसकी आवश्यकता नहीं होगी, लेकिन यह भविष्य में मदद कर सकता है।

Answer 2

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

आपके प्रश्न के उत्तर में हाँ mysql आसानी से लाखों रिकॉर्ड्स को संभाल सकता है अगर डिज़ाइन अच्छा है और डिज़ाइन खराब होने पर दुःस्वप्न होगा, तो किसी भी अन्य आधुनिक डाटाबेस की तरह।

Answer 3

जब तक आप अपनी तालिकाओं को संबंध बनाने के लिए सेट करते हैं और तालिकाओं के बीच संबंध सेट करते हैं, तो MySQL ठीक होना चाहिए।

क्या मैं पोस्टग्रेस का सुझाव भी दे सकता हूं?

Answer 4

फेसबुक ने MySQL के साथ शुरुआत की और वे केवल Cassandra पर चले गए जब उनके पास 100 मिलियन से अधिक उपयोगकर्ताओं के लिए 7TB इनबॉक्स डेटा था।

स्रोत: Lakshman, Malik: Cassandra - A Decentralized Structured Storage System।

Answer 5

यदि आप बजट पर हैं, तो MySQL से शुरू करें और ज़ेंड :: डीबी या उच्च स्तर के सिद्धांत पर सिस्टम का उपयोग करें।

शुरुआत में अपने डीबीएमएस चुनने के लिए डीएमबीएस स्विच करना आसान बनाना अधिक महत्वपूर्ण है।

Answer 6

आप जो सीखना चाहते हैं उस पर आप बहुत सटीक नहीं हैं। ठीक है। मैं आपको कुछ सलाह देने की कोशिश करूंगा।

1. सामान्यीकरण
2. इंडेक्स पर अधिक लोड तालिकाओं के लिए
3. MyISAM
4. असमान्यीकरण (sic!), लेकिन आप को समझना चाहिए कि आप लचीलापन

Answer 7

Sharding निश्चित रूप से अपने "मोटे तौर पर" आधारित आवश्यकताओं के लिए आवश्यक नहीं है के लिए क्या कर रहे हैं

Sharding

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

से ऊपर है, जबकि आधा सो तो लिखने की त्रुटियों पर ध्यान न दें लिखा गया था;)

Answer 8

तुम्हारा मतलब तो "मेरे mysql तालिका संदेश प्रणाली के लिए कैसे दिखाई देते हैं चाहिए", मैं अपने संदेश प्रणाली में निम्नलिखित कॉलम का उपयोग करें:

message_id 
fromuser 
fromview 
fromstatus 
touser 
toview 
tostatus 
title 
text 
poston 
thread 

संदेश_आईडी auto_increment है, जाहिर है। Fromuser और touser स्पष्ट हैं। Fromstatus और टोस्टैटस सक्रिय, हटाया, शुद्ध, ड्राफ्ट, और इसी तरह है। समीक्षा और दृश्य 'हां' और 'नहीं' पर सेट हैं। शीर्षक, पाठ, और 'पोस्टन' तिथि स्पष्ट हैं। थ्रेड आपके एचटीएमएल फॉर्म और संदेश डिस्प्ले स्क्रिप्ट के आधार पर आपके हिस्से पर थोड़ा सा प्रयास कर सकता है।

अपने फॉर्म के लिए, "to:" फ़ील्ड के आधार पर फ़ोरैच लूप बनाएं और प्रत्येक प्राप्तकर्ता के लिए एक प्रति सहेजें।

मुझे उम्मीद है कि इस संदेश प्रणाली में लाखों लोगों को पकड़ने की उम्मीद है, लेकिन लाखों शायद कुछ साल दूर हैं। मैं इसे छोटा और सरल रख रहा हूं।

Answer 9

यदि आप अपने डेटाबेस को सही ढंग से डिज़ाइन करते हैं, तो प्रदर्शन डेटा की मात्रा के साथ logarithmically खराब हो जाना चाहिए। दूसरे शब्दों में, आपके प्रश्नों को निष्पादित करने का समय डेटा की मात्रा से बहुत धीमा हो जाएगा।

इस लक्ष्य को प्राप्त करने के लिए, आप चीजों की एक संख्या के बारे में अनुशासित रहना होगा:

• आपका डेटाबेस डिजाइन ध्वनि होना चाहिए। ER modeling को समझना और सामान्यीकरण आवश्यक है। तो anatomy of indexes और अन्य भौतिक डेटा संरचनाओं को समझ रहा है।
• आपके पास एक सामान्य सामान्यीकृत डेटाबेस होने के बाद, इस पर विचार करें कि इसके कुछ "किनारों" को निष्पादन कारणों से पूरी तरह से अनौपचारिक रूप से denormalized किया जाना चाहिए। विशेष रूप से प्रश्नों का क्या आप जानते हैं आप की आवश्यकता होगी, पर सूचकांक नहीं सूचकांक - तदनुसार
  • डिजाइन अनुक्रमित:
  • इस पूरी प्रक्रिया के दौरान, यह ध्यान रखें प्रश्नों की किस तरह कर अपने क्लाइंट अनुप्रयोग होगा!
  • प्राकृतिक डिजाइन बनाम सरोगेट कुंजी के उपयोग और पहचान बनाम गैर-पहचान वाले संबंधों के उपयोग जैसे कुछ डिज़ाइन निर्णय आपके लिए आवश्यक जॉइन की मात्रा को प्रभावित कर सकते हैं। अपने डेटाबेस डिजाइन, index-only scans आदि
• उपयोग डीबीएमएस विशेष तंत्र, जैसे clustering, विभाजन, कुंजी संपीड़न क्लस्टर सीमा स्कैन करने के लिए अनुकूल रखने के लिए
• प्रयास करें, अपने लाभ के लिए materialized दृश्य (आदि ..)। यदि डीबीएमएस कुछ तंत्र का समर्थन नहीं करता है जिसे आप आवश्यक मानते हैं, तो डीबीएमएस स्विच करने से डरो मत!उदाहरण के लिए, InnoDB tables are always clustered, जो कि पीके पर पूछताछ करते समय एक लाभ है, लेकिन यदि आपको द्वितीयक अनुक्रमणिका की आवश्यकता होती है तो यह नुकसान हो सकता है। यदि आपको क्लस्टर्ड और हीप-आधारित दोनों टेबलों की आवश्यकता है, तो कुछ डीबीएमएस का उपयोग करें जो दोनों का समर्थन करते हैं (जैसे ओरेकल या एमएस एसक्यूएल सर्वर)।
• ग्राहक आवेदन सावधानी से कोड करें। धार्मिक रूप से बाध्य पैरामीटर और क्वेरी preparation का उपयोग करें - न केवल आप SQL पार्सिंग और क्वेरी प्लानिंग ओवरहेड को कम कर देंगे, लेकिन एसक्यूएल-इंजेक्शन-प्रतिरोधी भी होंगे! ओआरएम और पुस्तकालय अक्सर आपको इसे मैन्युअल रूप से करने से बचाएंगे, लेकिन आपको अभी भी समझना चाहिए कि "कवर के तहत" क्या हो रहा है।
• और अंतिम लेकिन कम से कम नहीं, धारणाओं पर रिले नहीं करें - माप इसके बजाय! डेटाबेस प्रदर्शन एक बढ़िया (और जटिल) संतुलन अधिनियम हो सकता है, और कुछ निर्णयों का प्रभाव तुरंत स्पष्ट नहीं हो सकता है

यदि आप यह सब सही तरीके से करते हैं, तो आपको वास्तविक फेसबुक की डेटा की मात्रा तक पहुंचना होगा एक "क्लासिक" डीबीएमएस पर्याप्त होने से पहले। उपयोगकर्ताओं और लाखों या संदेशों के 1000s इस संदर्भ में "बड़े" के रूप में भी योग्य नहीं हैं।

---

एक डीबीएमएस के नजरिए से "ग्राहक" - इस रूप में अच्छी तरह एक मध्यम स्तरीय हो सकता है।

MyISAM भी क्लस्टर नहीं है, लेकिन (जैसे लेनदेन समर्थन के अभाव के रूप में) गंभीर सीमाओं कि वैसे भी सामान्य उपयोग से यह अयोग्य घोषित करना चाहिए है।

Answer 10

मैं था कहते हैं कि वस्तु उन्मुख डेटाबेस के साथ-साथ NoSQL सिस्टम के बारे में पढ़ा है, यह एक बहुत ही दिलचस्प अवधारणा है, सक्रिय रूप से रेल पर रूबी की तरह प्रसिद्ध चौखटे द्वारा प्रयोग किया जाता है, जो आप अपने डेटा के बारे में कम चिंता करने की अनुमति देता है, आप कर सकते हैं के बाद से बस अपनी ऑब्जेक्ट को सीधे डेटाबेस में डंप करें, मुझे पता है कि यह थोड़ा सा विषय है लेकिन कम जटिल डेटाबेस का मतलब आसान संक्रमण स्केलेबल सिस्टम में है, और मैं केवल जागरूकता फैल रहा हूं

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