InnoDB e Drupal 7

5 contenuti / 0 new
Ultimo contenuto
InnoDB e Drupal 7

Ho bisogno di impostare che drupal 7 usi MyIsam e non InnoDB.
Sul mio localhost usa InnoDB perché disponibile, ma sul server in produzione ho è disponibile.

Come faccio a settare MyIsam di default?

Diamo anzitutto una panoramica tra Differenza tra le tabelle di tipo MyISAM e InnoDB.
Il Database Server MySQL dispone di vari tipi di tabelle. Le più usate sono senza dubbio le MyISAM e le InnoDB.

MyISAM

Sono le tabelle "storiche" di MySQL. Hanno fatto il loro successo grazie alle ottime performace e al ridotto carico sul server che necessitano. Purtroppò però mancano di alcune caratteristiche molto importanti nelle basi di dati; primo fra tutte il mancato supporto alle foreign key (chiavi esterne), grazie alle quali è possibile creare relazioni tra tabelle e applicare il concetto di integrità referenziale. Mancano inoltre del supporto alle transazioni. Mancando il supporto alle transazioni e alle foreign keys solitamente non sono adatte per realizzare sistemi di commercio elettronico o altre applicazioni enterprise.

Le tabelle di tipo MyISAM si compongono di 3 file con estensioni .frm, .MYD e .MIY. Il primo file contiene la struttura della tabella, il secondo i dati e il terzo gli indici.

Per trasferire una tabella da una macchina ad un'altra è sufficiente spostare questi 3 file. Il tipo di tabella MyISAM è solitamente quello predefinito nel DBMS.

InnoDB

Sono tabelle molto più complete rispetto alle MyISAM ma si sono fatte la nomina di essere più lente a causa delle funzionalità aggiuntive di cui dispongono. Vorrei fermarmi un attimo proprio su questa questione delle performance: ritengo che al giorno d'oggi la differenza reale di prestazioni tra MyISAM e InnoDB sia divenuta veramente minima.

Tra le caratteristiche a loro vantaggio, invece, vi sono le foreign key e la transazionalità, con le quali è possibile creare una base di dati relazionale e transazionale.

Per trasferire questo tipo di tabelle da un server ad un altro non è sufficiente spostarne i file e questo rende più complicate le procedure di backup. Questo tipo di tabelle, inoltre, non sono sempre disponibili negli hosting economici.

Ecco il codice (assicurati di avere un backup di tutto):
ALTER TABLE `tabella` TYPE=MyIsam

Ok grazie delle dritte.

Ora i DB usano tutti e due MyIsam perché in locale ho importato un db generato sul server di produzione.
Lavorando da locale (che usa InnoDB) vorrei comunque generare eventuali altre tabelle in myIsam, non c'è un file di config che dica a drupal di usare quel motore?

@bonzo: nel file my.conf puoi disabilitare le InnoDB, in questo modo drupal, non trovando queste funzionalità, userà le MyISAM.

@danzisiweb:

Quote:
Sono tabelle molto più complete rispetto alle MyISAM ma si sono fatte la nomina di essere più lente a causa delle funzionalità aggiuntive di cui dispongono. Vorrei fermarmi un attimo proprio su questa questione delle performance: ritengo che al giorno d'oggi la differenza reale di prestazioni tra MyISAM e InnoDB sia divenuta veramente minima.

Purtroppo non sono così d'accordo, purtroppo le tabelle InnoDB sono più lente nelle funzionalità di ricerca pure che non le MyISAM. In alcune tabelle particolarmente stressate da ricerche (con pochissimi inserimenti/update), in cui sono presenti circa 20k entry, su select su chiavi indicizzate, le MyISAM sono circa il 40% più veloci delle InnoDB (caching delle query escluso, essendo ricerche complesse il caching della query di MySQL non comporta vantaggi, anzi!).

Concordo nel fatto che le operazioni di insert & update siano atomiche, non causando il lock dell'intera tabella, rendendo più veloci tante operazioni, ma vanno considerati comunque tutte le possibilità, quindi direi che la scelta di Drupal di passare ad InnoDB è assolutamente ottima, ma in alcune situazioni usare MyISAM è più conveniente (per non parlare delle "possibili" speculazioni legali... ma qui entriamo nel fantamondo delle speculazioni di purezza GPL, quindi meglio lasciar perdere :D )

Ciao
Marco
--
My blog
Working at @agavee

Ok, grazie