Infrastruttura per DB altamente simultaneo e ad alta scrittura

I miei requisiti sono:

• 3000 connessioni
• 70-85% Scrivi vs Leggi

Attualmente, stiamo esaurendo un'istanza extra-CPU ad alta CPU con 700 connessioni. Tutti gli 8 core sono al massimo. Pensiamo che sia il numero di connessioni simultanee poiché la memoria va bene. La scrittura stessa è molto semplice (le convalide rallentano le cose). Per scalare a 3000, dobbiamo andare su più server, le opzioni attuali:

• MySQL Sharding
• Cluster MongoDB
• cassandra
• Hadoop e MySQL (cache Hadoop, dump singolo su MySQL)
• MongoDB e MySQL (invece di Hadoop, utilizziamo mongo per la cache)

Per gestire questo numero di connessioni, una serie di domande:

1. MySQL Sharding può gestire le connessioni simultanee?
2. Può un singolo master gestire queste connessioni simultanee o è un multi-head come Mongo un'opzione migliore?

Mi scuso se non sto descrivendo bene il mio problema. Si prega di porre domande.

Se si utilizza MySQL come database principale, è consigliabile prendere in considerazione l'utilizzo di una topologia a stella tramite MySQL Replication.

Ora, prima di dire UGHHH, ROFL e OMG a MySQL Replication, ascoltami.

Una topologia a stella consente di scrivere su un server DB (chiamato Distribution Mster [DM]) e inviare i comandi SQL a più server DB. Come si configura tale infrastruttura DB?

Ecco la descrizione

Hai 5 server DB (server A, B, C, D, E)

Server A

• Nella configurazione di MySQL Replication, sarà il Master
• Svolge un ruolo speciale come DM
• Master dei server B, C, D, E
• Tutte le tabelle utilizzano il motore di archiviazione BLACKHOLE (/ dev / null)
• Memorizza solo i registri binari
• Macchina di metallo nudo
• Benefici
  • Scritture molto veloci poiché tutte le tabelle sul DM usano BLACKHOLE
  • La latenza di rete è meno problematica poiché le letture rappresentano il 15-30% dell'attività DB
  • Tutti gli slave vengono aggiornati rigorosamente dal DM

Server B, C, D, E

• Schiavo di A
• Server una base per SELECT pesanti
• Il server può essere virtuale o bare metal
• Per tutti i server le cui tabelle utente utilizzano il motore di archiviazione InnoDB
  • Può essere utilizzato come DB Server warm standby
  • È possibile eseguire backup non invadenti
• Per tutti i server le cui tabelle utente utilizzano il motore di archiviazione MyISAM
  • Configurato con oprion di sola lettura
  • Le tabelle possono avere i loro formati di riga rifatti per accelerare le letture

Ho scritto post su questo prima

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Per mantenere la replica MySQL in perfetta forma

• Usa MySQL 5.5
• Utilizzare la replica semisincrona
• Ottimizza InnoDB per coinvolgere più CPU

MySQL Cluster potrebbe essere un altro approccio allo sharding. Controlla il post qui .

Sono anche un grande fan di Cassandra, ma dipende molto dal tuo modello di dati e dalle query che desideri eseguire. Cassandra è velocissima da scrivere, perché sono sempre sequenziali su disco.

Se hai intenzione di utilizzare la modalità multi-head (cosa che probabilmente ti servirà se hai davvero bisogno di connessioni attive 3K) probabilmente guarderei Riak o forse Cassandra. Dipende davvero da cosa fa la tua app per quanto bene si adatteranno, ma da quello che hai descritto penso che si adatterebbe a qualcosa come Riak.

Detto questo, un approccio frammentato sembra abbastanza fattibile, se riesci a trovare un buon modo per segmentare i dati e puoi ridurre al minimo qualsiasi necessità di cose cross-shard. Starei lontano da qualsiasi cosa di ring / star / mmm in mysql e mi limiterei a stare dritto in sharding. In realtà, se tu fossi disposto a usare Postgres, potresti prototipare abbastanza facilmente usando schemi su qualcosa come heroku, e poi biforcare e dividere i database mentre iniziano a diventare più grandi dei singoli nodi.

Oh, e mentre penso che potresti provare a ridimensionare qualcosa del genere verticalmente (nodo singolo che gestisce tutti i conn 3K), non penso che tu possa farlo nel cloud.

Se è un'opzione per la tua specifica applicazione, forse puoi usare un modo asincrono per scrivere i dati nel tuo database (coda di lavoro, inserti in batch ...) e / o spostare le numerose connessioni client dal tuo database con un proxy in primo piano .

Con lo sharding puoi generalmente ridimensionare bene (2x db-server == 2x connessioni), ma dipende fortemente dalla natura del tuo set di dati e da come puoi dividerlo tra i frammenti.

Personalmente preferisco MongoDB per la sua facilità di amministrazione, scalabilità, facilità d'uso generale. Inoltre, a meno che non abbia effettivamente bisogno di un RDBMS, userò un no-SQL.

Detto questo, scegli il DB che ha più senso per la tua applicazione. Se hai bisogno di Transazioni o non riesci a progettare la tua app senza Join (o semplicemente ha più senso con loro) allora usa un RDBMS (MySQL, PostGres, ecc.)

Mentre personalmente preferisco MongoDB, l'idea che MySQL non ridimensioni o non possa gestire un alto tasso di transazioni è puramente falsa. Il team di ingegneria di Facebook (e il team MySQL al suo interno) approfondisce i dettagli. Dai un'occhiata anche al blog del team Etsy Ops; adorano anche MySQL.

Infine, non userei MongoDB per una cache MySQL; usa Memcached per quello.

Redis è anche un archivio di valori-chiave in-RAM adatto per la gestione di determinati casi d'uso. Ci sono alcune voci di blog su blog.agoragames.com che descrivono alcuni casi d'uso.

Dovresti anche dare un'occhiata a CouchDB se stai pensando a No-SQL. Basta essere consapevoli del fatto che richiede una manutenzione regolare per mantenere basso l'utilizzo del disco. (Scambia velocità e convenienza per l'utilità del disco ...)

Infine, la pianificazione della capacità non è facile da prevedere. Devi testare il più realistico possibile ed essere pronto a rimediare in base a ciò che vedi. Purtroppo "Informatica" è tanto arte quanto scienza.