सामाजिक नेटवर्क अधिसूचना प्रणाली


10

पृष्ठभूमि

मैं एक क्लाइंट के लिए एक ऐप पर काम कर रहा हूं जिसमें कुछ सामाजिक नेटवर्किंग सुविधाएँ शामिल हैं। मैं मूल रूप से मोबाइल के फ्रंट-एंड का विकास कर रहा था, लेकिन परिस्थितियों ने मुझे बैक एंड के रूप में विकसित करने के लिए छोड़ दिया है।

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

UI की तरफ, हमारे पास इस पर एक नंबर के साथ एक अधिसूचना बटन होगा, और बटन पर क्लिक करने से आप अधिसूचना स्क्रीन पर पहुंच जाएंगे।

समस्या

मैं सूचनाओं को लागू करने के लिए रणनीतियों पर शोध कर रहा हूं और अधिकांश संसाधनों को मैंने डेटाबेस में एक या अधिक सूचना तालिका बनाने के लिए बिंदु पाया है। (एक उदाहरण जो मुझे पसंद है वह है यहां स्वीकृत उत्तर: /programming/9735578/building-a-notification-system )।

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

मेरा मूल विचार प्रश्नों के साथ सब कुछ संभालने के लिए किया गया था: अधिसूचना बटन पर अंतिम बार जब आप अधिसूचना स्क्रीन पर गए थे, तो पिछली बार की तुलना में अधिक हाल ही में पोस्ट की गई सामग्री पर पंक्ति-गणना का अनुरोध करके अधिसूचना बटन पर संख्या प्राप्त की जाएगी। जब आप अधिसूचना स्क्रीन पर गए। इस दृष्टिकोण के लिए नो राइट्स या अतिरिक्त स्टोरेज की आवश्यकता होगी, लेकिन यह अनम्य है और संभवतः सर्वर को बहुत कठिन रूप से हथौड़ा देगा।

सेट अप

बैकएंड (जैसा कि पिछले डेवलपर द्वारा स्थापित किया गया है) CodeIgniter और एक MySQL डेटाबेस का उपयोग करता है। यह वर्तमान में एक भद्दे GoDaddy साझा होस्टिंग खाते पर चल रहा है, लेकिन मुझे लगता है (आशा?) उत्पादन में जाने से पहले इसे उन्नत किया जाएगा और उपयोगकर्ता के विकास के साथ होस्टिंग पैकेज को बढ़ाया जाएगा।

वर्तमान में हमारा एकमात्र फ्रंट-एंड एक मोबाइल ऐप है, लेकिन हमने बाद में एक वेबसाइट बनाने की योजना बनाई है। मुझे इस समय सूचनाओं के बारे में सर्वर से रियल-टाइम पुश अपडेट प्राप्त करने की चिंता नहीं है।

परिशिष्ट

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

मुझे उम्मीद है कि यह यहाँ पोस्ट होने वाली समस्या के लिए पर्याप्त है; जरूरत पड़ने पर मैं इसे परिष्कृत कर सकता हूं। कृपया पूछें कि क्या आपके कोई प्रश्न हैं या मैंने महत्वपूर्ण विवरणों को छोड़ दिया है।

tl; डॉ

  • क्या डेटाबेस-संचालित अधिसूचना प्रणाली के दीर्घकालिक स्केलेबिलिटी के लिए नकारात्मक प्रभाव हैं, जब सभी उपयोगकर्ता केवल कुछ सौ लोगों में से कुछ का अनुसरण कर रहे हैं?
  • क्या प्रत्येक अनुयायी के लिए प्रत्येक अधिसूचना के लिए एक अलग अधिसूचना पंक्ति की आवश्यकता के बिना सूचनाओं को संचालित करने का एक तरीका है?
  • क्या पूरी तरह से क्वेरी-संचालित अधिसूचना प्रणाली स्केलेबल होगी, या डीबी को कोई डेटा नहीं लिखने के अलावा कोई लाभ है?
  • क्या मैं इसे बहुत जल्दी खत्म कर रहा हूँ? क्या मुझे अभी कुछ काम करना चाहिए और हम इसे अनुकूलित करने की चिंता कर सकते हैं यदि यह समस्या बन जाती है, तो यह देखते हुए कि ग्राहक के पास सीमित बजट है और हमें अभी तक नहीं पता है कि अंतिम उत्पाद लोकप्रिय होगा या नहीं?

क्या आप सूचनाएं समाप्त कर सकते हैं? उदाहरण के लिए, 2 सप्ताह से अधिक पुरानी कुछ भी हटाएं। साइट के आकार के रूप में उपयोग की जाने वाली तालिका के आकार को कम या ज्यादा संतुलित करना चाहिए।
ग्रैंडमास्टरबी

यह एक समस्या नहीं होगी, मैं हर बार किसी लोकप्रिय उपयोगकर्ता द्वारा पोस्ट किए जाने पर सूचना तालिका में 50,000 प्रविष्टियों को लिखने वाले डेटाबेस को लॉक करने के प्रदर्शन निहितार्थ से अधिक चिंतित था।
user45623

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

जवाबों:


10

इसलिए यदि एक हजार लोग सैली का अनुसरण कर रहे हैं, तो हम एक हजार पंक्तियों को संबंधित तालिका में सम्मिलित करते हैं। क्या वह मापनीय है?

हाँ, बशर्ते डेटाबेस टेबल ठीक से अनुक्रमित हो।

यदि हम उस बिंदु पर पहुंच जाते हैं, जहां दसियों या सैकड़ों हजारों उपयोगकर्ता सैली का अनुसरण कर रहे हैं और वह प्रति दिन कुछ दर्जन पोस्ट कर रहा है?

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

मेरा मूल विचार प्रश्नों के साथ सब कुछ संभालने के लिए किया गया था: अधिसूचना बटन पर अंतिम बार जब आप अधिसूचना स्क्रीन पर गए थे, तो पिछली बार की तुलना में अधिक हाल ही में पोस्ट की गई सामग्री पर पंक्ति-गणना का अनुरोध करके अधिसूचना बटन पर संख्या प्राप्त की जाएगी। जब आप अधिसूचना स्क्रीन पर गए।

यह अनावश्यक रूप से जटिल लगता है। यदि आपको सूचनाओं के बारे में विस्तृत आँकड़ों की आवश्यकता है, तो बस सूचनाएँ संग्रहीत करें।

क्या डेटाबेस-संचालित अधिसूचना प्रणाली के दीर्घकालिक स्केलेबिलिटी के लिए नकारात्मक प्रभाव हैं, जब सभी उपयोगकर्ता केवल कुछ सौ लोगों में से कुछ का अनुसरण कर रहे हैं?

यही कारण है कि यह काम करता है ... लोगों की एक छोटी संख्या हमेशा यातायात का विशाल बहुमत उत्पन्न करती है।

क्या प्रत्येक अनुयायी के लिए प्रत्येक अधिसूचना के लिए एक अलग अधिसूचना पंक्ति की आवश्यकता के बिना सूचनाओं को संचालित करने का एक तरीका है?

हां ... सूचनाओं को संग्रहीत न करें; आग और भूल शैली में सिर्फ सूचना ईमेल भेजें। या, एक निश्चित अवधि के लिए सूचनाएं संग्रहीत करें, और फिर उन्हें छोड़ दें। या, प्रत्येक अधिसूचना को पढ़ने के बाद छोड़ दें।

क्या पूरी तरह से क्वेरी-संचालित अधिसूचना प्रणाली स्केलेबल होगी, या डीबी को कोई डेटा नहीं लिखने के अलावा कोई लाभ है?

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

क्या मैं इसे बहुत जल्दी खत्म कर रहा हूँ?

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

एक वास्तविक जीवन का उदाहरण

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


वाह, आपने फ्रिगिन 'सब कुछ संबोधित किया! धन्यवाद, रॉबर्ट! डेटाबेस सामान्यीकृत है, लेकिन मैंने अभी तक अनुक्रमण को नहीं देखा है। दुर्भाग्य से, मैं "किसी ऐसे व्यक्ति से बात नहीं कर सकता जो मेरी मदद कर सकता है", क्योंकि नियम सख्त हैं कि मैं किसी के साथ परियोजना के विशिष्ट विवरणों पर चर्चा नहीं कर सकता, और ग्राहक ने इस बात पर ध्यान दिया है कि वे किसी पर भरोसा नहीं करेंगे। लेकिन मुझे इस परियोजना पर ... ठीक है, मैं अनुक्रमण पर कुछ शोध करने में सक्षम होना चाहिए। धन्यवाद!
user45623

1
अनुक्रमण के लिए अंगूठे के सामान्य नियम: प्रत्येक विदेशी कुंजी को डुप्लिकेट के साथ अनुक्रमित किया जाना चाहिए। प्रत्येक प्राथमिक कुंजी को पहले से ही अनुक्रमित किया जाना चाहिए। फ़ील्ड्स जिन्हें आपको खोज करना या WHERE क्लॉज़ लागू करना चाहिए जिन्हें अनुक्रमित किया जाना चाहिए; उन लोगों को कुछ होना चाहिए।
रॉबर्ट हार्वे

1
यह गलत है। यह स्केलेबल नहीं है। हर "सैली" के लिए आप N पंक्तियाँ बना रहे हैं जहाँ N आपके उपयोगकर्ताओं की संख्या है। यदि आपके पास उपयोगकर्ताओं की कोई उचित संख्या है तो यह तेज़ी से एक मुद्दा बनने जा रहा है। 100 "सैली" पोस्ट करने के लिए 10 बार 10,000 उपयोगकर्ताओं को एक दिन में 10 मिलियन पंक्तियाँ हैं - बहुत अच्छा नहीं लगता है? आप वास्तव में क्या करना चाहते हैं, यह उल्टा है और प्रति "सैली" पोस्ट के लिए एक पंक्ति बनाएं और सैली के बाद के सभी उपयोगकर्ता अपनी निजी कॉपी के बजाय इन्हें हड़प लें। यदि आपको उपयोगकर्ता-विशिष्ट तर्क (जैसे एकत्रीकरण) की आवश्यकता है, तो निश्चित रूप से यह समस्या पैदा करने वाला है ...
बेन

1
... "प्रति पंक्ति एक पंक्ति से बचें" स्पष्टीकरण यहाँ स्पष्ट रूप से एक पुआल आदमी है क्योंकि अधिकांश प्रणालियों को इन पोस्टों के चारों ओर छड़ी करने की आवश्यकता होगी। इसके अलावा, आप "क्योंकि वे जटिल हैं" प्रश्नों से बचते हैं, आप उनसे बचते हैं क्योंकि वे सिस्टम स्केल के रूप में निरंतर ओवरहेड का कारण बनेंगे।
बेन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.