Categoria: Database

Database MySQL, 10 trucchi per migliorarne le performance e la stabilità

 sveliamo dei semplici segreti che molti amministratori di database MySQL usano per migliorare le performance delle proprie basi dati.

wordpress_mysql_backup

Il database è la memoria del nostro sito internet o applicativo e ci permette di offrire contenuti dinamici in tempo reale ai nostri utenti.
Ottimizzare il database del proprio sito internet è un’operazione estremamente complessa e condizionata da tante variabili.

Se gestiamo applicazioni o siti che devono supportare numerosi accessi simultanei oppure gestiamo una base di dati che nel tempo ha assunto una elevata complessità (nell’ordine di qualche centinaia di migliaia di righe) è possibile avere un degrado nelle prestazioni, che di solito può essere risolto generalmente ottimizzando il DB.

Quelli che seguiranno sono 10 trucchi che aiutano a migliorare ed ottimizzare le performance di un DB MySQL e/o Percona Server basato su motore InnoDB (praticamente tutti quelli dei maggiori CMS, come WordPress, Moodle, Prestashop, Magento, Joomla, ecc.).

Parametri MySQL da modificare/configurare per un database performante

1.      Configurare il parametro innodb_buffer_pool_size

Il parametro più importante da modificare immediatamente è innodb_buffer_pool_size ed è quello che indica quanta memoria può essere usata per memorizzare in RAM i dati (e quindi evitare accessi al disco continui). Che valore dare dunque al buffer?

Mettiamo che abbiamo un server su cui risiede sia il webserver che Mysql, con 8 giga di ram: dedichiamo a innodb_buffer_pool_size 4GB

Per essere più chiaro e meno ripetitivo faccio una tabella

TIPOLOGIA DI SERVER RAM A DISPOSIZIONE RAM DA DEDICARE
Webserver+mysql 8GB RAM 4GB RAM
Webserver+mysql 16GB RAM 10GB RAM
DBserver dedicato 6GB RAM 5GB RAM
DBserver dedicato 12GB RAM 10GB RAM
DBserver dedicato 24GB RAM 20GB RAM

2.      Configurare il parametro innodb_log_file_size

Questa proprietà definisce la grandezza massima del file di log per tabelle InnoDB. Pur essendo vero che maggiore è la dimensione, migliori sono le prestazioni, è anche vero che bisogna fare i conti con le dimensioni del server. A seconda di tale considerazione si consiglia un tuning di questa variabile tra i 512 e i 4GB.

3.      Configurare il parametro max_connections

Un numero massimo di connessioni disponibili inferiori al numero di connessioni correnti impedirà agli utenti di accedere al database, rendere il vostro sito inaccessibile e / o lenta. Un numero molto elevato di connessioni disponibili per un numero molto basso di connessioni effettive farà server MySQL richiedono più RAM rispetto effettivamente necessario. Il problema di valori troppo alti (oltre i 1000) è il possibile crash del server che si trova a dover gestire contemporaneamente oltre 1000 transazioni attive.

4.      Configurare il parametro innodb_file_per_table

Questa impostazione serve per indicare a MySQL se si vuole conservare i dati e gli indici in un unico tablespace (impostazione su OFF) o in un file IBD separato per ogni tabella (impostazione su ON). Il consiglio è di impostare il parametro su ON (valore di default per MySQL 5.6) soprattutto se si effettuano operazioni di cancellazione e ricostruzione tabelle od operazioni di compressione, che permettono di recuperare spazio. Evitare però di usare l’impostazione su ON qualora si abbia a che fare con un database dal numero di tabelle davvero elevato (oltre 10 mila).

5.      Configurare il parametro innodb_flush_log_at_trx_commit

Se sembra che InnoDB sia più lento di MyISAM è possibile che questo valore sia stato configurato male. Il default (1) significa che ad ogni commit di una transizione (o statement fuori dalla stessa) necessita di fare flush del log su disco, un’operazione piuttosto costosa se molto frequente. Settare il valore a 2 significa fare il flush del log solo tramite cache del sistema operativo. Il valore 0 è più veloce, ma è rischioso perchè si possono perdere dati durante le transizioni nel caso di un crash di MySQL Server. Anche il valore 2 è rischioso se il sistema operativo va in crash.

6.      Configurare il parametro innodb_flush_metod

Sui sistemi Linux e simili (FreeBSD, Solaris…) c’è inoltre il problema di evitare il doppio buffering e per farlo occorre settare la variabile innodb_flush_method a O_DIRECT. Fatelo se vi accorgete che il vostro sistema swappa più del previsto quando il db è sotto stress.

7.      Configurare il parametro innodb_log_buffer_size

Il default per questa variabile è 1MB e per sistemi con poche transazioni ed un traffico medio potrebbe bastare. Non va settato un valore troppo alto perchè è il buffer è flushato ogni secondo ed esagerare significherebbe sprecare memoria. Solitamente sono più che sufficienti 8-16 MB.

8.      Configurare il parametro query_cache_size

Utile per applicazioni con molti dati in lettura. Valori compresi tra i 256 e i 2048 MB sono i migliori, a seconda della potenza della vostra macchina.
Al momento in cui scrivo le considerazioni valgono per MySQL Server 5.5 (io le ho provate su MySQL Server 5.6) e sono comunque suggerimenti da utilizzare con criterio e in base alle possibilità della propria macchina.

9.      Configurare il parametro log_bin

Attivare il logging binario è necessario sia per far funzionare il server come replica di un database server master, sia se sul server (in configurazione singola) si vuole abilitare il sistema di backup automatico. Logga le istruzioni che scrivono dati in formato binario. L’argomento opzionale deve essere il nome del log. Se non è specificato, verrà usato datadir/’log-basename’-bin o ‘datadir’/mysql-bin (il secondo solo se --log-basename non è specificato). Si raccomanda caldamente di usare --log-basename o specificare un nome file per essere sicuri che la replica non si arresti nel caso in cui il nome host del server cambi.

10.  Configurare il parametro skip_name_resolve

MySQL, per i client che si collegano da remoto, mantiene una cache dove memorizza numero IP, nome host ed altre informazioni. Per far ciò il server tenta una risoluzione DNS IP->host name.
Se i DNS interni alla LAN non forniscono un reverse DNS lookup (PTR records) allora è probabile sperimentare un rallentamento nelle connessioni. Infatti MySQL tenterà ogni volta di reinserire nella cache il nome host, processo inevitabilmente destinato a fallire con un timeout.
Per disabilitare il DNS host name lookup è sufficiente far partire MySQL con l’opzione –skip-name-resolve. Basta modificare il file di configurazione my.cnf o my.ini

Miglioriamo le performance di MySQL Server ottimizzando e riparando le tabelle.

MySQL non ha purtroppo  la sana abitudine di ottimizzare le tabelle qualora ve ne sia bisogno.

Per ottimizzazione delle tabelle si intende la riduzione dei byte in eccesso che si vengono a verificare quando un campo di un qualsiasi record viene modificato oppure quando un record viene cancellato.

Ad esempio, se un campo contiene del testo d occupa 100 byte e poi il campo viene modificato ed occuperà 90 byte, c’è il rischio di trovarsi con 10 byte in eccesso.

Stesso discorso quando un record viene cancellato: se la tabella occupa 1000 byte e viene cancellato un record che ne occupa 150, ci troveremo con una tabella di 850 byte col rischio di averne 150 in eccesso.

MySQL mette a disposizione l’istruzione OPTIMIZE TABLE il cui compito è quello, appunto di ottimizzare la tabella e compattare i dati.

Per far ciò basta usare lo strumento Mysqlcheck, in questo modo:

mysqlcheck –u root –p —auto–repair –c –o nomedatabase

Utilizzare professionalmente in ambito web un RDBMS come MySQL o PostgreSQL garantendo l’integrità dei dati, migliorandone le performance e la sicurezza.

databaseTra le cose che più destano indignazione nel mio lavoro, è quello di vedere colleghi o sedicenti tali, fare un uso delle tecnologie in modo errato, non avendo a cuore la lungimiranza e gli eventuali problemi che potrebbero verificarsi da li a poco.
Tra tutte le regole che ho imparato in 10 anni di lavoro ed altrettanti di studio è che prevenire è meglio che curare, e che con gli attrezzi giusti sei già a metà dell’opera.

Oggi voglio parlare di tutti quei web developer, che per scelta o causa di forza maggiore decidono di occuparsi anche della progettazione della base di dati su cui poi andrà a girare l’applicazione web scritta con un linguaggio server side, (PHP, Ruby, Python, ASP, ecc.)

Quello che trovo nella maggior parte dei casi quando non c’è un DBE (Database Engineer) a svolgere il delicato ruolo di progettare la base di dati, è  un progetto inconsistente, non performante e lacunoso sotto tutti i punti di vista.

Ciò potrebbe anche “andar bene” qualora gli effetti nefasti di una cattiva progettazione non mettano a rischio l’integrità dei dati e la coerenza del database stesso, o nei casi in cui l’integrità dei dati e la coerenza non siano uno dei requisiti fondamentali da tener presente in fase di progettazione.

Vuoi perchè sia un blogghettino personale, vuoi perchè i dati trattati non hanno un valore tale da giustificare un’accurata pianificazione e progettazione dello stesso.

Non è invece possibile vedere progetti campati per aria quando si ha a che fare con software seri che gestiscono informazioni riservate o dati fiscali e finanziari, in cui l’integrità e la consistenza della base di dati è fondamentale.

Anche un “banale” e-commerce dovrebbe rispondere a questi requisiti.

La realtà è fatta invece di dilettanti che usano i potentissimi RDBMS, (normalmente in ambito LAMP MySQL) limitandosi all’utilizzo più banale che se ne possa fare : un semplice “archivio con tanti cassetti” in cui fare INSERT, SELECT, UPDATE, e DELETE tramite l’applicazione web che ci gira sopra.

Funzionalità come Viste, Stored Procedure, integrità referenziale, Trigger, Transazioni, Indici , vengono prettamente ignorate.

Se una persona competente decidesse di eliminare la casa automobilistica FIAT dal database veicoli a cui è referenziata la tabella modelli:

FIAT

– Panda
– Punto
– Palio
– Siena
– Brava

Avrebbe solo l’accortezza in fase di progettazione di settare il vincolo ON DELETE CASCADE, sulla relazione Casa<-Modelli.
Questo vincolo impartisce l’ordine di cancellare i record referenziati alla cancellazione della chiave primaria esterna a cui è stata referenziata.

Un dilettante invece dovrebbe scorrere tutta la tabella modelli, cancellare tutti gli elementi con una DELETE FROM Modelli WHERE casa like “FIAT”; e solo successivamente salire al “nodo padre” e cancellare definiticamente la casa automobilistica con un DELETE FROM Casa WHERE nomecasa LIKE “FIAT”;

Cosa succede poi quando un DB genera un errore ?

Vuoi che sia generato a livello applicativo da un codice scritto male, vuoi che vada via l’energia elettrica, la rete, o si rompa l’alimentatore ?

Mettiamo l’ipotesi banale in cui due utenti della stessa banca, decidano di farsi un bonifico tra loro : Tizio bonifica 1000 euro a Caio.

Tizio fa click col mouse, il sistema riceve il dato, toglie 1000 euro a Tizio e … BUM (scoppia l’alimentatore del server).

Arriva il tecnico, ripara l’alimentatore, riavvia il sistema e ci troviamo nella condizione in cui Tizio ha 1000 euro in meno sul suo conto, Caio non ha 1000 euro in più, in quanto l’operazione di accredito non è andata a buon fine perchè appena prima l’alimentatore si è rotto.

In queste situazioni un progettista serio avrebbe dovuto usare una TRANSAZIONE ACID, ovvero una metodologia per eseguire un gruppo di query, in cui o le si eseguono TUTTE, o si ripristina il DB allo stato iniziale, prima dell’esecuzione del gruppo di query.

Nel caso avesse usato una transazione, al riavvio del sistema, il DBMS avrebbe letto i log e accorgendosi che era stata eseguita solo una parte delle query, avrebbe eseguito il ROLLBACK e ritornato nelle condizioni iniziali prima del bonifico.

Questi esempi sono volutamente banali in quanto rivolti appunto a coloro che approcciano al mondo dei DB, senza avere padronanza di concetti basilari come modello E/R, normalizzazione e peculiarità di DBMS Relazionali avanzati come possono essere MySQL, PostgreSQL, Oracle, SQL Server o altri.

La pigrizia spesso genera quella falsa illusione di fare bene le cose, ignorando funzionalità che permettono di farle in maniera molto più facile e sopratutto sicura.

Approcciare ad una sana lettura sulle potenzialità del motore InnoDB, e le relative differenze con MyISAM, per chi si approccia alla progettazione di una base di dati su MySQL è il primo passo.

Ottimizzare le performance di un sito web. Alcuni passi fondamentali per gestire siti con migliaia di visite al secondo

ottimizzazione-siti-webQuando si ha a che fare con un sito web con moltissime visite, prima o poi si dovrà fare i conti con le risorse insufficienti, l’inefficienza del sito e col portafogli.

Col portafogli perchè se continuerete ad avere un sito lento, non venderete; ma anche perchè per aumentare le performance probabilmente vi venderanno servizi cloud e servizi di hosting da svariate migliaia di euro al mese.

Questo è infatti il modo di ragionare puramente commerciale e per niente etico di molti fornitori di hosting.

Nella maggior parte dei casi invece sarebbe bastato solo rivolgersi alle persone giuste per fare un tuning intelligente del sistema, sostituire eventuali servizi con equivalenti più efficienti e mettere in piedi tecniche per massimizzare le performance e minimizzare i costi.

Verosimilmente in alcuni casi potremmo dimezzare i costi o addirittura decimare, aumentando le prestazioni in quei casi particolarissimi in cui realmente serve avere il massimo dell’efficienza.

Tra gli esempi di alcuni casi potrebbero essere portali giornalistici, community online, blog, o altri siti generici che hanno molte visite concorrenti e che richiedono funzionalità di lettura/scrittura verso il database ed hanno un interprete lato server come PHP.

Siti del tipo “Il fatto quotidiano” o la community su android “Tuttoandroid“.

Come gestire tutti quegli utenti in contemporanea ? Come dimensionare l’hardware ? Come settare il database per avere il massimo delle performance ? Quale webserver usare ? Come configurare l’interprete PHP ?

Per rispondere a queste domande bisogna avere una approfondita conoscenza sistemistica, conoscere i pro e i contro delle varie soluzioni disponibili e mettere in piedi un ambiente ottimale per dare il massimo dell’efficienza. In poche parole : Ottimizzare.

Brevemente possiamo dire che nell’ottica di gestire una mole elevatissima di utenti concorrenti bisogna scordarsi di implementare le soluzioni standard che il mercato offre in ambiente hosting.

In primis va scelto un hosting dedicato e non condiviso. Un server dedicato ben dimensionato con connettività possibilmente europea se si vuol rimanere contenuti nei costi.

Uno Xeon Quad core con 32 Giga di RAM e 3 terabyte di dati, 100 Mbit di banda normalmente lo si può trovare a meno di 80 euro / Mese.

Il webserver che normalmente viene configurato in questi casi è NGINX che offre (a differenza di Apache) di servire rapidamente i contenuti statici con un utilizzo efficiente delle risorse di sistema. È possibile distribuire contenuti dinamici HTTP su una rete che utilizza i gestori FastCGI per gli script, e può servire come un bilanciatore di carico software molto capace.

Ad esso dovrà essere abbinato PHP-FPM.

PHP-FPM è una derivazione di Php Fastcgi molto interessante, che apporta modifiche ed un nuovo modello di utilizzo al progetto originario. Incluso ultimamente nella release di Php 5.3.3, PHP-FPM rappresenta una tecnologia abbastanza matura da poter essere utilizzata in ambienti di un certo calibro. PHP-FPM ha la capacità di avviare pool multipli di processi Fastcgi in ascolto su porte separate per soddisfare le richieste su ambienti di hosting virtuale multidominio, anche se il modello di progettazione principale non consiglia utilizzi orientati all’hosting multiplo. PHP-FPM è stato principalmente pensato per siti web oberati da numerose richieste HTTP ed è dunque molto indicato per ambienti mono sito, con web server come Nginx e Lighttpd.

Il database se MySQL dovrà essere configurato in maniera adeguata in modo di gestire al meglio l’allocazione delle risorse come la cache delle query, i thread concorrenti, i vari engine di storage (MyISAM e InnoDB in primis), ecc…
Non basterebbe un libro intero sul tuning di MySQL, ma vi basti sapere che il settaggio può fare il buono e il cattivo tempo.

Se utilizzate CMS che lo permettono (o applicazioni da voi scritte appositamente) potrete affiancare a questa potentissima ricetta MEMCACHED.

Memcached aumenta le prestazioni e la scalabilità di siti web dinamici con tecnologia MySQL attraverso un caching dei dati e degli oggetti nella memoria per minimizzare il carico del database. I più grandi nomi del web, come YouTube, Facebook, Fotolog e Wikipedia utilizzano Memcached e MySQL per soddisfare le esigenze di milioni di utenti e di miliardi di visualizzazioni delle pagine ogni mese.

A livello WEB invece molti CMS (Drupal, Joomla, WordPress, ecc…) permettono l’implementazione di appositi moduli per effettuare il caching dei contenuti, ovvero far in modo di ridurre sensibilmente la generazione di pagine dinamicamente tramite PHP e MySQL e dunque far in modo di servire contenuti statici.

A questo potrebbe essere utile implementare e configurare servizi CDN specifici per distribuire le risorse e rendere più efficace il tutto.
I nodi CDN sono geograficamente distribuiti, spesso connessi a diverse dorsali; questi nodi collaborano vicendevolmente per soddisfare le richieste di contenuti, trasferendoli in maniera trasparente al fine di ottimizzarne il processo di consegna: un sistema centralizzato con unico server centrale non sarebbe in grado di soddisfare le molteplici richieste di servizio da parte di numerosi utenti. Le ottimizzazioni possono portare come vantaggi la riduzione dei costi per l’ampiezza di banda, o il miglioramento delle prestazioni, o entrambi.

Per gestire forum con centinaia di migliaia di iscritti invece, bisogna affidarsi alla soluzione commerciale di punta (peraltro molto economica), ovvero Vbulletin. Molto malleabile ed estremamente ricco di funzionalità, eccelle per la sua indiscussa velocità.

Abbiamo visto fino a qui alcuni dei passi principali per mettere online un sito rivolto a centinaia di migliaia di utenti, sicuramente non tutti, e non discussi approfonditamente.

Si potrebbe parlare di APC, di database NOSQL come MongoDB, Redis, ecc… di Web Accelerator come Varnish, o di un sacco di altre cose che sapientemente installate e configurate possano portare a risultati a dir poco sorprendenti.

Se pensi che il tuo sito Web abbia bisogno di dare il massimo in termini di velocità, o se credi di spendere troppo per la tua soluzione hosting o server dedicato attuale non ottimizzato e vuoi risparmiare oltre 2 terzi del canone mensile, siamo sicuramente la soluzione ai tuoi problemi.

Con un’analisi iniziale gratuita possiamo farti la nostra migliore offerta per avere il massimo delle performance al minor costo.

Contattaci per un preventivo gratuito

Backup remoto di un database MySQL su FTP con lftp e gzip per Windows.

Se avete mai avuto la necessità di fare un semplice backup di un DB MySQL e avete cercato in rete una soluzione facile ed efficace avrete sicuramente notato la mole inaudita di soluzioni più o meno professionali e potenti (dal costosissimo MySQL Enterprise Backup all’altrettanto valido, migliore, open source e gratuito XtraBackup della Percona) ma sopratutto infiniti script più o meno elaborati che facendo uso del semplice mysqldump permettono un backup (magari in rete).
Solitamente però sono fatti scritti in shell scripting (bash, sh, csh) o in linguaggi tipo Perl o Python che fanno uso dei comandi di sistema per ovviare le operazioni elementari che un backup richiede.
Difficilmente (in verità mai, ecco perchè ho scritto questo articolo) si trovano script funzionanti in ambiente Windows che permettano un uso immediato, semplice e malleabile come su ambienti Linux.

Lo spunto di questo articolo nasce dunque da un caso reale, e più precisamente la necessità di effettuare un backup remoto di un DB MySQL di uno studio personal training per salvaguardare i dati da eventuali rotture hardware, perdite dati, furti.

Lo script fa uso di 2 comandi originariamente Linux ricompilati e portati su Windows.

  • gzip (per la compressione del DB)
  • lftp (per il trasferimento e la sincronizzazione del backup generato su un server FTP)

 

il tutto viene invocato da uno script batch (.bat) che esegue il dump del DB (che fa uso di tabelle innodb, stored procedure, funzioni, viste) tramite l’invocazione di mysqldump (dell’installazione mysql originale già presente sul sistema) con l’opzione –routines che permette di fare il dump non solo dello schema e dei dati ma anche delle stored procedure, funzioni, trigger che sono elementi vitali del DB stesso.

Piu specificamente ecco l’intero script:

@echo off
 
set hour=%time:~0,2%
if "%hour:~0,1%" == " " set hour=0%hour:~1,1%
set dt=%DATE:~-4%-%DATE:~3,2%-%DATE:~0,2%_%hour%%time:~3,2%
cls
 
echo -------------------------------------------------------------------------
echo Backup del Database in corso.
echo.
echo Per favore non chiudere questa finestra e non usare il gestionale.
echo.
echo -------------------------------------------------------------------------
echo.
 
c:\xampp\mysql\bin\mysqldump -uNOMEUTENTE -pPASSWORD --opt --routines nomedatabase | gzip.exe &gt; c:\backup\sql\nomedatabase-%dt%.sql.gz
echo Trasferimento del backup remoto in corso ...
 
c:\backup\lftp -f /backup/copiaremota.lftp

Lo script di per se è molto semplice e nel dettaglio si comporta nel seguente modo :

  1. Crea una variabile hour a cui è associata l’ora del sistema
  2. Crea una variabile dt a cui è associata la data e l’ora del sistema
  3. invoca mysqldump (dal percorso dove è installato mysql) specificando username e password e il nome del database da salvare, passando l’output tramite pipe a gzip.exe che genera un file di tipo .gz sotto la cartella c:\backup\sql
  4.  viene invocato lftp che ha come parametro copiaremota.lftp

 

copiaremota.lftp è il file contenente le direttive da “dare in pasto” a lftp.exe

set ftp:ssl-allow no
open -u nomeutenteftp,passwordftp ftp.hostremoto.it
mirror -R --only-newer --verbose /backup/sql /
quit

Basterà dunque modificare username e password e il nome dell’host remoto per il server ftp nel file copiaremota.lftp per adattarlo al proprio contesto.

Esso una volta processato da lftp.exe farà il mirror dei file nuovi dalla cartella c:\backup\sql alla root directory del server ftp in questo caso /

NOTA BENE : dato che lftp è conforme allo standard POSIX di unix, pur lavorando in ambiente windows, la cartella c:\backup\sql diverrà nel file di configurazione .lftp /backup/sql

Per far funzionare il tutto dunque, scompattare l’allegato che troverete alla fine di questo articolo in c:\backup, modificare il file backup.bat con il path corretto di mysqldump, nome utente e password mysql e nome del database.

Successivamente modificate il file copiaremota.lftp inserendo la configurazione corretta del vostro server ftp.

Lo script rimane dunque molto semplice e funzionale per il backup schedulato di DB MySQL di tipo MyISAM o InnoDB. Sicuramente non è la soluzione ideali per ambienti mission critical che richiedono l’integrità e la continuità in produzione su cui consiglio soluzioni di replica Master/Slave e backup a caldo con  XtraBackup, ma è una possibile soluzione per database di “semplici” gestionali.

In accoppiata con la schedulazione di Windows (ovvero Operazioni Pianificate) può diventare veramente di grossa utilità. In fondo basta solo lanciare backup.bat per avere una copia remota in maniera del tutto automatica.

Aruba Hosting : Low Costing e MySQL senza InnoDB. Non è tutt’oro quel che luccica.

Normalmente non ci piace parlare dei nostri concorrenti (in questo caso oltretutto ci sentiamo come Davide contro Golia in termini di numeri) ma crediamo sia più che lecito parlarne quando oltre ad essere competiror sono anche fornitori dei nostri clienti e indirettamente dunque ci troviamo nelle vesti di clienti o meglio utilizzatori “costretti” ad utilizzare i loro servizi.

E’ bene infatti chiarire che sebbene forniamo noi stessi servizi di hosting Linux (LAMP) e server dedicati, ci occupiamo di gestire tramite servizi managed server VPS o dedicati presso altre server farm, (tra cui Aruba) e di aiutare clienti nella configurazione e installazione di software Web (solitamente che si basa su PHP e MySQL) sui loro pacchetti Hosting Linux.

Se avessimo voluto parlarne male, l’opportunità andava colta qualche settimana fa quando ci fu quel guasto elettrico divampato poi in incendio che mise down l’intero datacenter e i milioni di domini che essa ospita.

Non l’abbiamo fatto. L’imprevisto è dietro l’angolo, chi conosce Murphy lo sa fin troppo bene.  Sciagure di questo tipo sono successe a BIG mondiali come ThePlanet e piccolini come il nostrano Tophost.
La gestione dell’incidente e il ripristino dei servizi è stato a nostro avviso eccelso.

Nulla da eccepire nemmeno nell’assistenza (in particolar modo quella dei server dedicati) che comunque è repentina e gestita da personale tecnico (non le centraliniste) preparato.

Vanno invece fatte delle considerazioni sui loro spazi WebHosting, sulle feature che offrono e sul rapporto qualità/prezzo per un servizio professionale e completo dalla A alla Z.

Innanzitutto è bene precisare che Aruba punta molto del suo successo sull’offerta di spazio disco illimitato. In realtà lo spazio illimitato è un’utopia o meglio un sofismo utile ad aumentare la potenza commerciale di Aruba suscitando false sicurezza nell’utente.

Lo spazio illimitato non esiste ed ovviamente non può esistere come concetto informatico.

Al prezzo base infatti una 20ina di euro + IVA comprerete il fantomatico spazio illimitato, ma se volete dei servizi aggiuntivi ?

  • Le statistiche professionali ad esempio costano 12.91 + IVA l’anno. Se si fa web seriamente non si può far a meno di un servizio di statistiche utili al fine del webmarketing ma non solo.
  • L’antivirus e l’antispam è fondamentale, evita noie e pericoli informatici ed ha un costo tutto sommato accettabile e proporzionato, “solo” 2 euro l’anno + IVA.
  • Il servizio IMAP consente di poter configurare le proprie caselle di posta sfruttando il protocollo IMAP4 in alternativa a quello POP3. A differenza del protocollo POP3, con quello IMAP4 sono possibili più connessioni contemporanee allo stesso account di posta, con l’opportunità di controllare i cambiamenti apportati da ogni utente che si collega. Anche questa opzione è a pagamento a 2 euro l’anno più iva.
  • Il servizio Backup anch’esso obbligatorio per un utilizzo professionale e non vogliate correre il rischio di perdere tutto per colpa di accessi abusivi o guasti hardware. Attivabile ad un costo di 2 euro + iva l’anno.
  • Abilitare domini di terzo livello, del tipo terzolivello.dominioprincipale.it ha un costo annuale di 5 euro più IVA.

 

Fin qui tutto “bene” insomma, il concetto esposto e chiaramente percepito è che i servizi aggiuntivi sono al di fuori dell’offerta iniziale e vanno ordinati e pagati a parte. Politica aziendale del tutto legittima ed a nostro avviso anche onesta se confrontate con ipotetiche offerte di diretti concorrenti.

L’assurdità però avviene con il seguente servizio : il Database ! Ovvero MySQL 5.

Come riportato dal loro sito http://hosting.aruba.it/servizi_aggiuntivi.asp “Aruba.it ha attivato fra le proprie offerte anche il supporto a MySql: tecnicamente si tratta di un DBMS (Database Management System) ovvero, un sistema di gestione per Database, in pratica è un Database veloce e di grandi prestazioni, che consente la creazione di siti web dinamici con backend MySql. Con il servizio MySQL è possibile disporre di un massimo di 5 database e di uno spazio su disco complessivo di 100Mb. Il servizio è utilizzabile solo da domini ospitati dai nostri servizi hosting o Serverdedicati. Lo spazio su disco e’ incrementabile con pacchetti aggiuntivi da 100Mb l’uno. Il linguaggio di interazione predefinito è il PHP, ma è possibile, grazie alla presenza dei driver MyODBC, interagirvi anche tramite pagine ASP.”

Ciò che omettono di dire a riguardo è che sebbeno forniscano il servizio a 7 euro + IVA l’anno (a cui aggiungono il servizio opzionale di backup MySQL ad ulteriori 3 euro + IVA l’anno) non forniscono lo storage engine InnoDB o qualsiasi altro engine transazionale (vedi ad esempio XtraDB) che fanno di MySQL un vero DBMS relazionale e non un semplice giocattolino per appoggiare i dati.

Come riportato dalla loro Knowledge Base all’indirizzo http://ticket.aruba.it/KB/a244/utilizzo-di-tabelle-innodb.aspx “Il servizio MySql offerto non prevede il supporto per tabelle di tipo InnoDB.“.

E’ incredibile (nel senso più etimologico della parola stessa) che non forniscano (e sopratutto non lo dichiarino in fase d’ordine) un motore transazionale così potente e affidabile come InnoDB che è alla base di molti software web open source come ad esempio tra i più famosi : Magento, Druapl 7, Docebo, ecc…

Ogni software serio che si rispetti che sia sviluppato da ingegneri e non da peracottari che soddisfi le condizioni A.C.I.D, acronimo inglese Atomicity, Consistency, Isolation, e Durability (Atomicità, Coerenza, Isolamento e Durabilità), deve necessariamente usare un engine di tipo transazionale come ad esempio InnoDB per evitare tutte una serie di problematiche di difficile e ardua risoluzione da un punto di vista
applicativo che sarebbero risolvibili automaticamente tramite l’utilizzo delle chiavi esterne (foreign Key), e funzionalità avanzate come Transazioni, Stored Procedure, Stored Function, Trigger che sono disponibili esclusivamente su MySQL esclusivamente tramite  InnoDB o XtraDB ma sono assolutamente assenti nel vecchio giocattolino MyISAM, l’unico per ora disponibile sui piani hosting offerti da Aruba.

Se è vero che ogni azienda ha la libertà di vendere e commercializzare ciò che vuole, è anche vero che il cliente ha il DIRITTO di sapere in fase d’ordine che il loro “Database veloce e di grandi prestazioni” viene azzoppato e privato di importantissime funzionalità magari vitali per l’utilizzo futuro del cliente.

Un po’ come se un concessionario vi vendesse una bellissima e luccicante Ferrari e omettesse (volutamente ?) di dirvi che nel suo bel motore da 350 Km/h è stato applicato un limitatore che non vi fa andare oltre i 100 Km/h ?

Voi come ci rimarreste ?


 

Oracle is Evil ? Storia di un commento su Facebook : censura e considerazioni personali.

Oracle non ci piace. Non ci è mai piaciuta.
Non che non ci piacciano i loro prodotti (per cui forniamo assistenza e sviluppo), ma non ci piace il loro modo di far business.

Un’azienda di vecchio stampo, ricca e senza scrupoli che mira solo ed esclusivamente ai profitti fregandosene di concetti etici e community nate con l’avvento dell’Open Source.

Sarebbe da aprire un dibattito sull’acquisizione di Sun Microsystem e delle scelte adottate nei confronti dei prodotti Sun, un’azienda innovatrice che ha saputo stare sul mercato ai massimi livelli in simbiosi con la comunità Open Source.
Sarebbe appunto, ma non lo facciamo perchè non basterebbero migliaia di righe per approfondire l’argomento, per cui ci limiteremo solo a porre le seguenti domande :

  • A Oracle interessava veramente un DBMS nettamente inferiore al suo (MySQL), una suite da ufficio gratuita (OpenOffice), un linguaggio ormai in declino se non fosse usato da google su android (Java) ?
  • Ha veramente senso citare in tribunale Google per il codice Java integrato nella piattaforma Android ?

O ha acquistato Sun con l’unico scopo di fare da patent troll ?

Ognuno si faccia pure la propria idea in merito. A buoni intenditor poche parole.

Vale invece la pena spendere qualche parola, o meglio qualche riga, sulla vicenda di ieri 9 Maggio nella pagina Fan Ufficiale di Oracle http://www.facebook.com/Oracle, al commento del post giallo evidenziato in basso.

All’invito ad iscriversi alla Newsletter di Oracle Unbreakable Linux infatti, commento testualmente “Oracle use Redhat package. Oracle is Evil.”
Ne ricavo un ban dalla loro pagina ufficiale a cui mi riscrivo stamane cliccando mi piace, ma come si vede dallo screenshot precedente, non ho più la possibilità di commentare i loro post.

Cos’è stato detto di male ? Che Oracle a suo modo sfrutta i sorgenti di Redhat per trarne profitti ? Anche CentOS lo fa ma almeno lo fa a livello community e in modo etico e responsabile.
O forse Big Oracle si è “stranita” a causa dell’affermazione Oracle is Evil ?

E’ strano che al giorno d’oggi tutti puntano il dito contro Microsoft, Google, Facebook e nessuno se non pochi addetti ai lavori si rendano conto dei danni alla comunità che un’azienda come Oracle POTREBBE fare con la loro business strategy, avendo in mano prodotti tecnologici di rilevanza utilizzati in molteplici contesti e nella vita di tutti i giorni. (basti pensare MySQL e Java per fare un esempio).

E’ in questi casi che bisogna lodare Stallman e la sua licenza GPL alla base di moltissimi prodotti che Oracle dispone dopo l’acquisto di Sun, che permette fork di progetti vitali onde evitare il predominio di aziende sfacciate che non hanno scrupoli a far morire prodotti validi e di pubblica utilità solo per rimanere leader sul mercato.

PostgreSQL è ormai come Oracle 11g con le nuove funzionalità di replica in streaming e Hot Standby.

PostgreSQL più comunemente chiamato Postgres è giunta alla versione 9.0 lo scorso 20 Settembre.
Sarebbe complesso presentare PostgreSQL ad un neofita, ma vi basti sapere che è un DBMS SQL di classe Enterprise con efficienza, feature, stabilità che competono con rivali commerciali del calibro di MS SQL Server, DB2 (IBM) ed infine il mostro sacro Oracle.

Non è stato citato MySQL perchè effettivamente PostgreSQL è un prodotto di lunga superiore per essere impiegato in ambiti di produzione mission critical, con feature native consolidate dagli anni quando MySQL non aveva nulla di relazionale non supportando fino a qualche anno fa nemmeno l’integrità referenziale, le viste, le stored procedure e tutt’ora rimane impacciato con i trigger.

Dopo questa breve ma doverosa premessa si può affermare che ad oggi la nuova release 9.0 è pressoché pari in termini di funzionalità a Oracle 11g.

A dirlo è 2ndQuadrant, azienda leader di consulenza PostgreSQL.

Simon Riggs, CTO e fondatore di 2ndQuadrant, ritiene che sia la replica in streaming che Hot Standby, implementate come funzionalità interne al database,  costituiranno per le aziende un incentivo a migrare da costosi database proprietari, quale ad esempio Oracle che ha costi di licenza di decine di migliaia di euro per singolo singolo core.

Ciò è estremamente positivo dato che l’inclusione della replica nel core di Postgres era una delle feature più richieste dai clienti.
Fino ad ora ciò era possibile tramite modularità esterne, a discapito del senso di gradimento degli utenti finali che vogliono sempre qualcosa di integrato che funzioni bene, sempre e subito.

Sempre più filo da torcere a Oracle dunque che pur essendo l’azienda leader nel campo DBMS si trova sempre più minacciata da soluzioni Open Source quali MySQL (che ha recentemente acquistato insieme a SUN) ma sopratutto PostgreSQL definito all’unanimità “Il più avanzato database open source”.

A prova di ciò e del terrore (e dunque della validità e della bontà) che PostgreSQL incute a Oracle non si può assolutamente omettere l’increscioso evento avvenuto a fine luglio 2010, appena dopo l’acquisizione di Sun Microsystem che ha visto spegnere i server utilizzati da Postgres per testare le nuove patch su Solaris e OpenSolaris.

Sun infatti contribuiva a PostgreSQL mettendo a disposizione gratuitamente delle macchine, ma Oracle le ha spente senza nessun preavviso e senza commentare l’accaduto.

Comportamento sicuramente legittimo “affaristicamente parlando” ma da condannare da un punto di vista etico ed umano.