Si vous réimplémentiez Twitter, que feriez-vous différemment?

Question

Je viens de voir la hilarante & The; Rise et chute de Twitter " qui m'ont fait penser:

si vous réimplémentiez Twitter, que feriez-vous différemment?

Quelles technologies utiliseriez-vous? Quelles langues?

Comment vous assurez-vous que le service est évolutif?

Que changeriez-vous d'autre?

Answer 1

Je l'aurais implémenté sur GAE, comme suit:

Chaque utilisateur aura un tableau contenant les tweets des personnes qu’il suit. Cette table sera saisie par (utilisateur, horodatage décroissant).

Chaque utilisateur dispose également d’une table follower_ranges, qui associe un utilisateur à un ensemble de plages d’identificateurs suiveurs contigus. Pour la plupart des utilisateurs n'ayant que quelques milliers d'adeptes, ce tableau aura une seule entrée (-inf .. + inf); ce sera la valeur implicite par défaut. Pour les utilisateurs ayant plus d'adeptes, chaque plage du tableau comptera quelques milliers d'utilisateurs. Les plages seront équilibrées dans le temps pour conserver le nombre d'utilisateurs dans chaque intervalle, par ex. plus grand que 1000, plus petit que 10000. L'union de toutes les plages inclura tous les identifiants d'utilisateur.

Chaque fois qu'un utilisateur - > Une opération suiveur est créée, elle est codée en tant qu’action et ajoutée à une file d’attente. Chaque élément de la file d'attente est un tuple (expéditeur, action, charge utile, sous-groupe suiveur). Les travailleurs de la file d'attente prennent un élément, trouvent tous les abonnés du sous-groupe donné et appliquent l'action à chacun d'entre eux. (Notez que l'action peut être "ajouter un tweet", "supprimer un tweet", "éditer un tweet", etc. En principe, tout ce qui devra être appliqué à tous les abonnés.)

L'application de l'action de file d'attente à chaque suiveur impliquera l'émission des écritures et suppressions correspondantes dans la table tweet de chaque utilisateur. La barrière de la file d'attente empêchera les écritures d'apparaître instantanément, mais il devrait être possible de maintenir le délai en dessous de quelques secondes.

Afficher les tweets de l'utilisateur sera une opération peu coûteuse: "SELECT * FROM tweets WHERE user_id =: user_id ORDER BY (created_at DESC) LIMIT: max_per_page". Cela va scanner une seule table et sera une opération très rapide. (Il est bon de maintenir la latence du blocage des utilisateurs!)

Je pense que cette conception évoluerait plutôt bien au début. Chaque composant du système peut maintenant être mis à l’échelle facilement:

• Le stockage de la file d'attente peut être sauvegardé par GAE et mis à l'échelle selon toute table de magasin de données
• Les interfaces peuvent être mises à l’échelle de façon naturelle, et il n’est pas nécessaire d’adhérer
• Plusieurs processeurs de file d'attente peuvent être ajoutés à tout moment
• Les tables de stockage réelles se développeront naturellement et devraient évoluer correctement dans le magasin de données.

Cela dit, je peux penser à quelques améliorations futures que je voudrais examiner immédiatement:

• Réduisez le stockage de données rarement affichées. Cette conception dénormalise chaque tweet dans une copie par suiveur. Toutefois, seuls les tweets les plus récents sont généralement consultés. En supprimant la copie par utilisateur des tweets après leur âge de N jours, nous pouvons récupérer beaucoup de stockage. Si un utilisateur tente de visualiser quelque chose de l'histoire ancienne, nous récupérons les données des tables dénormalisées. Cela sera plus lent, mais cela n'arrivera pas trop souvent, et les économies seront considérables. Économies de stockage: (#avg_followers - 1) / #avg_followers
• Le modèle d'écriture n'est pas optimal. Sur plusieurs éléments de la file d'attente, chaque utilisateur de la file d'attente écrira dans la table des tweets de chaque utilisateur. Par conséquent, la localité des écritures ne sera pas très bonne. (Dans le pire des cas, nous aurons des connexions au serveur #processor * #storage.) Ce problème peut être résolu en appliquant plusieurs mises à jour à chaque groupe d'utilisateurs. Par exemple, si deux actions A et B doivent être appliquées à la plage [0, 10000), demandez à un seul processeur de file d’attente d’appliquer ces deux actions en même temps.

Answer 2

Cela se fait déjà: Laconica

Answer 3

1. C'est déjà fait. Partie II - La vengeance: identi.ca (au-dessus de Laconica)
2. Cela est déjà fait. Partie III - Du côté obscur: yammer

VBG! (-:

Answer 4

Je vais commencer par la prémisse de revenir pour le refaire: que ferais-je différemment, si j'étais sur Twitter à l'époque?

Pas une chose.

Twitter a continué de se concentrer sur l'essentiel: fournir un service que les gens veulent utiliser.

J'aimerais travailler sur un produit qui est devenu si populaire en si peu de temps que sa plus grande menace est devenue sa propre évolutivité. Cela signifie que vous avez gagné. Avec le succès viennent les ressources et l’attention pour capitaliser sur le succès.

Answer 5

Je le concevrais évolutif comme un diable dès le début.

Mon choix serait la plate-forme Microsoft, C #, IIS, SQL Server, Memcached (ou Velocity s'il est définitif et fonctionne bien au démarrage ;-)