[Mysql / Architettura database] Quale scegliere per un sistema di messaggistica?

[\\Lup3n]

Salve sto lavorando ad un nuovo progetto, un nuovo social network, che sto progettando partendo dall'architettura del database.

Per il progetto ho pensato a dei server Linux con l'ausilio di nginx, Memcached, php, mysql e redis.

In questa community è ovviamente previsto un sistema di messaggistica privata tra gli iscritti ma non vorrei appesantire troppo il database principale (mysql) e cercavo una diversa soluzione, magari anche usando un altro tipo di database. Ovviamente i messaggi, come in tutti i social che si rispettino, sono la parte più cospicua in termini di gigabyte e volevo un consiglio da voi su quale tecnologie utilizzare, magari una soluzione scalabile su più server sparsi in europa. Nessuno ha informazioni in merito a come Facebook o Badoo gestiscono questa cosa? Secondo voi è il caso di affidarsi a database di terze parti tipo Amazon RDS o Google big query?

Grazie in anticipo.

[franzauker2.0]

Ma quanti utenti stimi di avere?

[in the web]

E' la moda del NoSQL...

Lupin, il NoSQL crea molti più problemi di quanti ne risolva. E comunque, credimi, se non hai lavorato in una banca non hai la benché minima idea di cosa significhi "big data". Usa MySQL.

E comunque, la chat che veniva usata un po' di tempo fa (o forse ancora ora?) sui portali di TIM, Virgilio, e altri, era un software C++ sviluppato da 4 persone, che teneva tutto in RAM, ma non si serviva di nessun db, né SQL né NoSQL né NewSQL, e non usava nessun tipo di cluster/replica/etc etc.

[\\Lup3n]

Originariamente inviato da franzauker2.0
Ma quanti utenti stimi di avere?

Non è importante, che faccio 12 o 12000 unici giornalieri ho intravisto un business che mi piace e ci voglio provare.
Difficilmente sbaglio :P

Scherzo ad ogni modo non voglio partire già con il piede sbagliato per la scelta del database o di un architettura che magari mi farà buttare il sangue nel caso effettivamente questo progetto mi va bene e devo poi scalare in europa su più server.

Mysql lo conosco molto bene e infatti lo userò come master, redis per le operazioni ad alta lettura/scrittura. Il master mysql non voglio appesantirlo con la tabella "messaggi" che si riempirà facile di giga e giga.

BigQuery di google, come Amazon RDS, facendo due conti costa veramente poco per un servizio molto affidabile. Il prezzo sale in base alle effettive richieste e per un progetto in startup a budget limitato non è mica male.

In the web
Per messaggistica non intendo una chat realtime, li opterei per un node.js che oltretutto si trova molta documentazione ed è praticamente tutto già scritto. Vorrei implementare qualcosa stile whatzup, badoo e la messaggistica di facebook.

[franzauker2.0]

Originariamente inviato da \\Lup3n
Non è importante, che faccio 12 o 12000 unici giornalieri ho intravisto un business che mi piace e ci voglio provare.
Difficilmente sbaglio :P

Bhè 12.000 visite giornaliere posso gestirle con un Commodore 64

Scherzo ad ogni modo non voglio partire già con il piede sbagliato per la scelta del database o di un architettura che magari mi farà buttare il sangue nel caso effettivamente questo progetto mi va bene e devo poi scalare in europa su più server.

Guarda, se dovrai scalare su più server in Europa (!!!!!) penso che troverai qualcuno da assoldare così da farlo per te

Mysql lo conosco molto bene e infatti lo userò come master, redis per le operazioni ad alta lettura/scrittura.

Ed a cosa ti dovrebbe servire redis, giusto per curiosità?

Il master mysql non voglio appesantirlo con la tabella "messaggi" che si riempirà facile di giga e giga.

E ti sembrano molti, giga e giga?
Ti segnalo che sono facilmente reperibili (io almeno ne ho uno) server con 384 GB di RAM. Non di disco, di RAM...

BigQuery di google, come Amazon RDS, facendo due conti costa veramente poco per un servizio molto affidabile. Il prezzo sale in base alle effettive richieste e per un progetto in startup a budget limitato non è mica male.

Procedi pure, poi magari segnala cosa stai sviluppando, così mi iscrivo pure io.

[\\Lup3n]

Bhè 12.000 visite giornaliere posso gestirle con un Commodore 64

Se hai 12000 visitatori unici che visitano 7 pagine del sito va bene, se hai 12 mila visite che consumato una media 7000 foto al giorno e 2300 query penso che dobbiamo passare ad un amiga 600? :-P

Guarda, se dovrai scalare su più server in Europa (!!!!!) penso che troverai qualcuno da assoldare così da farlo per te

Su questo mi stai convincendo, tutto queste pippe mentali sulla struttura, forse è più voglia di imparare e provare cose nuove che reale necessità. Adesso metto tutto su mysql e se divento bill gates poi assumo qualche sistemista con i cosidetti per scalare.

Ed a cosa ti dovrebbe servire redis, giusto per curiosità?

Visto che è un database molto veloce, risiede in ram, la query per gli utenti on line connessi, sarebbe carino implementare queste query con redis. Trattandosi di un db key=>value che poi sarebbe nickname=>timestamp,age,id_location non è nemmeno complessa da gestire.

Procedi pure, poi magari segnala cosa stai sviluppando, così mi iscrivo pure io.

Non vedo la luce prima di settembre, ma siccome sono addentrato abbastanza bene nelle pr ne sentirai parlare :-P

[optime]

Originariamente inviato da \\Lup3n
Su questo mi stai convincendo, tutto queste pippe mentali sulla struttura, forse è più voglia di imparare e provare cose nuove che reale necessità. Adesso metto tutto su mysql e se divento bill gates poi assumo qualche sistemista con i cosidetti per scalare.

con i dovuti distinguo, non è che ti compri subito un TIR per trasportare due cassette di zucchine, pensando che un giorno ti ingrandirai

Originariamente inviato da \\Lup3n
Non vedo la luce prima di settembre, ma siccome sono addentrato abbastanza bene nelle pr ne sentirai parlare :-P

wow tienici aggiornati!

[franzauker2.0]

Originariamente inviato da \\Lup3n
Se hai 12000 visitatori unici che visitano 7 pagine del sito va bene, se hai 12 mila visite che consumato una media 7000 foto al giorno e 2300 query penso che dobbiamo passare ad un amiga 600? :-P

Non direi, considera che ho macchine che eseguono 500 query al secondo, 24h / (e 2 millisecondi in media a query non sono esattamente molti) e che le foto non sono altro che payload

Visto che è un database molto veloce, risiede in ram, la query per gli utenti on line connessi, sarebbe carino implementare queste query con redis. Trattandosi di un db key=>value che poi sarebbe nickname=>timestamp,age,id_location non è nemmeno complessa da gestire.

Guarda, non ti serve alcun database.
Ti basta un array, se proprio vogliamo fare gli sborroni con un banale albero binario, neppure bilanciato. Niente hash e cazzi vari, troppo difficile, serve un pomeriggio di lavoro partendo da zero

Segnalo, inoltre, che una selezione con massima... selettività dell'indice (chiave primaria, 1 riga) è efficiente con qualsiasi rdbms, non dico mysql, ma perfino dbase III

Che dire? Il 99.99999% di tutti i cosiddetti "database nosql in RAM" sono banalmente sostituibili con programmelli che perfino una ragioniera programmatrice predisporrebbe in un paio di giorni, con una macchina a 64 bit.

Segnalo, così per dire, che mysql dispone di meravigliose tabelle HEAP (in RAM), che in realtà hanno il difetto essenziale di lock a tabella e non a record