[mysql] Motore tabelle

[mysql] Motore tabelle postato il 11/01/2011 00:06:29 nel forum programmazione, gdrcd, open source, hosting

Ho letto in questi giorni un articolo interessante sulla "uscenda" versione 5.5 di MySql, che dovrebbe prevedere il passaggio a InnoDB come motore di default in luogo del "vecchio" MyISAM.
La novità starebbe anche nel fatto che se non ho capito male InnoDB dovrebbe funzionare "nativamente" e non come plugin, con le conseguenze del caso in termini di velocità di risposta, rispetto alle tabelle InnoDB su mysql 5.1

L'articolo presentava dei grafici comparativi sulla velocità di risposta in funzione del numero di connessioni, mettendo a paragone MyISAM, InnoDB su Mysql 5.1 e InnoDB su Mysql 5.5

La cosa più interessante sembra essere questa: fino a 16 connessioni la velocità non é sensibilmente diversa, mentre oltre le 16 connessioni si verificano dei "picchi" che iniziano a rendere sensibili le differenze.

Nel range da 16 a 32 connessioni InnoDB si mostra notevolmente più veloce di MyISAM, con una maggiore velocità per la versione su MySql 5.5
Inutile dire che quel range (16-32 connessioni) é quello probabilmente più interessante per la gran parte delle land di gdr online.

Oltre le 32 connessioni anche InnoDB su MySql 5.1 comincia ad arrancare, rispetto al suo pari "nativo" su MySql 5.5, pur dimostrandosi comunque più performante di MyISAM.

Le domande sono le seguenti... considerando che l'hosting al momento fornisce MySQL 5.1, quindi con InnoDB come plugin:

1) Può valere la pena di cambiare motore alle tabelle? Il ragionamento é questo: anche se non venisse adottato in futuro MySQL 5.5, per il range 16-32 connessioni InnoDB sembra comunque più veloce. E in caso di upgrade a 5.5 lo sarebbe ancora di più.

2) Corro qualche rischio ad effettuare l'operazione di cambio del motore delle tabelle dall'interfaccia di PhpMyAdmin? Richio perdita/corruzione di dati?

Grazie mille

---

quota

11/01/2011 00:19:12

http://www.openskill.info/infobox.php?ID=1412 ↗

---

quota

11/01/2011 00:50:34 e modificato da ghennadi72 il 11/01/2011 01:56:39

Interessante, ma non risponde più che tanto ai miei dubbi. A parte la questione del mancato supporto degli indici FULLTEXT da parte di InnoDB, ed un avviso che ho letto su wikipedia a proposito della maggiore lentezza delle SELECT con COUNT(*) su tabelle di grandi dimensioni.

http://dev.mysql.com/doc/refman/5.1/en/converting-tables-to-innodb.html ↗

In sostanza, limitando le informazioni a quello che é il nostro campo di interesse, mi pare di capire che i limiti di InnoDB possono essere:

- tablespace più grande a parità di dati
- assenza di indici FULLTEXT (quanto sono comuni nel nostro campo?)
- maggiore lentezza sulle SELECT COUNT(*) su grandi tabelle (grandi quanto?)
- pericolo di interruzione della conversione MyISAM > InnoDB se durante la conversione si riempie il tablespace, con conseguente riconversione che può durare ore.

Ho trovato altri articoli che suggeriscono che la differenza di prestazioni tra MyISAM e InnoDB non sia poi così elevata, ma a dire il vero sembrano piuttosto datati (2008 o giù di lì), rispetto ai test comparativi riportati dall'articolo che ho letto (su Linux & C., numero 72).

La mancata ricerca FULLTEXT onestamente, a parte la ricerca sui post di un forum/bacheca (con ordinamento dei risultati in base alla pertinenza del risultato trovato) non trovo abbia applicazioni sostanzialmente indispensabili nel nostro campo, sempre che non sia io ad aver capito male a cosa servono gli indici FULLTEXT.

Toh, forse sulle tabelle coi nomi dei personaggi potrebbe essere utile una ricerca ordinata per pertinenza, ad esempio quando si inserisce la parte di un nome per cercare tutti i pg che contengono le lettere indicate. Ma mi chiedo se sia una funzionalità davvero tanto indispensabile da non poter usare il classico WHERE NOMECAMPO LIKE '%CHIAVE%' e simili. Mi viene in mente una land molto famosa e popolosa a caso che campa benissimo senza presentarel'elenco dei PG trovati in ordine di pertinenza rispetto alla chiave di ricerca.

In ogni caso comunque nulla vieterebbe di mantenere il motore MyISAM solo sulle tabelle sulle quali può occorrere una ricerca ordinata per pertinenza del risultato.

Quindi in sostanza resto coi miei dubbi. 😶

---

quota

11/01/2011 01:51:38

Beh in teoria non dovresti averne.
Detto tra noi, nel nostro campo come dici tu, la multiconcorrenza è talmente ridicola che la questione prestazioni neanche si pone.

Soprattutto là dove, come noi appunto, non hai una macchina dedicata.
E' irrilevante che cosa fai tu se tutti quelli che condividono il db server nel tuo hosting sono degli sciagurati che lo mandano in bomba.

Le ottimizzazioni di certe prestazioni hanno senso unicamente quando la macchina è tua e ci sei solo tu, altrimenti ogni tua ottimizzazione sarà quasi sempre annullata dalle possibili porcherie del tuo "vicino".

E mi riferisco a quelle ottimizzazioni che impattano sul processore, ram della macchina (che non è appunto usata solo da te).

Ma va da se, come ho detto sopra: per le multiconcorrenze che abbiamo in questi giochi penso che comunque questi scrupoli se li debbano fare giochi con tutt'altra utenza

---

quota

11/01/2011 02:03:27

Beh certo, quello é ovvio... la schiavitù a "quello che fa il vicino di hosting" é un collo di bottiglia sempre presente. Ciò non toglie che dove possibile, in via generale, é preferibile ottimizzare quello che si può ottimizzare.

Il fatto che il mio vicino di "casa" per tirare fuori 6 valori di 6 colonne di uno stesso record, faccia 6 query estraendo i valori uno per uno e senza aver definito manco un indice sulla tabella, anzichè un'unica query, non implica che debba farlo anch'io con la scusa che "tanto se lo fa il mio vicino, rallenta anche me" :-)

Siamo d'accordo che parliamo di incrementi di prestazione assolutamente teorici, ma la domanda ha una sua valenza generale in quest'ottica. Oggi gestiamo il DB di una land, domani potremmo gestire invece il DB di un sito di e-commerce su server dedicato e magari potrebbe essere utile ricordarsi quello che si è imparato "ai vecchi tempi", anche se ai vecchi tempi l'utilità pratica era poca. :-)

---

quota

11/01/2011 02:14:19

Si, ma una domanda posta non ha una risposta unica universale e valida per tutte le casistiche.

Bada bene che io non ho detto che non ha senso ottimizzare, ho detto che certe ottimizzazioni sono inutili.
Secondo me quella del motore è una di quelle dato che opera sul carico del processore su cui non hai alcun controllo o certezza per i motivi sopra detti.

Ottimizzare una query ha senso invece perchè velocizza la risposta ai tuoi script e quindi le prestazioni del tuo prodotto (che è diverso dalle prestazioni della macchina su cui si basa la scelta di un motore appunto).

Altro discorso ancora è se vuoi scegliere un motore invece di un altro a fronte delle funzioni che ti mette a disposizione e di cui ti puoi quindi avvantaggiare nel tuo prodotto.

Insomma, come vedi cambia di parecchio la risposta a seconda dell'argomento, del contesto e dell'ottimizzazione che si vuole cercare.
Per quello che avevi posto tu inizialmente (o almeno per come l'ho capito io, cioè l'ottimizzazione del carico del motore sul server) la risposta è: è indifferente il motore che scegli.

---

quota

11/01/2011 02:33:54

Le innoDB son meno prestanti rispetto alle myisam, e le myisam sono meno prestanti delle innoDB a seconda delle situazioni. In generale le innoDB per quel che concerne un gdr-online sono solo un peso, ma su questi livelli come faceva notare cle la questione sulla prestanza degli engine di memorizzazione è molto relativa.

La domanda da porre comunque è una soltanto: hai bisogno della tansazionalità ? Se si vai di InnoDB, semplice ;-)

---

quota

VGP Play

Vi presentiamo VGP Play: una piattaforma di streaming italiana dedicata ai videogiochi e alla tecnologia!

Il Panopticon Ludico

Trattato Sociologico: "Il Panopticon Ludico" Sorveglianza, Potere e Discrezionalità nella Gestione dei GDR

Hell Dawn London

Recensione del gioco di ruolo via chat post-apocalittico Hell Dawn London

Alice in Wonderland

Impariamo a giocare a 3D Evolution e alla slot machine Alice in Wonderland