Quelle est la bonne façon de compter les commentaires d'articles, les hits et les likes dans un index d'articles?

Question

J'ai trois tables, une pour les articles, un pour commentaires, un pour goûts, une pour les visites, dans cet exemple schéma

**news** 
    news_id 

**comments** 
    comment_id 
    news_id 

**likes** 
    like_id 
    news_id 

**hits** 
    hit_id 
    news_id 

Ce que je veux faire est d'écouter tous les articles dans un indice sortable dans une boîte/div pour chaque article avec nombre d'articles de coups, commentaires, et j'aime, je sais comment faire tout cela, donc ce n'est pas la façon dont je cherche, c'est la meilleure façon, je pense à ces deux solutions.

1. le faire de la manière normale, une requête SQL complexe puis le cache de la requête, disons pour une heure ou deux.

2. écrire un script qui est exécuté toutes les deux ou trois heures pour calculer les données et les stocker dans la même table de nouvelles dans les champs numériques "news_hits, news_likes, news_comments".

et bien sûr la troisième manière est de faire la requête chaque fois que la page est chargée sans aucune mise en cache.

Je pense que c'est la méthode numéro un que j'irai après, mais je voulais un avis professionnel ou expérimenté, je ne m'attends pas à un grand nombre de visiteurs, environ 500-1000 par jour maximum, mais je veux être préparé pour le trafic élevé.

merci,

Rami

Answer 1

Il serait préférable d'admettre la redondance dans ce cas, pour améliorer la vitesse. À la table de nouvelles, ajoutez ces champs:

comments_count int not null default 0, 
likes_count int not null default 0, 
hits_count int not null default 0 

Lorsqu'un commentaire/comme/hit est ajouté/supprimé, si la base de données prend en charge les déclencheurs, déclenche un incrément/décrément du compteur référencé, sinon - le faire manuellement à chaque insertion/suppression (procédure stockée peut-être?).

Ce type de données est plus souvent lu que écrit, donc pour optimiser la vitesse de lecture, ralentir la vitesse d'écriture et l'espace de stockage n'est pas un gros problème.

De temps en temps, il serait bon d'exécuter une requête qui mettrait à jour ces compteurs si, pour une raison quelconque, ils devenaient erronés.

Answer 2

briser le SQL complexe en plusieurs requêtes plus petites (moins complexes) et le cache du résultat individuel (s), donc à chaque fois que vous voulez préparer le cache warm-up, il ne prendra pas trop de ressources de base de données

Answer 3

Avec un tel modèle simple, une requête et un faible nombre de visiteurs, je voudrais aller à la requête droite. Il s'exécutera très bien (en millisecondes) avec une indexation appropriée.

Si je comprends bien le scénario, la requête devrait trier les articles de presse par leur popularité, qui est déterminée d'une manière ou d'une autre par le nombre de likes/hits/comments.

Si vous souhaitez régler un problème de performances que vous ne pouvez pas rencontrer, la solution la plus simple consisterait à utiliser un cache de requête qui expire toutes les 10 secondes. Avec votre charge actuelle, chaque visiteur rendra toujours la vue depuis la base de données, car le cache expire entre les visites de pages. Si, un jour, vous devenez soudainement envahi avec 200 000 visiteurs par exemple, vous n'effectuerez la requête qu'une fois toutes les 10 secondes.