Come si sceglie un motore di database MySQL

16

In particolare, come scegliere tra MyISAM e InnoDB, quando nessuno dei due manca di una funzionalità richiesta (ad es. Non sono necessarie chiavi esterne).

Si tratta sempre di provare entrambi e misurare? Oppure ci sono buone regole empiriche per quanto riguarda il numero e la frequenza delle letture rispetto alle scritture e altre misure del genere? La dimensione della tabella ha qualche effetto sulla scelta tipica?

mysql innodb myisam

— Tony Meyer
fonte

6

La risposta è che dovresti sempre misurare, preferibilmente con i tuoi dati e il tuo carico di lavoro, se possibile.

Poiché i modelli di accesso ai dati possono variare notevolmente da un'app all'altra, è difficile da dire e con ogni probabilità impossibile determinare un motore di archiviazione "migliore" per tutti i carichi di lavoro.

Tuttavia, ci sono stati sviluppi molto incoraggianti nello spazio MySQL che hanno partecipato a MySQLConf / Percona Performance Conf la scorsa settimana.

Alcuni dei motori di archiviazione alternativi:

XtraDB (fork di InnoDB)
Plugin InnoDB
PBXT
TokuDB

Inoltre, Percona, Google, ecc. Hanno contribuito con patch che aiutano notevolmente con le prestazioni di InnoDB. Personalmente, eseguo una build OurDelta. Funziona bene per me e incoraggio a dare un'occhiata ai build di OurDelta e Percona.

— Jauder Ho
fonte

Se sei interessato ai benchmark, prova sysbench o iibench.

— Jauder Ho,

Qualcuno dei motori di stoccaggio alternativi è abbastanza stabile da essere adatto per un sito di produzione?

— Tony Meyer,

Don MacAskill sta cercando di mettere in produzione XtraDB. YMMV.

— Jauder Ho,

Le prestazioni non sono l'unico requisito - considera anche le questioni operative (in realtà sono di solito più importanti, secondo la mia esperienza)

— MarkR,

Ovviamente, le prestazioni non sono l'unico requisito, anche se credo che la richiesta originale chiedesse di più su perf. Altre considerazioni come quelle operative (come sottolineato) e le caratteristiche avranno tutte un ruolo nel processo di selezione.

— Jauder Ho,

5

Se è solo un semplice sistema di archiviazione / report, utilizzo MyISAM per le sue prestazioni non elaborate.

Userei InnoDB se fossi preoccupato per più accessi simultanei con molte scritture, per sfruttare il blocco a livello di riga.

— Alnitak
fonte

1

Per qualsiasi carico di lavoro che mescola letture e scritture, InnoDB è l'unica opzione (attualmente in fase di spedizione).

— Dave Cheney,

4

Esistono numerosi benchmark per diversi motori di database MySQL. Ce n'è uno decente che confronta MyISAM, InnoDB e Falcon sul blog sulle prestazioni MySQL di Percona , vedi qui .

Un'altra cosa da considerare tra i due motori di cui sopra (MyISAM e InnoDB) sono i loro approcci al bloccaggio. MyISAM esegue il blocco delle tabelle, mentre InnoDB esegue il blocco delle righe. Ci sono una varietà di cose da considerare, non solo le cifre delle prestazioni.

— James B
fonte

4

Ci sono funzionalità che troverai molto utili, per motivi operativi, anche se l'applicazione non le richiede assolutamente:

InnoDB ha MVCC, il che significa che è possibile eseguire backup coerenti senza blocco
InnoDB ha il ripristino automatico, il che significa che non sono necessarie lunghe operazioni di TABELLA DI RIPARAZIONE dopo uno spegnimento impuro
Con InnoDB, i lettori non bloccano mai gli scrittori e viceversa, il che significa (in generale) una maggiore concorrenza (questo non significa necessariamente prestazioni migliori nel caso generale)
InnoDB raggruppa le sue righe sulla chiave primaria, il che può significare meno operazioni di I / O per le operazioni di lettura SE la chiave primaria è stata scelta sufficientemente bene.

Quindi, nonostante i vincoli di chiave esterna, probabilmente si desidera utilizzare comunque InnoDB.

ovviamente questo è ServerFault, non StackTranslate.it, quindi la risposta corretta è:

È sempre necessario utilizzare il motore scelto dagli sviluppatori dell'applicazione
Se non hanno scelto un motore specifico, non sono molto seri sull'uso di MySQL e probabilmente non sanno come usarlo correttamente.
Non è possibile passare a un motore diverso da quello su cui è stata testata l'applicazione, in quanto potrebbe introdurre bug.

— MarkR
fonte

2

Pensi davvero che il motore di database sia una decisione dello sviluppatore, non degli amministratori? Come sviluppatore, voglio dire "Ho questi dati, che lo farò con" e lascerò l'ottimizzazione (e il backup, e ...) del database all'amministratore.

— Tony Meyer,

1

Sì, lo sviluppatore deve essere in grado di sviluppare e testare la propria app su un motore specifico; si comportano in modo molto diverso sia funzionalmente che in termini di prestazioni.

— MarkR,

2

Il mio provider di hosting ci ha consigliato di eliminare completamente MyISAM e passare a InnoDB, a meno che non sia possibile.

Nel nostro caso abbiamo avuto una grave corruzione dei dati che ha iniziato a mostrare da poche volte a poche volte al giorno, richiedendo sempre TABELLA DI RIPARAZIONE e comandi correlati, che hanno richiesto anni su grandi tabelle.

Una volta convertiti (o: convertiti) in InnoDB, i problemi sono scomparsi all'istante. Svantaggi / avvertimenti che abbiamo avuto:

Impossibile convertire le tabelle con l'indice FULLTEXT (questo problema è scomparso nel tempo da solo; è stato sostituito con una soluzione basata su Solr / Lucene che ha comunque una qualità molto migliore)
Le grandi tabelle con milioni di righe che spesso richiedono COUNT (*) erano molto lente, non siamo stati in grado di cambiare neanche quelli.

Ma nota: questo è tutto specifico per il nostro ambiente, ecc., Quindi potrebbe non essere generalmente applicabile.

— marchio
fonte

Seleziona solo count ( ) dalla tabella è più veloce in MyISAM. Seleziona count ( ) dalla tabella dove column = value ha prestazioni simili sia su MyISAM che InnoDB. mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables

— sumar