इवेंट फ़ीड कार्यान्वयन - क्या यह स्केल करेगा?

Question

स्थिति:

मैं वर्तमान में एक सामाजिक वेबसाइट जिससे प्रत्येक उपयोगकर्ता को अपने मित्रों की गतिविधियों की एक फ़ीड के लिए एक फ़ीड प्रणाली को डिजाइन करने कर रहा हूँ। मेरे पास फ़ीड बनाने के लिए दो संभावित तरीके हैं और मैं पूछना चाहता हूं कि स्केल करने की क्षमता के मामले में कौन सा सर्वोत्तम है।

सभी उपयोगकर्ताओं की घटनाओं को एक केंद्रीय डेटाबेस तालिका, event_log में एकत्रित किया जाता है। उपयोगकर्ताओं को friends तालिका में दोस्तों के रूप में जोड़ा जाता है। आरडीबीएमएस हम उपयोग कर रहे हैं MySQL है।

स्टैंडर्ड विधि: जब कोई उपयोगकर्ता अपने फ़ीड पृष्ठ का अनुरोध करता है, सिस्टम भीतरी friends साथ event_log में शामिल होने से फ़ीड उत्पन्न करता है। नतीजा तब कैश किया जाता है और 5 मिनट के बाद टाइमआउट पर सेट किया जाता है। इस टाइमआउट को बदलकर स्केलिंग हासिल की जाती है।

की परिकल्पना यह विधि: एक टास्क पृष्ठभूमि में और event_log में प्रत्येक नए, असंसाधित आइटम के लिए चलता है, यह डेटाबेस तालिका user_feed में प्रविष्टियों उपयोगकर्ताओं को, जो दोस्तों के उपयोगकर्ता के लिए जो पहल की साथ कर रहे हैं के सभी के साथ है कि घटना अपने आप युग्मन बनाता है घटना। एक टेबल पंक्ति एक उपयोगकर्ता के साथ एक घटना जोड़ता है।

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

मेरी आंखों में अनुमानित समाधान बहुत बेहतर लगता है; सभी प्रसंस्करण ऑफ़लाइन किया जाता है, इसलिए कोई भी उपयोगकर्ता उत्पन्न करने के लिए किसी पृष्ठ की प्रतीक्षा नहीं करता है और इसमें कोई भी शामिल नहीं होता है, इसलिए भौतिक मशीनों में डेटाबेस टेबल को शेड किया जा सकता है। हालांकि, यदि किसी उपयोगकर्ता के पास 100,000 मित्र हैं और एक सत्र में 20 ईवेंट बनाते हैं, तो परिणामस्वरूप डेटाबेस में 2,000,000 पंक्तियां डालने लगती हैं।

प्रश्न:

• इस बुरी से बुरी हालत समस्याग्रस्त ऊपर उल्लेख किया है, यानी तालिका आकार करता MySQL प्रदर्शन पर प्रभाव पड़ता है और वहाँ किसी भी कर रहे हैं:

  प्रश्न दो अंक करने पर निर्भर करता प्रत्येक घटना के लिए डेटा के इस द्रव्यमान सम्मिलन के साथ मुद्दों?

• क्या कोई और चीज है जिसे मैंने याद किया है?

Answer 1

मुझे लगता है कि आपकी परिकल्पना प्रणाली बहुत अधिक डेटा उत्पन्न करती है; सबसे पहले वैश्विक स्तर पर user_feed पर स्टोरेज और अनुक्रमण आवश्यकताओं को तेजी से बढ़ना प्रतीत होता है क्योंकि आपका उपयोगकर्ता-आधार बड़ा हो जाता है और अधिक अंतःस्थापित (दोनों सोशल नेटवर्क के लिए संभवतः वांछनीय); दूसरी बात यह मान लीजिए कि एक मिनट के 1000 उपयोगकर्ताओं के दौरान प्रत्येक ने एक नया संदेश दर्ज किया था और प्रत्येक के पास 100 मित्र थे - तो आपके पृष्ठभूमि धागे में 100 000 आवेषण हैं और जल्दी से पीछे आ सकते हैं।

मुझे आश्चर्य है कि आपके दो प्रस्तावित समाधानों के बीच एक समझौता किया जा सकता है जहां पृष्ठभूमि थ्रेड एक तालिका को अंतिम_user_feed_update अद्यतन करता है जिसमें प्रत्येक उपयोगकर्ता के लिए एक पंक्ति होती है और अंतिम बार उपयोगकर्ता फ़ीड को बदल दिया जाता है।

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

Answer 2

जब आप अधिकतम संख्या में दोस्तों को सीमित करते हैं तो हाइपोथिज्ड विधि बेहतर काम करती है .. बहुत सी साइटें फेसबुक आईआईआरसी सहित सुरक्षित ऊपरी सीमा निर्धारित करती हैं। यह आपके 100K मित्र उपयोगकर्ता गतिविधि उत्पन्न करते समय 'हिचकी' को सीमित करता है।

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

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