تنفيذ نظام فعال ل"تعليقات غير مقروء" العدادات

Question

وأنا أحاول أن أجد الحل الأمثل لهذه المشكلة التالية: هناك حاجة لتصميم قاعدة بيانات (على بوستجرس)، ونظام المشغلات والعدادات في ذلك، والتي سوف تشكل نظام الاستعلام عن كفاءة وتحديث و تخزين المعلومات على 'كم تعليقات غير مقروء موجودة في كل مادة من المواد (أو المقال، أو شىء. ما شابه)، التي يتم عرضها على هذه الصفحة ".

وكل الحل الذي يأتي في الرأس، لديها بعض العيوب الخطيرة، سواء في الاستعلام، أو تخزين، أو الجزء التحديث. بمعنى آخر. يحتاج الكثير من التخزين، أو تحديثات كثيرا، أو استفسارات costy جدا.

وماذا عن اكسبيرينسي لديك؟ ربما يكون هناك حل لطيفة شكلت بالفعل لهذا النوع من المشاكل؟

Answer 1

وأود أن الحفاظ على مخطط بسيطة بقدر الإمكان، لذلك الاستعلام سيكون بسيطا قدر الإمكان. وعادة ما يكون هذا أيضا أدنى متطلبات التخزين. وبطبيعة الحال، وضع مؤشرات لدعم هذا الاستعلام.

والخطوة التالية: قياس الأداء! "لقياس ما يمكن معرفته." ما هو زمن الاستجابة؟ ما هو الحمل على الخادم؟ طالما أن الأداء مقبولا، والحفاظ على المخطط والاستعلام بسيطة. لا نضحي الصيانة إذا كان ليس من الضروري تماما: سوف خلفاء الخاص نشكركم على ذلك لاحقا

إذا الأداء هو حقا مشكلة، والنظر في وظيفة التخزين المؤقت للإطار الذي تستخدمه للتطبيق الخاص بك. NOT تنفيذ استعلام دائما أسرع من إجراء عملية واحدة الأمثل.

Answer 2

إذا كنت حقا لا تنجح داخل المغلف الموارد الخاصة بك، ربما لديك لقرص تجربة المستخدم. ربما تخزين تاريخ الوصول الماضي إلى موضوع غير كافية.

Answer 3

وأنا لا أعتقد أن نهج تطبيع نموذجي من شأنه أن أترككم مع الأسئلة غير فعالة. افترض أن لديك article_comments الجدول مع (article_id, comment_id) PK وcomments_seen_by_user جدول آخر مع (user_id, article_id, comment_id) PK. كل ما عليك القيام به هو، على كل مادة من المواد المدرجة في الصفحة:

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 مرة، وسيكون لكل شوط استخدام مؤشر لسحب يقول 10-20 الصفوف من article_comments، واختبار فرعي هو مجرد مؤشر آخر على مسح comments_seen_by_user، حتى إجمالا قد يكون لديك 20 * (20 * 2) = 800 عمليات البحث فهرستها لأداء لإظهار صفحة معينة. وهذا ليس العرق إلى DB الحديث. وأنا ربما تطل على خطط أفضل استعلام كيو قد تجد.

ولقد حاولت ذلك، وجدت الأداء يريد؟ إذا كان الأمر كذلك، فإن أول تخميني ان يكون لديك لا VACUUMed في كل حين. خلاف ذلك، لا بد لي قد حصلت على تقديراتي لعدد من المواد في الصفحة، أو تعليق في المادة، خطأ - يرجى تحديث مع مزيد من التفاصيل في هذه الحالة

Answer 4

وأنا سأجيب j_random_hacker الثانية، وفقط أود أن تجنب تخزين ARTICLE_ID في الجدول comments_seen_by_user منذ comment_id يجب أن تكون فريدة من نوعها على مستوى العالم لكل تعليق. أيضا 3-الأبعاد (و2-د بدرجة أقل) المؤشرات لا تزال بطيئة في الإنترنت، وذلك في محاولة لتجنب لهم.

ولا توجد طريقة جيدة حول جدول USER_ID والقيم comment_id لتخزين المعلومات عن تصريحات قراءة، فقط للتأكد من أنه يحتوي على فهرس فريد. وهناك عدد قليل 10000000 الصفوف في هذا الجدول لا توجد مشكلة على الإطلاق لشبكة الإنترنت، طالما أنه يمكن الحفاظ على مؤشر في الذاكرة. يمكنك تتبع حجم مؤشر (عدد الصفحات 8KB على القرص) مع الاستعلامات إلى جداول النظام:

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

Answer 5

وأود أن نتفق على أن يذهب لنهج تطبيع ومعرفة ما اذا كان يعمل بها. عادة أنا ينبغي. ومع ذلك، هل يمكن أيضا استخدام بعض INSERT الزناد على الطاولة 'تعليق'، الذي يعد استكمالا عداد تعليق في (المادة أي) الجدول الأساسي. ان ذلك يعتمد على الشخصية الاستخدام لهذا الموقع: إذا تم تعليق قراءة في الغالب (مقارنة مع إضافة تعليقات) النفقات العامة للنهج القائم على الزناد يجب استهلاك بسرعة. اذا كان خلاف ذلك الموقع الذي يحتوي على الحمل تعليق عالية وهذا يمكن أن تقتل الأداء.

واود ان اذهب لبسيط، بنية الجدول تطبيع وإضافة التحسين الأخرى في وقت لاحق، عندما يكون لديك بعض الشخصية استخدام معقول.