एक अधिसूचना प्रणाली का निर्माण [बंद]

170

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

तो ... कुछ आवश्यकताएँ जो हमारे पास हैं:

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

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

इस दृष्टिकोण से मैं चिंतित हूं:

नरक के रूप में जटिल :)
यहाँ डेटाबेस सबसे अच्छा भंडारण है (हम MySQL का उपयोग कर रहे हैं) या मुझे कुछ और उपयोग करना चाहिए (रेडिस एक अच्छा फिट भी लगता है)
मुझे एक सूचना के रूप में क्या संग्रह करना चाहिए? उपयोगकर्ता आईडी, उपयोगकर्ता आईडी जिसने घटना शुरू की, प्रकार की घटना (ताकि मैं उन्हें समूह बना सकूं और उपयुक्त पाठ प्रदर्शित कर सकूं) लेकिन तब मुझे पता नहीं है कि अधिसूचना का वास्तविक डेटा कैसे संग्रहीत किया जाए (उदाहरण के लिए URL और छवि का शीर्षक जो कि पसंद किया गया था)। क्या मुझे सूचना जनरेट करते समय बस उस जानकारी को "सेंकना" चाहिए, या क्या मुझे प्रभावित होने वाले रिकॉर्ड (छवि, प्रोफ़ाइल, ...) की आईडी को स्टोर करना चाहिए और अधिसूचना प्रदर्शित करते समय डीबी से बाहर की जानकारी खींचनी चाहिए।
यहां पर प्रदर्शन ठीक होना चाहिए, भले ही मुझे सूचना पृष्ठ प्रदर्शित करते समय 100 सूचनाओं को उड़ने की प्रक्रिया करनी पड़े
हर अनुरोध पर संभावित प्रदर्शन समस्या क्योंकि मुझे उपयोगकर्ता को अपठित सूचनाओं की संख्या प्रदर्शित करनी होगी (जो कि मैं अपने आप में एक समस्या हो सकती है क्योंकि मैं एक साथ सूचनाओं का समूह बनाऊंगा)। इसे टाला जा सकता है, हालांकि अगर मैंने पृष्ठभूमि में सूचनाओं (जहां उन्हें समूहित किया गया है) का दृश्य उत्पन्न किया है और ऑन-द-फ्लाई नहीं है

तो आप मेरे प्रस्तावित समाधान और मेरी चिंताओं के बारे में क्या सोचते हैं? कृपया टिप्पणी करें यदि आपको लगता है कि मुझे कुछ और उल्लेख करना चाहिए जो यहां प्रासंगिक होगा।

ओह, हम अपने पेज के लिए PHP का उपयोग कर रहे हैं, लेकिन मुझे लगता है कि यहाँ एक बड़ा कारक नहीं होना चाहिए।

notifications

— जान हनिक
स्रोत

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

— शहरयार

@ शिवहर मुझे लगता है कि यह अधिसूचना प्रणाली की जटिलता पर निर्भर करता है।

— tyan

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

— अंकित मारोठी

168

एक अधिसूचना किसी चीज़ (वस्तु = घटना, दोस्ती ..) के बारे में है (क्रिया = जोड़ा, अनुरोध किया गया है) किसी व्यक्ति (अभिनेता) द्वारा और उपयोगकर्ता (विषय) को रिपोर्ट किया गया। यहाँ एक सामान्यीकृत डेटा संरचना है (हालाँकि मैंने MongoDB का उपयोग किया है)। आपको परिवर्तनों के बारे में कुछ उपयोगकर्ताओं को सूचित करने की आवश्यकता है। तो यह प्रति-उपयोगकर्ता सूचनाएँ हैं .. जिसका अर्थ है कि यदि 100 उपयोगकर्ता शामिल थे, तो आप 100 सूचनाएं उत्पन्न करते हैं।

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║—1:n—→║ID                 ║—1:n—→║ID                  ║
║userID       ║      ║notificationID     ║      ║notificationObjectID║
╚═════════════╝      ║object             ║      ║verb                ║
                     ╚═══════════════════╝      ║actor               ║
                                                ╚════════════════════╝

(जहाँ आप फिट दिखते हैं समय क्षेत्र जोड़ें)

यह मूल रूप से प्रति वस्तु में परिवर्तन को समूहीकृत करने के लिए है, ताकि आप कह सकें कि "आपके पास 3 मित्र अनुरोध हैं"। और प्रति अभिनेता समूहन उपयोगी है, ताकि आप कह सकें कि "उपयोगकर्ता जेम्स बॉन्ड ने आपके बिस्तर में बदलाव किए हैं"। यह आपकी पसंद के अनुसार सूचनाओं का अनुवाद और गणना करने की क्षमता भी देता है।

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

चूंकि साइट पर उपयोगकर्ताओं के लिए सूचनाएं वास्तविक समय के करीब हैं, इसलिए मैं सभी श्रोताओं के लिए नोडज को अपडेट करने के साथ नोडज + वेबसोकेट क्लाइंट के साथ टाई करूंगा, क्योंकि परिवर्तन जोड़ा जाता है।

— आर्टजोम कुरपोव
स्रोत

1

notification_object.object एक स्ट्रिंग "मैत्री" की तरह परिवर्तन प्रकार की पहचान करता है, इसके अतिरिक्त डेटा के साथ परिवर्तित वस्तु का वास्तविक संदर्भ, जिसके बारे में मैं बात करता हूं

— सूचना_change.notificationObjectID

2

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

— जेफरी मिल्स

4

मुझे पता है कि यह विषय पहले से ही काफी पुराना है, हालांकि मैं पहली तालिका के बारे में हैरान हूँ, इस तालिका का उद्देश्य क्या है? यह एक अलग तालिका के रूप में होने का क्या फायदा है? दूसरे शब्दों में, आप अधिसूचना में एक नई प्रविष्टि कब बनाएंगे और इस संरचना के साथ एक मौजूदा अधिसूचना में आप बस एक वस्तु और परिवर्तन कैसे करेंगे?

— बास गूसेन

3

@JefferyMills आप तालिका is_notification_readमें एक स्थिति फ़ील्ड की तरह हो सकते हैं notificationऔर इसे उचित रूप से चिह्नित कर सकते हैं यदि यह है unread, readया deleted।

— केविन

2

मैंने इस समाधान के कुछ पहलुओं को समझने के लिए संघर्ष किया है, और इसके बारे में एक अलग सवाल किया है: dba.stackexchange.com/questions/99401/…

— user45623

27

यह वास्तव में एक अमूर्त प्रश्न है, इसलिए मुझे लगता है कि हमें केवल इस बात पर चर्चा करने की आवश्यकता है कि आपको क्या करना चाहिए या क्या नहीं करना चाहिए।

यहां मैं आपकी चिंताओं के बारे में सोचता हूं:

हां, एक अधिसूचना प्रणाली जटिल है, लेकिन नरक के रूप में नहीं। मॉडलिंग और ऐसी प्रणालियों को लागू करने के लिए आपके पास कई अलग-अलग दृष्टिकोण हो सकते हैं, और वे एक माध्यम से उच्च स्तर की जटिलता तक हो सकते हैं;
व्यक्तिगत रूप से, मैं हमेशा सामान डेटाबेस-चालित बनाने की कोशिश करता हूं। क्यों? क्योंकि मैं इस बात की गारंटी दे सकता हूं कि जो कुछ चल रहा है उसका पूरा नियंत्रण हो सकता है - लेकिन यह सिर्फ मेरे लिए है, आप डेटाबेस-संचालित दृष्टिकोण के बिना नियंत्रण कर सकते हैं; मेरा विश्वास करो, तुम उस मामले पर नियंत्रण चाहते हो;
मुझे आपके लिए एक वास्तविक मामले की मिसाल दीजिए, ताकि आप कहीं से भी शुरुआत कर सकें। पिछले एक वर्ष में मैंने किसी तरह के सोशल नेटवर्क (फेसबुक की तरह नहीं, निश्चित रूप से) में एक अधिसूचना प्रणाली को लागू किया है और लागू किया है। जिस तरह से मैंने वहां नोटिफिकेशन स्टोर किया था? मैं एक था notificationsमेज, जहां मैं रखा generator_user_id(उपयोगकर्ता कि अधिसूचना पैदा कर रहा है की आईडी), target_user_id, (स्पष्ट की तरह, है ना?) notification_type_id(कि अधिसूचना प्रकार के साथ एक अलग तालिका को संदर्भित), और सब उस आवश्यक सामान को हमें अपनी तालिकाओं (टाइमस्टैम्प, झंडे आदि) के साथ भरने की आवश्यकता है। मेरी notification_typesतालिका में संबंध हुआ करता थाnotification_templates तालिका के रखती थी, जो प्रत्येक प्रकार की अधिसूचना के लिए विशिष्ट टेम्पलेट संग्रहीत करती थी। उदाहरण के लिए, मेरे पास एक POST_REPLYप्रकार था, जिसमें एक टेम्पलेट की तरह{USER} HAS REPLIED ONE OF YOUR #POSTS । वहाँ से, मैंने अभी इलाज किया{}एक चर के #रूप में और एक संदर्भ लिंक के रूप में;
हाँ, प्रदर्शन करना चाहिए और चाहिए ठीक हो। जब आप सूचनाओं के बारे में सोचते हैं तो आप सर्वर को सिर से पैर तक धकेलने के बारे में सोचते हैं। या तो यदि आप इसे अजाक्स अनुरोध के साथ या जो भी करने जा रहे हैं, आपको प्रदर्शन के बारे में चिंता करने की आवश्यकता है। लेकिन मुझे लगता है कि यह दूसरी बार की चिंता है;

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

— डैनियल रिबेरो
स्रोत

मेरे पास कुछ अन्य डेटा स्टोर के साथ नियंत्रण क्यों नहीं होगा?

— Jan Hančič

खैर, मैंने ऐसा नहीं कहा। मैंने जो कहा वह यह है कि मैं केवल डेटाबेस-संचालित दृष्टिकोण के साथ डेटा नियंत्रण की गारंटी दे सकता हूं; लेकिन यह सिर्फ मुझे है। मुझे लगता है कि rephrase हूँ।

— डैनियल रिबेरो

अधिसूचना टेम्पलेट में प्लेसहोल्डर ({...}) @DanielRibeiro को डेटाबेस के विभिन्न प्रकारों के लिए अलग-अलग प्रकार के नोटिफिकेशन के लिए प्लेसहोल्डर्स के डेटा को बदलने की आवश्यकता है। उदाहरण के लिए एक टेम्पलेट "{उपयोगकर्ता} को आपकी तस्वीर पसंद आई है।", एक अन्य टेम्पलेट है "आपका {Pagename} नया जैसा है।" आदि {PageName} और {user} और अन्य प्लेसहोल्डर अलग-अलग डेटाबेस टेबल से मैप करेंगे, इसलिए प्लेसहोल्डर्स को गतिशील रूप से प्राप्त करने के लिए स्कीमा क्या होना चाहिए।

— आशीष शुक्ला

डैनियलरिबेरो ने @Aishish Shukla,

— शांताराम

@ आशीष शुक्ला ने आपने प्लेसहोल्डर्स का इस्तेमाल किया है या उनकी जगह ली है, और कैसे?

— शांताराम तुपे

8

╔════════════════════╗
║notification        ║
╟────────────────────╢
║Username            ║
║Object              ║
║verb                ║
║actor               ║
║isRead              ║
╚════════════════════╝

यह 2 संग्रह होने के बजाय एक अच्छा जवाब है। आप नई घटनाओं को प्राप्त करने के लिए उपयोगकर्ता नाम, ऑब्जेक्ट और क्वेरी से क्वेरी कर सकते हैं (जैसे 3 लंबित मित्र अनुरोध, 4 प्रश्न आदि पूछे गए ...)

मुझे पता है कि इस स्कीमा के साथ कोई समस्या है।

— Kaphy
स्रोत

3

शीर्ष उत्तर ने एक सामान्यीकृत डेटा संरचना का उपयोग किया, जिसका अर्थ है कि तालिकाओं में कोई अतिरेक नहीं। क्या आपका जवाब ऐसा है?

— हारून हॉल

4

मैं व्यक्तिगत रूप से स्वीकृत उत्तर के लिए आरेख को बहुत अच्छी तरह से नहीं समझता हूं, इसलिए मैं एक डेटाबेस आरेख आधार को संलग्न करने जा रहा हूं जो मैं स्वीकृत उत्तर और अन्य पृष्ठों से सीख सकता हूं।

सुधार अच्छी तरह से प्राप्त कर रहे हैं।

— जेसन ग्लीज
स्रोत

Message_template की तरह लगता है NotificationType तालिका में होगा। यह भी लगता है कि जैसा कि main_url नोटिफिकेशन टेबल में होगा, तो आप Notification_Message टेबल को समाप्त कर सकते हैं। क्या आप इसकी वजह बता सकते हैं कि आपके पास NotificationMessage टेबल है?

— जेफ रयान