Social networking

[alfaomega08]

Ciao. Io e alcuni miei amici (tutti pazzi), stiamo provando a mettere su un sito di Social Networking (facebook, myspace, twitter, ecc...). Ci sono venuti alcuni dubbi...
Alcune funzionalità di questi siti web permettono l'aggiornamento in tempo reale sullo stato di un altro utente. Twitter addirittura la ricerca di parole chiave nell'intero archivio dei messaggi.
Che razza di server gira sotto questi siti web per permettere la ricerca degli ultimi messaggi in tempo reale tra un oceano di messaggi?
Poi il database... abbiamo pensato che per rendere più veloce il tutto sia necessaria una o più tabelle per utente, con gli elenchi di amici, messaggi ecc. Ma con questo metodo si supererebbe il limite di 32.000 file per directory dell'ext3 (dato che in MySQL ogni tabella occupa 1-3 file). Allora abbiamo pensato a raccogliere tutto in file XML. Vari per ogni utente, all'interno della propria cartella, inserita in una directory presa in base ai primi 3 caratteri del nome.
Esempio: username: topogigio
la cartella sarebbe "t/o/p/o/user_topogigio"
In questo modo si potrebbero creare ben 14 miliardi di utenti senza raggiungere il limite di 32.000 file.
Ma comunque sarebbe lentissimo. Infatti se dovessi fare la ricerca degli ultimi messaggi dovrei aprire 14 miliardi di XML e selezionare gli ultimi arrivati.

Insomma questi siti si avvalgono di tecnologie sconosciute, oppure hanno dei server che consentono loro di fare questi movimenti alla velocità della luce?

Grazie in anticipo

[EvolutionCrazy]

tecnologie sconosciute non penso proprio sai...

aggiungo che non ho mai sentito nessuno progettare una base dati partendo da presupposti tipo "abbiamo pensato che per rendere più veloce il tutto sia necessaria una o più tabelle per utente, con gli elenchi di amici, messaggi ecc."

di solito si fa il contrario (almeno per database relazionali...)

memcached per esempio mai sentito?

pensi che google abbia meno roba da cercare rispetto a facebook?

[GrG]

Non puoi iniziare una cosa così pensando in grande, penso. A meno che non abbia qualche decina di miglia di euro da investire.

La scalabilità è una cosa fondamentale, ma applicarla in certi ambiti non è facile.

Metti su un CMS su un dedicato serio, poi quando avrai decine di migliaia di utenti inizierai a pensare a come ottimizzare il db per carichi estremi, il cluster di server e così via.

[WizOfOz]

.... e aggiungo che sicuramente non te la puoi cavare con un server... ce ne vorranno diversi e specializzati nei compiti con tanto di storage condiviso.

[guest]

decine di migliaia di euro?
hai dimenticato un paio di zeri vero?

[GrG]

No, non ne ho dimenticati.

Ho fatto due conti veloci per una infrastruttura seria, 50 000 € dovrebbero bastare per iniziare (amministrazione esclusa, si presume che se qualcuno vuole mettere su un SN non necessiti di consulenti esterni per gestire l'infrastruttura).

[FlameNetworks]

Non vedo il nesso tra MySQL e tutta quella mole di dati.
Per gestire svariati milioni di record ci vuole Oracle oppure DB2.

[guest]

non sono d'accordo.
i database bisogna saperli fare, wikipedia è fatto interamente in php+mysql così come anche youtube.
se non erro anche il 99% di tutti gli altri social network sono appoggiati su mysql.
basta dare una letta su highavailability (non ricordo mai il nome esatto) per rendersene conto.
io personalmente ho tre database da oltre 3 milioni e mezzo di record, una è del nostro analitycs interno, uno è di un cliente mentre il terzo è del nostro booking online, riempito volutamente con esattamente 200000 clienti di test ed almeno 1 anno di tariffe per ogni camera di ogni cliente (1 record per ogni giorno per ogni camera per ogni cliente, a te i conti)

nessuno dei tre è lento o di difficile gestione.

[WizOfOz]

Certo... devi scegliere il prodotto giusto e per questi progetti o hai una grande esperienza o ti devi affidare a qualcuno che li conosce molto bene... non basta scaricare mysql e installare

MySQL :: MySQL Cluster

[guest]

Occhio che MySQL cluster non è sempre utilizzabile.
Fa girare tutto il database in ram su tutti i nodi, ovvero se ha un DB da 100GB, devi avere anche 100GB di ram disponibile ad esso.

Purtroppo, in questo ambito (social networking), dubito possa essere utile, considerata la grossa mole di dati che si andranno a veicolare.

Però, si possono studiare tante belle cose, come ad esempio due nodi in mysql cluster per le transazioni principali, e due nodi in mysql normale per l'archivio dei dati meno richiesti e così via.
Così facendo, i nodi in cluster conterranno solo i dati degli ultimi minuti/ore/giorni occupando poco spazio, mentre chi richiede dati più vecchi sarà veicolato su mysql normale.

Un po come youtube, se apri un video di 4 mesi fa, è più lento durante il download rispetto ad un video caricato ieri o comunque sia con molti accessi. Probabilmente perchè la cdn è usata solo per i video più frequenti.

[FlameNetworks]

non sono d'accordo.
i database bisogna saperli fare, wikipedia è fatto interamente in php+mysql così come anche youtube.
se non erro anche il 99% di tutti gli altri social network sono appoggiati su mysql.
basta dare una letta su highavailability (non ricordo mai il nome esatto) per rendersene conto.
io personalmente ho tre database da oltre 3 milioni e mezzo di record, una è del nostro analitycs interno, uno è di un cliente mentre il terzo è del nostro booking online, riempito volutamente con esattamente 200000 clienti di test ed almeno 1 anno di tariffe per ogni camera di ogni cliente (1 record per ogni giorno per ogni camera per ogni cliente, a te i conti)

nessuno dei tre è lento o di difficile gestione.

Il punto non è se i DB li sai progettare o meno.
Ti posso garantire che il sistema di billing dove lavoro MySQL non lo regge.
In termini di performances ed affidabilità, Oracle e/o DB2 non sono comunque paragonabili a MySQL, soprattutto su sistemi che gestiscono decine di milioni eventi giornalieri.

[guest]

Il punto non è se i DB li sai progettare o meno.
Ti posso garantire che il sistema di billing dove lavoro MySQL non lo regge.
In termini di performances ed affidabilità, Oracle e/o DB2 non sono comunque paragonabili a MySQL, soprattutto su sistemi che gestiscono decine di milioni eventi giornalieri.

Oracle è superiore, senza dubbio, ma come ho detto io ho siti che generano tali cifre su database da milioni di record (se fai il calcolo del solo database del nostro booking vedrai che sono 73 milioni di record in modalità 'base' con solo 1 camera, ed i media gli hotel ne hanno 5 o 6 l'uno [è uno stresstest per vedere se il database è stato creato correttamente, purtroppo non abbiamo 200.000 hotel come clienti]) e non hanno alcun problema prestazionale.
Il database va tarato, va creato in un determinato modo, le tabelle vanno ottimizzate e gli indici van studiati a tavolino in base alle applicazioni che ne faranno uso.
Sullo stesso server ho anche database che con poche visite collassano (wordpress, ad esempio) ma non è un problema di mysql, ma di wordpress che è fatto da cani.
MySQL se ottimizzato è un ottimo database, non ai livelli di Oracle, ma comunque un ottimo database in grado di reggere senza problemi milioni di richieste su database con milioni di record.

Credo che dire che per milioni di visite non si debba usare mysql ma oracle sia utilizzare la nomea di quest'ultimo per "sentirsi più sicuri".
Ci è già capitato di un cliente che ha scelto IBM esclusivamente per il nome ed in caso di problemi ha scaricato la colpa su di noi perchè lui....."ha comprato un IBM, non un server da supermercato, è un IBM, non può aver problemi, è per forza colpa vostra".

Il tipico scarica-barile che scarica tutto sugli altri facendo leva su un marchio.

[FlameNetworks]

Forse non mi sono spiegato...non sono i nomi nè il sentirsi più sicuri a fare la differenza, bensì l'affidabilità e le performances (alias livello di servizio) nel contesto in cui l'applicazione deve essere utilizzata.
Infatti non metterei mai un sistema di billing che in un'ora fattura mediamente 500 mila € su MySQL, così come non metterei mai Oracle su un sito che fa 10 GB di traffico al mese.
Oltretutto nel nostro caso non puoi dare la colpa al consulente che ha fatto un errore nè al tizio che sta alla control room. Se qualcosa non funziona Oracle e HP devono correre a sistemare e pure in fretta, sennò scattano delle penali salatissime.
E' ovvio che se il cliente si sente meglio ad usare certi marchi non posso biasimarlo.

[guest]

Nel tuo caso hai ragione, nemmeno io, probabilmente, utilizzerei mysql se in un ora veicolassero 500mila euro.

Ma qui si parlava di un social network, e mysql è perfettamente in grado di gestire milioni di richieste su milioni di record. tutto qui.
Quel che non capisco è perchè suggerisci oracle o db2 "a priori" sapendo che si parla di social network e non di operazioni finanziarie. Non è la borsa di Londra, ma una community online.

[FlameNetworks]

Perchè un disservizio, in questi casi, comporterebbe perdita di denaro.
E' vero che FB ha un'architettura basata su MySQL però è distribuita su molti server (se non ricordo male saranno un migliaio di macchine) quindi riesce a gestire tutte le richieste degli utenti (anche se qualche volta l'ho visto fermo) e tutto questo ha dei costi molto elevati.