मैं निम्नलिखित संरचना के साथ जाऊंगा:
-
सभी कार्रवाइयों के लिए एक संग्रह का उपयोग करें,
Actions -
कौन किसका अनुसरण करता है, इसके लिए दूसरे संग्रह का उपयोग करें,
Subscribers -
तीसरे संग्रह का उपयोग करें,
Newsfeedकिसी निश्चित उपयोगकर्ता के समाचार फ़ीड के लिए, आइटमActions. से फ़ैन-आउट कर दिए जाते हैं संग्रह।
Newsfeed संग्रह एक कार्यकर्ता प्रक्रिया द्वारा पॉप्युलेट किया जाएगा जो एसिंक्रोनस रूप से नए Actions को संसाधित करता है . इसलिए, समाचार फ़ीड रीयल-टाइम में पॉप्युलेट नहीं होंगे। मैं गीर्ट-जन से असहमत हूं कि वास्तविक समय महत्वपूर्ण है; मेरा मानना है कि अधिकांश उपयोगकर्ता अधिकांश . में एक मिनट की भी देरी की परवाह नहीं करते हैं (सभी नहीं) एप्लिकेशन (वास्तविक समय के लिए, मैं पूरी तरह से अलग आर्किटेक्चर चुनूंगा)।
यदि आपके पास बहुत बड़ी संख्या में consumers हैं , फैन-आउट में कुछ समय लग सकता है, सच। दूसरी ओर, उपभोक्ताओं को सीधे ऑब्जेक्ट में डालने से बहुत बड़े फॉलोअर्स की संख्या के साथ भी काम नहीं होगा, और यह अत्यधिक बड़े ऑब्जेक्ट बनाएगा जो बहुत अधिक इंडेक्स स्पेस लेते हैं।
हालांकि, सबसे महत्वपूर्ण बात यह है कि फैन-आउट डिज़ाइन अधिक अधिक लचीला है और प्रासंगिकता स्कोरिंग, फ़िल्टरिंग आदि की अनुमति देता है। मैंने हाल ही में MongoDB के साथ समाचार फ़ीड स्कीमा डिज़ाइन के बारे में एक ब्लॉग पोस्ट लिखा है जहाँ मैं उस लचीलेपन में से कुछ को अधिक विस्तार से समझाता हूँ।
लचीलेपन की बात करें तो, मैं उस activitystrea.ms कल्पना के बारे में सावधान रहूँगा। यह विभिन्न प्रदाताओं के बीच इंटरऑप के लिए एक विनिर्देश के रूप में समझ में आता है, लेकिन जब तक आप विभिन्न अनुप्रयोगों से गतिविधियों को एकत्रित करने का इरादा नहीं रखते हैं, तब तक मैं अपने डेटाबेस में वह सभी वर्बोज़ जानकारी संग्रहीत नहीं करूंगा।
