आपका कोड मुझे बहुत कुछ नहीं बताता; मुझे लगता है कि यह मददगार होगा यदि आप अपनी डेटा संरचना को सादे JSON / SQL में रख सकते हैं।
वैसे भी, मैं प्रत्येक उपयोगकर्ता की स्ट्रीम को मोंगोडीबी में क्रमबद्ध करता हूं। मैं विभिन्न कारणों से डेटाबेस में एचटीएमएल को स्टोर नहीं करता (कम से कम सॉफ्टवेयर के उस स्तर पर नहीं); इसके बजाय, आपको प्रासंगिक डेटा को (संभवतः बहुरूपी) संग्रह में सहेजना चाहिए। न्यूज़फ़ीड प्राप्त करना बहुत आसान है, इंडेक्सेशन सीधा है, आदि। दृश्य संरचना अनिवार्य रूप से नहीं बदलेगी। यदि आप बाद में HTML को बदलना चाहते हैं, तो यह भी आसान है।
नकारात्मक पक्ष यह है कि यह बहुत सारे डेटा को डुप्लिकेट करेगा। अगर लोगों के बहुत सारे अनुयायी हो सकते हैं, तो यह एक समस्या बन सकती है। एकल उपयोगकर्ता आईडी के बजाय उपयोगकर्ता आईडी की सरणियों का उपयोग करने से मदद मिल सकती है (यदि जानकारी सभी अनुयायियों के लिए समान है), लेकिन यह भी सीमित है।
बहुत बड़ी एसोसिएशन समस्याओं के लिए, केवल कैशिंग है। जिस तरह से मैं इसे समझता हूं, फेसबुक और ट्विटर दोनों में जादू यह है कि वे अक्सर डीबी हिट नहीं करते हैं और रैम में बहुत सारा डेटा रखते हैं। यदि आप अरबों वस्तुओं को जोड़ रहे हैं, तो ऐसा करना RAM में भी एक चुनौती है।
अपडेट लगातार लिखे जाने चाहिए न कि घंटे के आधार पर। मान लीजिए कि आपके पास बहुत अधिक ट्रैफ़िक है, और प्रति घंटा अपडेट में 30 मिनट लगते हैं। अब, सबसे खराब स्थिति 90 मिनट की है। देरी। यदि आप परिवर्तनों को समय-समय पर संसाधित करते हैं, तो आप इसे संभवतः 5 मिनट तक कम कर सकते हैं।
आपको किसी बिंदु पर धारणाओं में फेंकना होगा, कैशिंग और कुछ हेरिस्टिक्स का उपयोग करना होगा। कुछ उदाहरण:
- एक ट्वीट जितना ताज़ा होगा, उसे उतना ही अधिक ट्रैफ़िक दिखाई देगा। इसके रीट्वीट होने की संभावना अधिक होती है, और इसे अधिक बार देखा जाता है। इसे RAM में रखें।
- 1991 का आपका फेसबुक टाइमलाइन अवलोकन पृष्ठ शायद दैनिक आधार पर नहीं बदलने वाला है, इसलिए यह दीर्घकालिक आउटपुट कैशिंग के लिए एक उम्मीदवार है।
- वर्तमान फ़ेसबुक गतिविधि में बहुत कुछ लिखे जाने की संभावना है। आउटपुट कैशिंग यहां ज्यादा मदद नहीं करेगा। फिर से, वस्तु को RAM में रखना चाहिए।
