Funzionalità massime di MySQL

Question

Come faccio a sapere quando un progetto è troppo grande per MySQL e dovrei usare qualcosa con una migliore reputazione per la scalabilità?

Esiste una dimensione massima del database per MySQL prima che si verifichi un peggioramento delle prestazioni? Quali fattori contribuiscono al fatto che MySQL non sia un'opzione valida rispetto a un DBMS commerciale come Oracle o SQL Server?

Answer 1

Principalmente è la dimensione del tavolo.

Suppongo qui che utilizzerete il plugin Oracle innoDB per mysql come motore. Se non lo fai, probabilmente significa che stai utilizzando un motore commerciale come infiniDB, InfoBright per Tokutek, nel qual caso le tue domande dovrebbero essere inviate a loro.

InnoDB diventa un po 'sgradevole con tavoli molto grandi. Si consiglia di suddividere le tabelle se possibile con istanze molto grandi. In sostanza, se gli indici (usati di frequente) non si adattano tutti alla ram, gli inserimenti saranno molto lenti in quanto devono toccare molte pagine non nella ram. Questo non può essere risolto.

È possibile utilizzare la funzione di partizionamento MySQL 5.1 se fa ciò che si desidera, o partizionare le tabelle a livello di applicazione, in caso contrario. Se riesci a far rientrare gli indici dei tuoi tavoli nella ram e carichi solo un tavolo alla volta, allora sei un vincitore.

È possibile utilizzare la compressione del plug-in per fare in modo che la RAM passi un po 'oltre (poiché le pagine sono compresse sia su RAM che su disco) ma non può battere la limtation fondamentale.

Se gli indici della tabella non tutti (o almeno MOSTAMENTE - se si hanno alcuni indici che sono NULL nel 99,99% dei casi che si potrebbero ottenere senza quelli) si inseriscono nella ram, la velocità di inserimento risulterà tale.

La dimensione del database non è un grosso problema, a condizione che le tabelle si adattino individualmente nella ram mentre si esegue il caricamento in serie (e, naturalmente, si carica solo una alla volta).

Queste limitazioni si verificano realmente con la maggior parte dei database basati su riga. Se hai bisogno di più, prendi in considerazione un database di colonne.

Infobright e Infinidb utilizzano entrambi un nucleo basato su mysql e sono basati su colonne che possono gestire tabelle molto grandi.

Anche Tokutek è molto interessante: è possibile contattarli per una valutazione.

Quando si valuta l'idoneità del motore, assicurarsi di caricarlo con dati molto grandi sull'hardware di produzione. Non ha senso testarlo con un database (ad esempio) 10G, che non dimostrerà nulla.

Answer 2

Google utilizza MySQL. Il tuo progetto è più grande di Google?

Commenti di Smart-alec a parte, MySQL è un'applicazione di database di livello professionale. Se la tua applicazione mette a dura prova MySQL, scommetto che farà lo stesso con qualsiasi altro database.

Answer 3

Se siete alla ricerca di un paio di esempi:

• Facebook si trasferì a Cassandra solo dopo che è stato immagazzinando oltre 7 terabyte di dati di posta in arrivo. (Fonte: Lakshman, Malik: Cassandra - A Decentralized Structured Storage System.) (... Anche se stavano avendo un bel numero di problemi in quella fase.)

• Wikipedia anche handles hundreds of Gigabytes di dati di testo in MySQL.

Answer 4

MySQL è un DBMS commerciali, basta la option di ottenere il sostegno/monitoraggio che viene offerto da Oracle o Microsoft. Oppure puoi usare il supporto della comunità o il software di monitoraggio fornito dalla comunità.

Answer 5

Le cose che dovresti guardare non sono solo le dimensioni delle operazioni. Critici sono anche:

• Scenari per il backup e il ripristino?
• Manutenzione. Esempio: SQL Server Enterprise può ricostruire un indice MENTRE IL VECCHIO È DISPONIBILE - in modo trasparente. Ciò significa nessun tempo di inattività per la ricostruzione di un indice.
• Disponibilità (in pratica non si vuole dover ripristinare un database da 5000 gb se un server muore) - il mirroring preferito, la replica "succhia" (tecnicamente).

Qualunque cosa tu stia cercando, stai attento con Oracle RAC (il loro cluster) - è noto per essere "problematico" (per dirlo con precisione). SQL Server è noto per essere molto più economico, scala molto peggio (nessuna opzione "RAC") ma fondamentalmente funziona senza che gli amministratori vogliano suicidarsi ogni ora (l'opzione "RAC" sembra farlo). La scalabilità "molto peggio" è ancora abbastanza buona per il Terra Server (http://msdn.microsoft.com/en-us/library/aa226316(SQL.70).aspx)

Qui ci sono alcune domande di persone che hanno problemi a ricostruire gli indici su un database da 10 GB o qualcosa del genere.

Così tanto per i miei 2 centesimi. Sono certo che alcuni specialisti di MySQL salteranno sui problemi lì.

Answer 6

Lavoro per una grande azienda di Internet. MySQL può scalare molto, molto grande con ottime prestazioni, con un paio di avvertimenti.

Un problema che potresti incontrare è che un indice superiore a 4 gigabyte non può entrare in memoria. Ho dedicato molto tempo a provare a migliorare le prestazioni full-text di MySQL manipolando alcuni parametri dell'indice, ma non è possibile aggirare il problema fondamentale che, se la query raggiunge il disco per un indice, rallenta.

Potresti trovare alcune applicazioni di supporto che possono aiutarti a risolvere il tuo problema. Per il problema full-text, c'è Sfinge: http://www.sphinxsearch.com/

Jeremy Zawodny, che ora lavora alla lista di Craig, ha un blog su cui di tanto in tanto discute le prestazioni dei grandi database: http://blog.zawodny.com/

In sintesi, il progetto probabilmente non è troppo grande per MySQL. Potrebbe essere troppo grande per alcuni dei modi in cui hai già utilizzato MySQL e potrebbe essere necessario adattarli.