Les actions de l'utilisateur comme les réseaux sociaux facebook, myspace, tous les grands

Question

Je travaille sur un site de type réseau social en PHP, je l'ai fait une fois avant et le site a surpassé ma capacité de codage de suivre, il y a quelques années et maintenant je veux revenir sur ce projet.

Basicly sur mon réseau il y a une table mysql friend_friend qui garde la trace de qui est qui est un ami, pour chaque ami confirmé, il y a 2 entrées dans la base de données ici est que le tableau:

CREATE TABLE IF NOT EXISTS `friend_friend` (
    `autoid` int(11) NOT NULL AUTO_INCREMENT, 
    `userid` int(10) DEFAULT NULL, 
    `friendid` int(10) DEFAULT NULL, 
    `status` enum('1','0','3') NOT NULL DEFAULT '0', 
    `submit_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
    `alert_message` enum('yes','no') NOT NULL DEFAULT 'yes', 
    PRIMARY KEY (`autoid`), 
    KEY `userid` (`userid`), 
    KEY `friendid` (`friendid`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1657259 ; 

Je puis avoir une table d'utilisateur avec toutes les informations d'utilisateur appelé friend_reg_user

Ensuite, un tableau pour les bulletins que les utilisateurs publient, l'objet est de ne montrer que les bulletins des utilisateurs avec lesquels vous êtes amis. Voici les bulletins tableau

CREATE TABLE IF NOT EXISTS `friend_bulletin` (

    `auto_id` int(11) NOT NULL AUTO_INCREMENT, 
    `user_id` int(10) NOT NULL DEFAULT '0', 
    `bulletin` text NOT NULL, 
    `subject` varchar(255) NOT NULL DEFAULT '', 
    `color` varchar(6) NOT NULL DEFAULT '000000', 
    `submit_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
    `status` enum('Active','In Active') NOT NULL DEFAULT 'Active', 
    `spam` enum('0','1') NOT NULL DEFAULT '1', 
    PRIMARY KEY (`auto_id`), 
    KEY `user_id` (`user_id`), 
    KEY `submit_date` (`submit_date`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=455144 ; 

Ok, donc de le faire je soit exécuter une requête sur la table friend_friend pour obtenir tous les amis d'un utilisateur et les ajouter à une chaîne comme celui-ci 1,2,3,4, 5,6 ceux-ci seraient des numéros d'identification d'ami et ensuite sélectionner dans la table de bulletin où ID d'auteur de bulletin est dans ma liste d'identification d'ami

La deuxième méthode consiste à utiliser JOINS pour obtenir toutes ces données à la fois.

Ma quête maintenant enfin, une fois que le site devient très grand, quand il y a des millions d'amis et d'enregistrements dans la BD tout cela ralentit, quelles sont mes options pour accélérer les choses? Y a-t-il une meilleure manière de faire cela? Aussi, je prévois de changer les bulletins pour inclure plus que des bulletins, mais faire plus d'actions des utilisateurs comme les grands sites maintenant afin qu'il affiche les mises à jour de statut et les blogs et tous les

Answer 1

Ce que vous cherchez à faire peut probablement être fait de plusieurs façons. Vous pouvez avoir une table de résumé qui combine toutes les données associées (amis dans cette instance) pour un membre donné.

C'est une approche plutôt simple mais qui peut devenir beaucoup plus sophistiquée.

Les cumuls de résumé agissent comme un mécanisme de mise en cache persistante. Vous devrez garder cette mise à jour par une méthode - un travail cron, MapReduce, etc Vous ne voulez pas calculer toutes ces données chaque fois que vous en avez besoin - au lieu, le calculer à intervalles réguliers afin qu'il soit prêt rapidement. Memcache est un excellent outil pour la mise en cache, mais qui met en cache des données qui doivent être calculées à un moment donné de toute façon. Malheureusement, Memcache n'est pas persistant. Cela signifie que si le serveur ou le service memcached meurt, vos données le sont également.

Vous pouvez explorer certaines technologies de pointe avancées telles que MongoDB, CouchDB, Project Voldemort et neo4j pour des outils encore plus efficaces.

Id recommande également regarder le code source pour le réseau social open source PHP Elgg à http://www.elgg.org/

Answer 2

Facebook utilise memcached pour stocker les bases de données SQL comme distribuées tables de hachage. C'est probablement votre meilleur pari.