se si reimplementato twitter, che cosa faresti di diverso?

Question

Ho appena visto l'esilarante "L'Ascesa e la Caduta di Twitter", che mi ha fatto pensare:

se si reimplementato twitter, che cosa faresti di diverso?

Quali tecnologie utilizzare?Quali lingue?

Come si fa a garantire che il servizio è scalabile?

Che cosa vuoi cambiare?

Answer 1

Avrei implementato su GAE, in questo modo:

Ogni utente dispone di una tabella contenente i tweet delle persone che segui.Questa tabella sarà la chiave da (utente, data e ora decrescente).

Ogni utente ha inoltre un follower_ranges tabella che associa un utente di una serie contigua di seguace intervalli di id.Per la maggior parte degli utenti, che hanno solo poche migliaia di seguaci in questa tabella sarà una singola voce (-inf..+inf);questo sarà il implicita di default.Per gli utenti con più seguaci, ogni intervallo in tabella avrà un paio di migliaia di utenti.Le gamme di essere equilibrato nel tempo per mantenere il numero di utenti in ogni raggio di qualche intervallo, ad es.maggiore di 1000, di dimensioni inferiori a 10000.L'unione di tutti i campi di includere tutti gli id utente.

Ogni volta che un utente -> seguace operazione è stato creato, è codificato come un'azione e aggiunto a una coda.Ogni elemento della coda è un (mittente, azione, capacità di carico, seguace subrange) tupla.Coda di lavoratori prendete un elemento, trova tutti i seguaci di una data porzione, e applicare l'azione di ciascuno di essi.(Si noti che l'azione può essere "aggiungi un tweet", "elimina un tweet", "modifica di un tweet," etc.In fondo tutto ciò che dovrà essere applicato a tutti i seguaci.)

Applicando la coda di azione per ogni seguace comporterà l'emissione del corrispondente scrive e cancella per ogni utente tweet tabella.La barriera di coda significa che le scritture non vengono visualizzati istantaneamente, ma dovrebbe consentire di mantenere il ritardo di seguito alcuni secondi.

Mostrando all'utente il tweet sarà un funzionamento a basso costo:"SELECT * FROM tweet WHERE user_id = :user_id ORDINE (created_at DESC LIMIT :max_per_page".Questo esegue la scansione di una singola tabella, e di essere un operazione molto veloce.(Tenendo utente-blocco di latenza giù è buona!!!)

Penso che questo disegno di scala piuttosto bene inizialmente.Ogni componente del sistema può essere adattata facilmente:

• La coda di archiviazione può essere sostenuto da GAE, e in scala, come per qualsiasi Datastore tabella
• Le interfacce possono essere scalati, naturalmente, e non c'è bisogno di stickyness
• Più coda di processori possono essere aggiunti in qualsiasi momento
• La memorizzazione effettiva tabelle di crescere in modo naturale, e scala bene su Datastore.

Detto questo, ho in mente un paio di miglioramenti futuri vorrei guardare immediatamente:

• Ridurre stoccaggio di rado dati mostrati.Questo design denormalizes ogni tweet in ogni seguace di copia.Tuttavia, solo i più recenti tweet sono di solito accessibili.Eliminando il per-copia per l'utente di tweet dopo sono N giorni, siamo in grado di recuperare un sacco di spazio di archiviazione.Se un utente tenta di visualizzare qualcosa dalla storia antica, recuperiamo i dati da denormalizzato tabelle.Questo sarà più lento, ma non accade troppo spesso, e il risparmio sarà notevole.Risparmio di Storage:(#avg_followers - 1) / #avg_followers
• Scrivi schema non è ottimale.In più elementi della coda, coda lavoratore sarà iscritto a ogni utente tweet di tabella, quindi la frazione di scrive, non sarà molto buono.(Caso peggiore, dovremo #processore * #storage server per le connessioni). Questo può essere risolto applicando più aggiornamenti per ogni fascia di utenti.Per esempio, se due azioni A e B devono essere applicate per l'intervallo [0, 10000), quindi hanno una singola coda processore applicare queste due azioni in una sola volta.

Answer 2

È già stato fatto: Laconica

Answer 3

1. E ' già stato fatto Parte II - La Vendetta: identi.ca (che è al di sopra di Laconica)
2. E ' già stato fatto Parte III - Dal Lato Oscuro: yammer

VBG!(-:

Answer 4

Ho intenzione di partire dal presupposto di tornare a rifarla:cosa farei in modo diverso, sono io a twitter, allora?

Non è una cosa.

Twitter focalizzato l'attenzione su ciò che conta:fornire un servizio che la gente in realtà vuoi per utilizzare.

Mi piacerebbe lavorare su un prodotto che è diventato così popolare in un breve periodo di tempo in cui il suo più grande minaccia è diventata proprio la scalabilità.Il che significa che hai vinto.Con il successo deriva le risorse e l'attenzione per capitalizzare il successo.

Answer 5

Vorrei un design scalabile come l'inferno, solo dall'inizio.

La mia scelta sarebbe la Piattaforma di Microsoft, C#, IIS, SQL Server Memcached (o di Velocità, se è finale e funziona bene quando inizio ;-)