si vous réimplémenté twitter, que feriez-vous différemment?

Question

Je viens de voir le hilarant "The Rise and Fall of Twitter" qui m'a fait penser:

si vous réimplémenté twitter, que feriez-vous différemment?

Quelles technologies utiliseriez-vous? Quelles langues?

Comment vous assurer que le service est évolutif?

Quoi d'autre changeriez-vous?

Answer 1

je l'aurais mis en œuvre sur GAE, comme ceci:

Chaque utilisateur aura une table contenant les tweets des personnes qu'ils suivent. 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'identifiants de suiveurs contigus. Pour la plupart des utilisateurs, qui n'ont que quelques milliers de followers, cette table aura une seule entrée (-inf .. + inf); Ce sera le défaut implicite. Pour les utilisateurs ayant plus d'abonnés, chaque plage de la table aura quelques milliers d'utilisateurs. Les plages seront équilibrées dans le temps pour conserver le nombre d'utilisateurs dans chaque intervalle de temps, par ex. supérieur à 1000, inférieur à 10000. L'union de toutes les plages comprendra tous les ID utilisateur.

Chaque fois qu'une opération utilisateur -> 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, subrange suiveur). Les opérateurs de file d'attente prennent un objet, trouvent tous les suiveurs dans la sous-plage donnée et appliquent l'action à chacun d'eux. (Notez que l'action peut être «ajouter un tweet», «supprimer un tweet», «modifier un tweet», etc. Tout ce qui doit être appliqué à tous les abonnés.

L'application de l'action de file d'attente à chaque suiveur impliquera l'émission des écritures et des suppressions correspondantes dans la table de tweets de chaque utilisateur. La barrière de la file d'attente signifiera que les écritures n'apparaîtront pas instantanément, mais il devrait être possible de garder le retard en dessous de quelques secondes. Montrer à l'utilisateur que ses tweets seront une opération bon marché: "SELECT * FROM tweets WHERE id_utilisateur =: id_utilisateur ORDER BY (created_at DESC) LIMIT: max_per_page". Cela va scanner une seule table, et être une opération très rapide. (Garder la latence bloquant l'utilisateur vers le bas est bon!)

Je pense que cette conception serait plutôt bonne échelle initialement. Chaque composant du système peut désormais être étendu facilement:

• Le stockage de file d'attente peut être soutenue par GAE, et mis à l'échelle selon une table Datastore
• Les frontends peuvent être mis à l'échelle naturelle, et il n'y a pas besoin de stickyness
• Plus de processeurs de file d'attente peuvent être ajoutés à tout moment
• Les tables de stockage réelles vont se développer naturellement et devraient évoluer correctement sur Datastore.

Cela dit, je peux penser à une amélioration future de couple que j'examineraient immédiatement:

• Réduire le stockage des données rarement montrées. Cette conception dénormalise chaque tweet en une copie par suiveur. Cependant, seuls les tweets les plus récents sont généralement accessibles. En supprimant la copie par utilisateur des tweets après l'âge de N jours, nous pouvons récupérer beaucoup de stockage. Si un utilisateur essaie d'afficher quelque chose de l'histoire ancienne, nous récupérons les données des tables dénormalisées. Ce sera plus lent, mais cela n'arrivera pas trop souvent, et les économies seront importantes. Économies de stockage: (#avg_followers - 1)/#avg_followers
• Le motif d'écriture n'est pas optimal. Sur plusieurs éléments de la file d'attente, chaque agent de file d'attente écrira sur la table des tweets de chaque utilisateur, ainsi la localité des écritures ne sera pas très bonne. (Dans le pire des cas, nous aurons #processor * #storage server connections.) Cela peut être résolu en appliquant plusieurs mises à jour à chaque gamme d'utilisateurs. Par exemple, si deux actions A et B doivent être appliquées à l'intervalle [0, 10000), alors un processeur de file d'attente unique appliquera ces deux actions en même temps.

Answer 2

C'est déjà fait: Laconica

Answer 3

Je concevoir évolutive comme l'enfer juste dès le début.

Mon choix serait la plate-forme Microsoft, C#, IIS, SQL Server, Memcached (ou Velocity si elle est définitive et fonctionne bien quand je commence ;-)

Answer 4

1. Il est déjà fait Partie II - revanche: identi.ca (qui est sur le dessus de Laconie)
2. Il est déjà fait partie III - a partir du côté obscur: yammer

VBG! (-:

Answer 5

Je vais commencer à partir de la prémisse de retourner à le faire à nouveau: ce

que je ferais différemment, si je sur Twitter à l'époque pas une chose

?. Twitter a mis l'accent sur ce qui compte: fournir un service que les gens veulent vraiment 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 vient les ressources et l'attention ion pour capitaliser sur le succès.