MongoDB o Cassandra sono migliori di MySQL per dataset di grandi dimensioni?

Question

Nel nostro database (attualmente MySQL) ci sono oltre 120 milioni di record, e facciamo uso frequente di query JOIN complesse e logiche a livello di applicazione in PHP che toccano il database. Siamo una società di marketing che fa del data mining il nostro obiettivo principale, quindi abbiamo molti report di grandi dimensioni che devono essere eseguiti su base giornaliera, settimanale o mensile.

Allo stesso tempo, il servizio clienti opera su uno slave replicato dello stesso database.

Ci piacerebbe essere in grado di rendere questi rapporti in tempo reale sul Web anziché dover generare manualmente fogli di calcolo per loro. Tuttavia, molte delle nostre relazioni impiegano una notevole quantità di tempo per estrarre i dati (in alcuni casi, più di un'ora).

Non operiamo nel cloud, scegliendo invece di operare utilizzando due server fisici nella nostra sala server.

Dato tutto ciò, qual è la nostra migliore opzione per un database?

Answer 1

Penso che stai andando nella direzione sbagliata del problema.

Pensare se si scende a NoSQL per ottenere prestazioni migliori non è proprio vero. Al livello più basso, stai scrivendo e recuperando una buona fetta di dati. Ciò implica che il collo di bottiglia è (molto probabilmente) I/O HDD (che è il collo di bottiglia comune).

Attaccare all'hardware che si ha per un momento e utilizzare una memoria monolitica dei dati non è scalabile e, come hai notato, ha implicazioni quando si vuole fare qualcosa in tempo reale.

Quali sono le opzioni? È necessario ridimensionare l'installazione del server e del software (che è ciò che si dovrebbe fare con qualsiasi NoSQL in ogni caso, inserire ad un certo punto i dischi rigidi più veloci). Si potrebbe anche voler guardare ai motori di memorizzazione alternativi (diversi da MyISAM e InnoDB - per esempio, uno dei migliori motori che sembra trasformare I/O casuali in I/O sequenziali è TokuDB).

Implementazione sottosistema disco rigido più veloce sarebbe di aiuto anche alle proprie esigenze (FusionIO se si hanno le risorse per farlo).

Senza ulteriori informazioni sulla tua destinazione (quale sia la configurazione del server, quale versione di MySQL stai usando e quali motori di archiviazione + dimensioni dei dati stai operando), è tutta una speculazione.

Answer 2

Cassandra ha ancora bisogno di Hadoop MapReduce per e MongoDB ha limitato la concorrenza per quanto riguarda MapReduce ...

... così ...

... 120 milioni di record non è più di tanto, e MySQL dovrebbe essere facilmente in grado di gestirlo. La mia ipotesi è un collo di bottiglia di IO, o stai facendo un sacco di letture casuali invece di letture sequenziali. Preferirei assumere un tecnico MySQL per un mese circa per mettere a punto schemi e query, invece di investire in una nuova soluzione.

Se fornisci ulteriori informazioni sul tuo cluster, potremmo essere in grado di aiutarti meglio. "NoSQL" da solo non è la soluzione al tuo problema.

Answer 3

Per quanto non sia un fan di MySQL una volta che i tuoi dati diventano grandi, devo dire che non sei neanche lontanamente a dover passare a una soluzione NoSQL. Le righe da 120M non sono un problema: il database con cui sto lavorando ha ~ 600M in una sola tabella e lo interrogiamo in modo efficiente. La gestione di molti dati da una prospettiva operativa è il problema; interrogarlo non lo è.

Riguarda gli indici corretti e l'uso corretto di questi quando si uniscono e in secondo luogo le impostazioni di memoria. Trova le tue query lente (mysql slow query log FTW!) E impara a usare per spiegare la parola chiave per capire se sono lenta. Quindi modifica i tuoi indici in modo che le tue query siano efficienti. Inoltre, assicurati di aver compreso le impostazioni di memoria di MySQL. Ci sono grandi pagine nei documenti che spiegano come funzionano, e non sono così difficili da capire.

Se hai fatto entrambe le cose e hai ancora problemi, assicurati che l'I/O del disco non sia un problema. Quindi si dovrebbe cercare in un'altra soluzione per interrogare i dati se lo è.

Soluzioni NoSQL come Cassandra hanno molti vantaggi. Cassandra è fantastica per scrivere dati. Ridimensionare le tue scritture è molto semplice: basta aggiungere più nodi! Ma il compromesso è che è più difficile recuperare i dati. Dal punto di vista dei costi, se hai esperienza in MySQl, probabilmente è meglio sfruttarlo e scalare la tua soluzione attuale fino a raggiungere un limite prima di cambiare completamente l'architettura sottostante.