Scegliere un hosting per Magento

[Redazione HostingTalk]

Parlare di Magento vuol dire parla di Commercio Elettronico. Quindi, prima di avventurarsi nell'analisi di Magento e delle soluzioni di Hosting Magento è bene spendere qualche parola su questo nuovo e promettente settore dell'Information Technology.

Cos'è il Commercio Elettronico di cui tanto si parla? E' quella forma di commercio, denominata anche E-Commerce, che si avvale di un sito web per realizzare una transazione economica. In pratica un sito web diventa non solo il luogo "virtuale" con cui comunicare col mondo ma anche una vera e propria piattaforma di vendita tramite la quale un qualsiasi esercizio commerciale può "piazzare" i propri prodotti.



Leggi il contenuto dell'articolo Scegliere un hosting per Magento

[HostingVirtuale]

Il problema (se così si può definire) di Magento è che il database MySql deve essere configurato con supporto allo Storage Engine InnoDB che non tutti i provider offrono.

[xAnder]

Basterebbe informarsi prima dell'acquisto

[Shazan]

Il problema (se così si può definire) di Magento è che il database MySql deve essere configurato con supporto allo Storage Engine InnoDB che non tutti i provider offrono.

InnoDB è di default attivo su MySQL, c'è ancora qualcuno che perde tempo a disabilitarlo...? Se sì, a che pro...?

[xAnder]

Non dovrebbe migliorare le prestazioni del database?

[2busy]

Cosa? MyISAM o altri engine?!?

[xAnder]

2busy, mi riferivo a mettere nella configurazione del server mysql "skip-innodb"

[guest]

InnoDB è di default attivo su MySQL, c'è ancora qualcuno che perde tempo a disabilitarlo...? Se sì, a che pro...?

Una enorme pecca di InnoDB è la frammentazione delle tabelle.
Butta tutto in un file (di default) ed a quanto pare, non lo svuota nemmeno se elimini i record.

Mi son ritrovato su un server di monitoraggio con ben 8GB di file innodb. Ho svuotato l'intero database ed il file è rimasto 8GB.

Soluzione: dump, cancellazione brutale del file, ed import.

[Shazan]

Che io sappia, il file di tablespace non si rimpicciolisce dopo che elimini i dati ma al suo interno lo spazio può essere riutilizzato per altri dati, quindi non è spreco.

Rispetto ai vantaggi che InnoDB comporta, disattivarlo secondo me non ha senso.

[guest]

Che io sappia, il file di tablespace non si rimpicciolisce dopo che elimini i dati ma al suo interno lo spazio può essere riutilizzato per altri dati, quindi non è spreco.

Non saprei, però su piccole VPS, avere un file così grosso, come nel mio caso, potrebbe essere un problema perchè ti porterebbe a viaggiare sempre con il disco pieno.

Io avevo la VPS con 8GB di disco mysql, di cui 7.9 erano occupati da innodb per un solo database. Non è spreco, ma tutti gli altri database che usano MyISAM non riuscivano più a scrivere causa disco pieno.

Rispetto ai vantaggi che InnoDB comporta, disattivarlo secondo me non ha senso.

No, non ha senso, ma dipende dove lo vai a piazzare.
Forse su shared hosting, dove hai il 95% dei clienti che usano MyISAM, avere una manciata di database InnoDB che ti possono mettere fuori uso anche tutti gli altri per via dello spazio, potrebbe essere problematico.

Immagina uno script fatto male, impazzito, che salva milioni e milioni di record su un database InnoDB. Prima che il cliente se ne accorga e faccia il fax (sempre che se ne accorga) tu ti ritroveresti con un database bello ciccione e magari in piena notte ti fa andare ko anche gli altri db perchè ha riempito il disco. Il cliente se ne accorge, elimina i dati impazziti ma tu resti con il disco pieno.

[Shazan]

Puoi impostare tu la dimensione del file e stabilire che non possa autoespandersi.

[AndDM]

Dai miei piccoli test lo skip-innodb toglie quasi la metà della ram in uso. Penso possa essere utile disattivarlo nel caso di risorse limitate e se si utilizzassero applicativi che ne possano fare a meno.
Nel caso di servizi generici penso che il gioco non valga la candela.

[usu]

Poteva effettivamente avere poco senso usare InnoDB prima del plugin innodb dato che le prestazioni erano veramente scandalose, ma da quello in poi (e soprattutto con MySQL 5.5) comincia avere poco senso usare MyISAM (non per niente InnoDB è diventato lo storage engine di default )
Per quanto riguarda il problema dello spazio, la cosa si risolve parzialmente con l'opzione innodb_file_per_table che mette tutte le varie tabelle in file separati (tipo MyISAM) e al massimo basta distruggere e ricreare una tabella invece che i DB.

Attenzione che non basta aggiungere innodb_file_per_table a my.cnf per avere la nuova gestione dei file innodb, ma bisogna backuppare il db, cancellare tutte le tabelle e i file ibdata* e log* (meglio spostarli, in caso qualcosa vada storto), inserire innodb_file_per_table in my.cnf e infine importare il backup.

[guest]

Per quanto riguarda il problema dello spazio, la cosa si risolve parzialmente con l'opzione innodb_file_per_table che mette tutte le varie tabelle in file separati (tipo MyISAM) e al massimo basta distruggere e ricreare una tabella invece che i DB.

Il problema non è avere un singolo file o 50 file distinti, bensì l'impossibilità di ridurlo di dimensione.

Non puoi dire ad un cliente di fare backup e restore delle sue tabelle di tanto in tanto per ottimizzare il db.
E questo su shared hosting può essere problematico.

Inoltre, come vien calcolata la dimensione di una tabella? vien fatto il calcolo sui dati effettivamente presenti o sulle dimensioni dei file? In quest'ultimo caso, chi usa innodb, si ritroverebbe entro breve fuori quota database.

[Shazan]

La dimensione di una tabella viene calcolata sui dati effettivamente presenti. Il file è solo una specie di partizione virtuale, un contenitore.

Se usi la soluzione suggerita da Usu, quella dei file distinti, quando elimini una tabella il file rimpicciolisce.