Aria FAQ

Questa FAQ spiega cosa aspettarsi dallo Storage Engine Aria (nel testo chiamato semplicemente 'Aria'). MariaDB, il fork di MySQL che include Aria, è illustrato nella sua pagina dedicata.

Cosa è Aria?

Aria è un nuovo Storage Engine per MySQL® e MariaDB, sviluppato con l'obiettivo di creare uno Storage Engine di default che sia transazionale E non-transazionale.

E' in sviluppo dal 2007 ed è stato annunciato nel blog di Monty.

E' sviluppato dagli ingegneri principali di MySQL, che hanno sviluppato il server MySQL e gli Storage Engine MyISAM, MERGE e MEMORY.

Perché si chiama Aria?

Lo Storage Engine inizialmente si chiamava Maria, come la figlia più giovane di Monty. Monty ha chiamato MySQL come la sua prima figlia My. Il suo secondo figlio, Max, ha dato il suo nome a MaxDB e alle distribuzioni MySQL-Max.

Poiché il server di database MariaDB e lo Storage Engine Maria venivano confusi, è stato deciso di cambiare il nome. Si è tenuto un contest chiamato Rename Maria durante la prima metà del 2010 e vari nomi sono stati proposti da tutto il mondo. Monty ha scelto Aria da una breve lista di finalisti. La persona che lo ha suggerito, Chris Tooley, ha ricevuto in premio un System 76 Meerkat NetTop con Linux da Monty Program. Ulteriori informazioni sul contest sono disponibili alla paina Rename Maria.

Qual è l'obiettivo di Aria 1.5 (versione attuale)?

Costituire un'alternativa crash-safe a MyISAM. Ossia, quando mysqld si riavvia dopo un crash, Aria riporta tutte le tabelle allo stato in cui si trovavano all'inizio di un'istruzione o all'inizio del precedente LOCK TABLES.

L'obiettivo attuale è mantenerla stabile e correggere tutti i bug che sono stati trovati.

Qual è l'obiettivo di Aria 2.0 (prossima versione)?

Uno Storage Engine pienamente transazionale che abbia almeno tutte le funzionalità principali di InnoDB.

Al momento Aria 2.0 è in attesa, perché gli sviluppatori stanno dedicando le loro energie ai miglioramenti di MariaDB. Tuttavia sono interessati a lavorare con clienti e partner per aggiungere ulteriori funzionalità ad Aria e terminare Aria 2.0.

L'obiettivo è meglio definito nel WorkLog di Aria 2.0. Cliccando su 'Dependent Tasks' si possono vedere i dettagli.

Ecco una breve descrizione:

• ACID compliant
• Commit/Rollback
• Updates e deletes concorrenti
• Lock a livello di riga
• Group commit (è già in MariaDB 5.2)
• Ricerca nelle pagine degli indici più veloci (Page directory)

In Aria 2.5 l'intento è di iniziare a concentrarsi sulle prestazioni.

Come pensate di raggiungere questi obiettivi?

Migliorando continuamente MariaDB e rilasciandolo fin quando non si avrà una release sufficientemente stabile.

I miglioramenti tra le varie versioni dovrebbero essere realizzati in modo tale che gli aggiornamenti siano triviali (insomma, senza bisogno di effettuare il dump e ricaricare i dati, o modificare le applicazioni).

Lavoreremo da vicino con la comunità per migliorare tanto lo Storage Engine Aria quando il server MySQL che è distribuito come parte di MariaDB. Lavoreremo anche con la Sun per introdurre lo Storage Engine Aria in MySQL 6.0.

Gli alberi di sviluppo di MariaDB su Launchpad sono aperti al download e allo sviluppo della comunità.

Quali sono gli obiettivi finali di Aria?

NOTA: Quelli elencati di seguito sono gli obiettivi tecnici del team del progetto. Il modo in cui Aria verrà incorporato nel server MySQL® e se rimpiazzerà MyISAM è soggetto alle decisioni del MySQL Product Management.

• Creare un nuovo Storage Engine che sia conforme ad ACID e abbia il Multi-Version Concurrency Control (MVCC), e che possa essere lo Storage Engine predefinito sia transazionale sia non transazionale per MariaDB e MySQL®.
• Creare un rimpiazzo per MyISAM. Questo è possibile perché Aria può essere eseguito anche in modalità non transazionale, supporta gli stessi formati di MyISAM e supporta o supporterà la maggior parte delle caratteristiche di MyISAM.
• Che Aria sia un componente standard di MySQL 6.0; è già nell'albero di MySQL 6.0 supportato da Sun (ora Oracle).

Quali sono gli 'obiettivi di progetto' di Aria?

• Multi-Version Concurrency Control (MVCC) e ACID
• Tabelle opzionalmente non transazionali che dovrebbero essere 'veloci e compatte' come quelle di MyISAM
• Possibilità di usare Aria per le tabelle temporanee interne in MySQL (invece di MyISAM)
• Tutti gli indici dovrebbero avere la stessa velocità (gli indici clusterizzati non fanno parte della road map di Aria. Se si necessita degli indici clusterizzati, è meglio usare XtraDB)
• Far sì che le transazioni di 'qualsiasi' lunghezza funzionino (supportando le transazioni di lunga durata, si avrà bisogno di più spazio nei log)
• Permettere lo spostamento dei log; per esempio, si potranno fare dei backup incrementali delle tabelle Aria copiando i log di Aria
• Permettere di copiare le tabelle Aria tra differenti server (rispettando alcuni vincoli ben definiti)
• Miglior gestione dei blob (come minimo, migliore di quella offerta da MyISAM)
• Evitare di copiare la memoria o di usare memoria aggiuntiva per i blob durante le insert e le update.
• Blob allocati in grandi blocchi sequenziali - meno frammentazione nel tempo
• I blob sono registrati in modo tale che Aria possa facilmente essere estesa per avere accesso a qualsiasi parte del blob con una singola lettura, in futuro
• Scrittura veloce su disco (quindi un basso ritardo per le righe dei dati, un basso ritardo per le pagine dei dati e poco spazio sprecato nelle pagine). Nota: vi è ancora del lavoro da fare per completare questo obiettivo. Il progetto del disco va bene, ma c'è bisogno di più caching in memoria
• Un piccolo footprint, per rendere MariaDB + Aria adatto ai desktop e alle applicazioni embedded
• Allocazione della memoria flessibile e algoritmi scalabili per utilizzare grandi quantità di memoria in modo efficiente, quando è disponibile

Dove posso trovare documentazione e aiuto su Aria?

Il progetto è mantenuto su Launchpad.

Se si desidera restare aggiornati o essere parte dello sviluppo di Aria, è possibile iscriversi ai gruppi maria-captains, maria-developers, maria-docs o maria-discuss su Launchpad.

E' possibile riportare o conoscere i bug di Aria su Launchpad o nel sistema di bug di MySQL.

Di solito è possibile trovare alcuni sviluppatori di MariaDB online sul canare IRC #maria su freenode.

Chi c'è dietro ad Aria?

Attualmente, il nucleo del team di Aria è formato da:

Leader tecnico:

• Michael "Monty" Widenius - Creatore di MySQL e MyISAM

Sviluppatori principali (in ordine alfabetico)

• Guilhem Bichot - Esperto di replica, on line backup di MyISAM, etc.
• Kristian Nielsen - Build tools di MySQL, NDB, MySQL server
• Oleksandr Byelkin - Cache delle query, sub-queries, viste
• Sergei Golubchik - Architetto del server, ricerca fulltext, indici per MyISAM-Merge, architettura a Plugin, etc.

Tutti eccetto Guilhem Bichot lavorano per SkySQL.

Quali sono la politica dei rilasci e la pianificazione di Aria?

Aria segue gli stessi criteri di rilascio che usa MariaDB.

Alcuni chiarimenti, relativi ad Aria:

• I formati dei file degli indici e dei dati dovrebbero essere compatibili all'indietro e in avanti, per facilitare il downgrade e l'upgrade
• Si cercherà di mantenere compatibile il formato dei file di log, ma non ci sono garanzie che sarà così. In altre parole, in caso di upgrade, a volte sarà necessario rimuovere i vecchi file aria_log.## e maria_log.## prima di riavviare mysqld. Fino ad ora questo è avvenuto solo tra MariaDB 5.1 e 5.2

Commissioni aggiuntive per Beta 1.5

• Aria ha tutte le caratteristiche previste dalle specifiche presenti nel worklog di Aria 1.5.

Quali sono le differenze tra Aria 1.5 e MyISAM?

Aria 1.0 era fondamentalmente un rimpiazzo crash-safe non transazionale di MyISAM. Aria 1.5 ha aggiunto una miglior concorrenza (inserimenti da utenti multipli) e alcune ottimizzazioni.

Aria supporta tutte le caratteristiche di MyISAM, eccetto quelle elencate sotto. Questo comprende il check, il repair e la compressione, sia interna sia esterna, delle righe, diversi formati, diversi formati di compressione degli indici, aria_chk, etc. Dopo un arresto normale, è possibile copiare i file di Aria da un server a un altro.

Vantaggi di Aria (rispetto a MyISAM)

• I dati e gli indici sono crash safe.
• In caso di crash, le modifiche vengono annullate allo stato dell'avvio di una istruzione o dell'ultimo comando LOCK TABLES
• Aria può ripetere quasi tutte le istruzioni dal log (anche creare, eliminare, rinominare e troncare le tabelle). Perciò, si può eseguire un backup di Aria semplicemente copiando il log. Ecco che cosa non può essere (ancora) ripetuto:
  • Le batch di INSERT in una tabella vuota (questo comprende LOAD DATA INFILE, SELECT ... INSERT e le INSERT di molti record).
  • ALTER TABLE. Si noti che le tabelle .frm NON vengono ricreate!
• LOAD INDEX può saltare i blocchi degli indici indesiderati
• Supporta tutti i formati dei record di MyISAM e il nuovo formato PAGE, dove i dati sono registrati in pagine (le dimensioni predefinite sono di 8K)
• Inserimenti concorrenti nella stessa tabella provenienti da diversi utenti
• Quando si usa il formato PAGE (predefinito) i dati delle righe vengono messi in una cache dalla cache delle pagine
• Aria ha dei test unitari in diverse parti di codice
• Supporta sia tabelle crash-safe (che presto saranno transazionali) sia tabelle non transazionali. (Le tabelle non transazionali non vengono loggate e le righe richiedono meno spazio): CREATE TABLE foo (...) TRANSACTIONAL=0|1 ENGINE=Aria.
• PAGE è l'unico formato di record crash-safe/transazionale
• Il formato PAGE dovrebbe fornire notevoli miglioramenti prestazionali sui sistemi che non hanno un buon caching dei dati (come ad esempio Windows)

Differenze tra Aria e MyISAM

• Aria usa GRANDI file di log (1G per default)
• Aria ha un file di controllo (aria_log_control) e alcuni file di log (aria_log.???????). I file di log possono essere svuotati automaticamente quando non sono più necessari, oppure su richiesta (magari dopo un backup)
• Aria usa pagine di 8K per default (quelle di MyISAM sono di 1K). Questo rende Aria un po' più veloce quando si usano indici di dimensioni fisse, ma più lento quando si usano chiari compresse di dimensioni variabili (questo fino a quando non aggiungeremo una directory delle pagine degli indici)

Svantaggi di Aria (rispetto a MyISAM) che verranno eliminati presto

• Aria non supporta INSERT DELAYED
• Aria non supporta cache degli indici multiple

Svantaggi di Aria (rispetto a MyISAM) che verranno eliminati in una versione successiva

• La scrittura di righe molto piccole (< 25 byte) non è efficiente con il formato PAGE
• Le tabelle MERGE non supportano Aria (dovrebbe essere facile aggiungere questo supporto in futuro)

Differenze che probabilmente non verranno eliminate

• Le pagine dei dati di Aria nel formato a blocchi hanno un sovraccarico di 10 byte per pagina e 5 byte per riga. Il supporto alle transazioni e alle insert concorrenti multiutente utilizza un sovraccarico ulteriore di 7 byte per le nuove righe, 14 byte per le righe eliminate e 0 byte per le vecchie righe compresse.
• Nessun lock esterno (MyISAM ha i lock esterni, ma tale caratteristica è usata di rado)
• Le dimensioni delle pagine di Aria sono le stesse per i dati e per gli indici (definite quando Aria viene usato per la prima volta). MyISAM supporta dimensioni differenti per i dati e per gli indici
• Un piccolo sovraccatico (15 byte) per ogni pagine degli indici
• Aria non supporta il RAID interno di MySQL (è stato disabilitato anche in MyISAM: è una funzionalità deprecata)
• Le dimensioni minime per il file dei dati, con il formato PAGE, sono di 16K (con pagine di 8K)

Quali sono le differenze tra MariaDB 5.1 e il normale MySQL-5.1?

Si veda:

• Storage Engine Aria
• MariaDB contro MySQL

Perché utilizzare la parola chiave TRANSACTIONAL se Aria non è ancora transazionale?

Nell'attuale fase di sviluppo, le tabelle Aria create con TRANSACTIONAL=1 sono crash safe e atomiche ma non transazionali, perché le modifiche non possono essere annullate con il comando ROLLBACK. Poiché Aria sarà pienamente transazionale, relativamente fra breve tempo, crediamo sia meglio utilizzare fin d'ora la parola chiave TRANSACTIONAL, in modo che le applicazioni non debbano essere modificate in un secondo momento.

Le tabelle create con TRANSACTIONAL=1 guadagneranno ulteriori funzionalità transazionali ad ogni nuova versione di Aria. Ci aspettiamo che queste tabelle saranno pienamente transazionali (nel senso tradizionale del termine) con Aria 2.0.

Quali sono i problemi conosciuti delle versioni MySQL-5.1-Maria?

• Si veda KNOWN_BUGS.txt per conoscere i bug aperti e i bug di progettazione
• Si veda http://bugs.launchpad.net/maria o http://bugs.mysql.com/ per conoscere i bug riportati di recente. Si prega di riportare qui i problemi che si riscontrano!
• Se vi è un bug nel codice di recupero di Aria o nel codice che genera i log, o se i log sono corrotti, allora mysqld non dovrebbe essere in grado di avviarsi, perché Aria non dovrebbe essere in grado di eseguire i log all'avvio.

Se Aria non si avvia o se non si riesce a recuperare una tabella (cosa che non dovrebbe accadere):

• Si eliminino i file aria_log.???????? dalla directory dei dati
• Si riavvii mysqld e si esegua CHECK TABLE / REPAIR TABLE o mysqlcheck sulle tabelle Aria

oppure

• Si rimuovano i log e si esegua aria_chk sui file *.MAI

Cosa cambierà nelle prossime versioni di Aria?

LOCK TABLES non inizierà un segmento crash-safe. Si dovrebbe usare BEGIN/COMMIT invece. Per rendere il tutto compatibile in avanti, si potrebbe fare così:

BEGIN;
LOCK TABLES ....
UNLOCK TABLES;
COMMIT;

E successivamente limitarsi a rimuovere la parte LOCK/UNLOCK.

Come posso creare una tabella Aria in stile MyISAM (non transazionale)?

Esempio:

CREATE TABLE t1 (a int) ROW_FORMAT=FIXED TRANSACTIONAL=0 PAGE_CHECKSUM=0;
CREATE TABLE t2 (a int) ROW_FORMAT=DYNAMIC TRANSACTIONAL=0 PAGE_CHECKSUM=0;
SHOW CREATE TABLE t1;
SHOW CREATE TABLE t2;

Si noti che i record non vengono copiati nella cache delle pagine se si usano i formati FIXED e DYNAMIC. Se si desidera avere una cache dei dati (non supportata da MyISAM) si può usare ROW_FORMAT=PAGE:

CREATE TABLE t3 (a int) ROW_FORMAT=PAGE TRANSACTIONAL=0 PAGE_CHECKSUM=0;
SHOW CREATE TABLE t3;

E' possibile utilizzare PAGE_CHECKSUM=1 anche per le tabelle non transazionali; questo fa sì che venga mantenuto un checksum in tutte le pagine degli indici. Questo checksum sarà presente anche se si usa ROW_FORMAT=PAGE.

Si potrebbero notare delle differenze nella velocità (che possono essere leggermente positive o negative) tra MyISAM e Aria per via delle differenti dimensioni delle pagine. E' possibile modificare le dimensioni in MariaDB con --aria-block-size=#, dove # è uno dei seguenti valori; 1024, 2048, 4096, 8192, 16384 o 32768.
Si noti che se si modificano le dimensioni delle pagine occorre eseguire un dump di tutte le tabelle in un file di testo (con mysqldump) e rimuovere i vecchi file di log di Aria:

rm datadir/aria_log*

Quali sono i vantaggi e gli svantaggi del nuovo formato PAGE, rispetto ai vecchi formati di MyISAM (DYNAMIC e FIXED)?

I formati DYNAMIC e FIXED di MyISAM sono estremamente semplici e richiedono uno spazio aggiuntivo molto piccolo, perciò è difficile batterli quando si tratta di effettuare semplici scansioni di dati non modificati. Il formato DYNAMIC però si comporta molto peggio con il tempo, se si effettuano sui record molte modifiche che ne incrementano le dimensioni.

I vantaggi del formato PAGE (rispetto a DYNAMIC e FIXED) per le tabelle non transazionali sono i seguenti:

• I dati sono copiati nella cache delle pagine, e questo migliora le performance (perché utilizza meno chiamate di sistema)
• Non si frammenta così facilmente come il formato DYNAMIC durante le istruzioni UPDATE; il numero massimo di frammenti è molto basso
• Il codice può facilmente essere esteso per leggere esclusivamente le colonne interessate (ad esempio, evitando di leggere i blob)
• Modifiche più veloci (rispetto a DYNAMIC).

Gli svantaggi sono:

• E' richiesto un po' di spazio aggiuntivo (la differenza dovrebbe essere sensibile per righe di dimensioni molto ridotte)
• La scansione completa delle tabelle è più lenta
• Quando si usa row_format=PAGE (predefinito), Aria prima scrive le righe, poi le chiavi e a quel punto controlla se ci sono dei duplicati. Questo rallenta il formato PAGE rispetto a DYNAMIC (o a MyISAM) se vi sono molti valori duplicati, per via del ritardo dato dalla scrittura e dalla successiva rimozione dei record. Se questo risulta essere un problema, è meglio usare row_format=DYNAMIC per ottenere un comportamento identico a quello di MyISAM.

Qual è il modo corretto per copiare una tabella Aria da un posto a un altro?

Una tabella Aria consiste in tre file:

XXX.frm: La definizione della tabella, usato da MySQL.
XXX.MYI: Informazioni interne sulla struttura dei dati, la struttura degli indici e i dati degli indici.
XXX.MAD: I dati.

E' possibile copiare in modo sicuro i file di Aria in un'altra directory o istanza di MySQL, se una delle seguenti condizioni è vera:

• Se si arresta correttamente mysqld con 'mysqladmin shutdown', in modo che non ci siano dati da recuperare al riavvio di Aria

oppure

• Se si esegue 'flush tables ' e non si accede alle tabelle con SQL finché le tabelle non siano state copiate.

Inoltre, per le tabelle transazionali, occorre rispettare la regola seguente:

Non è possibile copiare la tabella in un percorso che appartiene allo stesso server MySQL, se la nuova tabella esisteva già e la nuova tabella è ancora attiva nel log del recupero di Aria (cioè se Aria potrebbe aver bisogno di accedere ai vecchi dati durante il recupero). Se non si è sicuri del fatto che il vecchio nome esistesse o meno, si esegua 'aria_chk --zerofill' sulla tabella prima di utilizzarla.

Prima di copiare una tabella transazionale e prima di utilizzarla, si raccomanda di eseguire il seguente comando:

aria_chk --zerofill nome_tabella

Questo sovrascrive con 0 tutti i riferimenti ai log (LSN), tutti i riferimenti transazionali (TRN) e tutto lo spazio inutilizzato. Inoltre marca la tabella come 'spostabile'.

Un altro vantaggio dello zerofill è che permette ai file di Aria una migliore compressione. Nessun dato reale viene eliminato dallo zerofill.

Aria rileva automaticamente se una tabella è stata copiata da un altro sistema; in tal caso, al primo accesso esegue uno zerofill a meno che la tabella non sia stata segnata come 'spostabile'. Un motivo per usare <<code>>aria_chk --zerofill<<code>> è che si evita un ritardo al primo accesso alla tabella.

Si noti che questo rilevamento automatico non funziona se si copiano tabelle da un altro server MariaDB!

Quando è sicuro rimuovere i vecchi file di log?

Se si desidera rimuovere i vecchi file di log di Aria (aria_log.*) con i comandi 'rm' o 'delete', prima di farlo occorre arrestare MariaDB in modo pulito (ad esempio con 'mysqladmin shutdown').

Le stesse regole vanno seguite quando si aggiorna MySQL; prima si arresta MySQL in modo pulito e solo dopo si esegue l'upgrade. Questo permette di rimuovere i vecchi file di log se vi sono problemi di incompatibilità tra le varie versioni.

Non bisogna rimuovere il file aria_log_control! Non si tratta di un file di log, ma contiene informazioni sulla configurazione di Aria (id della transazione corrente, id unico, numero del prossimo file di log, etc).

Se lo si elimina, Aria genera un nuovo file aria_log_control all'avvio e tratta i vecchi file di Aria come se fossero stati copiati da un altro sistema. In pratica, deve eseguire su di essi un zerofill prima di potervi accedere.

Se questo avviene, nel file mysqld.err si vedrà qualcosa di questo genere:

Note] Zerofilling moved table: '.\database\xxxx'

Lo zerofill non rimuove dati importanti.