"अपठित टिप्पणियों" काउंटरों की एक कुशल प्रणाली को कार्यान्वित करना

Question

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

प्रत्येक समाधान जो सिर पर आता है, में कुछ गंभीर नुकसान होते हैं, या तो क्वेरीिंग, या भंडारण या अद्यतन भाग में। अर्थात। इसे बहुत अधिक भंडारण, या बहुत अधिक अपडेट, या बहुत महंगा प्रश्नों की आवश्यकता है।

आपकी समाप्ति के बारे में क्या? हो सकता है कि इस तरह की समस्याओं के लिए पहले से ही एक अच्छा गठित समाधान हो?

Answer 1

मैं स्कीमा को यथासंभव सरल रखूंगा, इसलिए पूछताछ जितनी सरल हो सकेगी। यह आमतौर पर सबसे कम भंडारण आवश्यकताओं भी है। बेशक, इस क्वेरी का समर्थन करने के लिए सूचकांक सेट करें।

अगला चरण: प्रदर्शन को मापें! "मापने के लिए पता है।" प्रतिक्रिया समय क्या है? सर्वर पर लोड क्या है? जब तक प्रदर्शन स्वीकार्य है, स्कीमा और क्वेरी को सरल रखें। यदि यह बिल्कुल जरूरी नहीं है तो रखरखाव बलिदान न करें: आपके उत्तराधिकारी बाद में इसके लिए धन्यवाद देंगे।

यदि प्रदर्शन वास्तव में एक समस्या है, तो आप अपने आवेदन के लिए उपयोग कर रहे ढांचे की कैशिंग कार्यक्षमता देखें। एक क्वेरी निष्पादित नहीं करना एक अनुकूलित प्रदर्शन करने से हमेशा तेज है।

Answer 2

यदि आप वास्तव में अपने संसाधन लिफाफे में सफल नहीं होते हैं, तो शायद आपको उपयोगकर्ता अनुभव को ट्विक करना होगा। शायद धागे की अंतिम पहुंच की तारीख को संग्रहित करना पर्याप्त है।

Answer 3

मुझे विश्वास नहीं है कि सामान्य, सामान्यीकृत दृष्टिकोण आपको अक्षम प्रश्नों के साथ छोड़ देगा। मान लें कि आपके पास पीके (article_id, comment_id) और पीके (user_id, article_id, comment_id) के साथ एक और तालिका comments_seen_by_user के साथ एक तालिका article_comments है। तुम सब करने की ज़रूरत है पृष्ठ पर सूचीबद्ध प्रत्येक लेख के लिए, यह है:

SELECT count(*) FROM article_comments ac 
WHERE article_id = ?    -- Parameter 
AND NOT EXISTS (
    SELECT 1 FROM comments_seen_by_user csbu 
    WHERE csbu.user_id = ?   -- Parameter 
    AND csbu.article_id = ac.article_id 
    AND csbu.comment_id = ac.comment_id 
) 

आप एक पृष्ठ पर 20 लेख है, तो आप इसके बाद के संस्करण क्वेरी 20 बार चलाने देंगे, और प्रत्येक रन खींचने के लिए एक सूचकांक का उपयोग करेगा article_comments से 10-20 पंक्तियां कहें, और सबक्वायरी परीक्षण comments_seen_by_user पर एक और इंडेक्स स्कैन है, इसलिए सभी में आपके पास दिए गए पृष्ठ को दिखाने के लिए 20 * (20 * 2) = 800 अनुक्रमित लुकअप हो सकते हैं। यह आधुनिक डीबी के लिए कोई पसीना नहीं है। और मैं शायद बेहतर क्वेरी योजनाओं को देख रहा हूं जो PostgreSQL पा सकते हैं।

क्या आपने यह कोशिश की है, और प्रदर्शन चाहते हैं? यदि ऐसा है, तो मेरा पहला अनुमान यह होगा कि आपके पास थोड़ी देर में VACUUM एड नहीं है। अन्यथा, मुझे प्रति पृष्ठ लेखों की संख्या, या प्रति लेख टिप्पणी, गलत के लिए मेरा अनुमान होना चाहिए - कृपया उस मामले में और विवरण के साथ अपडेट करें।

Answer 4

मैं दूसरा j_random_hacker का जवाब दूंगा, केवल मैं टिप्पणियों_आईडी_बी_यूज़र तालिका में article_id को संग्रहीत करने से बचूंगा क्योंकि टिप्पणी_आईडी प्रत्येक टिप्पणी के लिए वैश्विक रूप से अद्वितीय होनी चाहिए। PostgreSQL में भी 3-आयामी (और 2 डिग्री से कम डिग्री) सूचकांक अभी भी धीमे हैं, इसलिए उनसे बचने का प्रयास करें।

उपयोगकर्ता_आईडी की एक तालिका के आसपास कोई वास्तव में अच्छा तरीका नहीं है, टिप्पणी टिप्पणियों के बारे में जानकारी संग्रहीत करने के लिए टिप्पणी_आईडी मान, बस सुनिश्चित करें कि इसमें एक अद्वितीय अनुक्रमणिका है। ऐसी तालिका में कुछ 10 मिलियन पंक्तियां PostgreSQL के लिए बिल्कुल कोई समस्या नहीं है, जब तक यह सूचकांक को स्मृति में रख सके।आप सिस्टम तालिकाओं के लिए सूचकांक आकार (डिस्क पर 8KB पृष्ठों की संख्या) प्रश्नों के साथ का ट्रैक रख सकते:

select relname,relpages from pg_class where relname='comments_seen_by_user_pkey'; 

Answer 5

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

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