Använda Aria Storage Engine med MariaDB Server

MariaDB Server är en av de mest populära databasservrarna med öppen källkod. Det skapades av de ursprungliga utvecklarna av MySQL och det blev populärt för att vara snabbt, skalbart och robust. MariaDB har ett rikt ekosystem av lagringsmotorer, plugins och andra tillgängliga verktyg som gör den mycket mångsidig för en mängd olika användningsfall.

När det gäller MariaDB-lagringsmotorn har du olika typer att välja mellan som XtraDB, InnoDB, MyRocks, MyISAM eller till och med Aria. Det finns ingen bästa lagringsmotortyp, eftersom den beror på själva arbetsbelastningen. Den sistnämnda, Aria Storage Engine, kompileras som standard från MariaDB 5.1 och den måste vara "använd" när MariaDB-tjänsten startas.

I den här bloggen kommer vi att se vad Aria Storage Engine är och hur man använder den i en MariaDB-server.

Vad är Aria Storage?

Aria är en lagringsmotor för MySQL och MariaDB. Den utvecklades ursprungligen med målet att bli standardlagringsmotorn för transaktioner och icke-transaktioner för MariaDB och MySQL.

För närvarande stöder den kryptering och detektering av dödläge, och den erbjuder också ett kraschsäkert alternativ till MyISAM. När MariaDB startar om efter en krasch, återställer Aria alla tabeller till tillståndet vid starten av en sats eller i början av den sista LOCK TABLES-satsen.

Aria stöder extern och intern kontroll, reparation och komprimering av rader, olika radformat, olika indexkomprimeringsformat, aria_chk och mer.

Denna lagringsmotor har använts för MariaDB-systemtabellerna sedan 10.4-versionen.

Skillnader mellan Aria och MyISAM

Låt oss se några grundläggande skillnader mellan Aria och hans direkta konkurrent:MyISAM, och sedan fördelarna och nackdelarna med Aria Storage Engine.

Aria använder stora loggfiler (1G som standard).
Aria har en loggkontrollfil (aria_log_control) och loggfiler (aria_log.%). Loggfilerna kan rensas automatiskt när de inte behövs eller rensas på begäran.
Aria använder 8K-sidor som standard, medan MyISAM använder 1K. Detta gör Aria lite snabbare när du använder nycklar med fast storlek, men långsammare när du använder nycklar med variabel längd.

Fördelar med Aria Storage Engine

Data och index är kraschsäkra.
Vid en krasch kommer ändringarna att återställas till läget för starten av en sats eller en sista LOCK TABLES-sats.
Aria kan spela upp nästan allt från loggen. De saker som inte kan spelas upp ännu är:
- Sats INSERT i en tom tabell.
- ÄNDRA TABELLER.
LOAD INDEX kan hoppa över indexblock för oönskade index.
Stöder alla MyISAM ROW-format och nya PAGE-format där data lagras på sidor.
Flera samtidiga infogare i samma tabell.
När du använder PAGE-format cachelagras raddata av sidcache.
Aria har enhetstester av de flesta delar.
Stöder både kraschsäkra och inte transaktionstabeller.
PAGE är det enda kraschsäkra/transaktionella radformatet.
SIDA-format bör ge en anmärkningsvärd hastighetsförbättring på system som har dålig datacache.
Från MariaDB 10.5 är den maximala nyckellängden 2000 byte, jämfört med 1000 byte i MyISAM.

Nackdelar med Aria Storage Engine

Aria stöder inte INSERT DELAYED.
Aria stöder inte flera nyckelcacher.
Lagringen av mycket små rader (<25 byte) är inte effektiv för PAGE-format.
MERGE-tabeller stöder inte Aria.
Aria-datasidor i blockformat har en overhead på 10 byte/sida och 5 byte/rad. Transaktioner och stöd för flera samtidiga skrivare kommer att använda en extra overhead på 7 byte för nya rader, 14 byte för raderade rader och 0 byte för gamla komprimerade rader.
Ingen extern låsning.
Aria har en sidstorlek för både index och data. MyISAM stöder olika sidstorlekar per index.
Liten overhead per indexsida (15 byte).
Minsta datafilstorlek för PAGE-format är 16K.
Aria stöder inte index på virtuella fält.

Aria-lagringsformaten

Den stöder tre olika tabelllagringsformat.

Fast längd

Dessa tabeller innehåller poster med en fast längd. Varje kolumn har samma längd för alla poster, oavsett det faktiska innehållet. Det är standardformatet om en tabell inte har några BLOB-, TEXT-, VARCHAR- eller VARBINARY-fält och inget RADFORMAT tillhandahålls.

Kännetecken:

Snabbt, eftersom MariaDB alltid vet var en post börjar.
Lätt att cache.
Ta upp mer utrymme än dynamiska tabeller, eftersom den maximala mängden lagringsutrymme kommer att tilldelas varje post.
Rekonstruktion efter en krasch är okomplicerad på grund av de fasta positionerna.
Ingen fragmentering eller behov av att organisera om, såvida inte poster har raderats och du vill frigöra utrymme.

Tabeller som innehåller BLOB- eller TEXT-fält kan inte åtgärdas eftersom dessa båda är dynamiska fält.

Dynamisk

Dessa tabeller innehåller poster med variabel längd. Det är standardformatet om en tabell har några BLOB-, TEXT-, VARCHAR- eller VARBINARY-fält och inget RADFORMAT tillhandahålls.

Kännetecken:

Varje rad innehåller en rubrik som anger radens längd.
Rader tenderar att lätt bli fragmenterade. ATT UPPDATERA en post för att vara längre säkerställer sannolikt att den lagras på olika platser på disken.
Alla strängkolumner med en längd på fyra eller fler är dynamiska.
De kräver mycket mindre utrymme än tabeller med fast längd.
Återställning efter en krasch är mer komplicerad än med FIXA tabeller.

Sida

Det är standardformatet för Aria-tabeller och är det enda formatet som kan användas om TRANSACTIONAL är inställt på 1.

Kännetecken:

Den cachelagras av sidcachen, vilket ger bättre slumpmässig prestanda eftersom det använder färre systemanrop.
Det fragmenteras inte lika lätt som det DYNAMISKA formatet under UPPDATERINGAR. Det maximala antalet fragment är mycket lågt.
Uppdateringar snabbare än dynamiska tabeller.
Har ett litet lagringsutrymme, främst märkbart på mycket små rader.
Långsammare för att utföra en fullständig tabellskanning.
Långsammare om det finns flera dubbletter av nycklar, eftersom Aria först kommer att skriva en rad, sedan nycklar och först därefter leta efter dubbletter.

För att veta vilket lagringsformat som används av en tabell kan du använda SHOW TABLE STATUS-satsen.

Transaktionsalternativ för Aria Storage Engine

Faktiskt, för Aria betyder transaktioner kraschsäkra, och det stöds inte för partitionerade tabeller. Det kräver också PAGE-radformatet för att det ska fungera.

Tabellalternativen TRANSACTIONAL och ROW_FORMAT samverkar på följande sätt:

Om TRANSACTIONAL=1 är inställt, är det enda radformatet PAGE som stöds. Om ROW_FORMAT är inställt på något annat värde, utfärdar Aria en varning, men tvingar fortfarande radformatet att vara PAGE.
Om TRANSACTIONAL=0 är inställt kommer tabellen inte att vara kraschsäker och alla radformat stöds.
Om TRANSACTIONAL inte är inställt på något värde, stöds alla radformat. Om ROW_FORMAT är inställt kommer tabellen att använda det radformatet. Annars kommer tabellen att använda standardformatet PAGE-rader. I det här fallet, om tabellen använder PAGE-radformatet, kommer den att vara kraschsäker. Om den använder något annat radformat kommer den inte att vara kraschsäker.

Hur man använder Aria Storage Engine på MariaDB Server

Först måste du skapa en databas (om du inte har en skapad) och använda den:

MariaDB [(none)]> create database db1;

Query OK, 1 row affected (0.003 sec)

MariaDB [(none)]> use db1

Database changed

Skapa sedan en tabell med hjälp av "Aria"-motorn:

MariaDB [db1]> CREATE TABLE table1 (id int(11) DEFAULT NULL, name text)

    -> ENGINE=Aria

    -> TRANSACTIONAL=1;

Query OK, 0 rows affected (0.025 sec)

Vi angav TRANSACTIONAL-värdet i 1 för att se det här, men, som vi nämnde, är det inte nödvändigt eftersom det kommer att vara 1 som standard om vi använder Aria utan att ange radformat och transaktionsvärden. Nu kommer du att skapa tabellen:

MariaDB [db1]> SHOW CREATE TABLE table1\G

*************************** 1. row ***************************

       Table: table1

Create Table: CREATE TABLE `table1` (

  `id` int(11) DEFAULT NULL,

  `name` text DEFAULT NULL

) ENGINE=Aria DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1 TRANSACTIONAL=1

1 row in set (0.000 sec)

Och i tabellstatusen kan du kontrollera både transaktions- och radformatvärdena:

MariaDB [db1]> SHOW TABLE STATUS\G

*************************** 1. row ***************************

            Name: table1

          Engine: Aria

         Version: 10

      Row_format: Page

            Rows: 0

  Avg_row_length: 0

     Data_length: 8192

 Max_data_length: 17592186011648

    Index_length: 8192

       Data_free: 0

  Auto_increment: NULL

     Create_time: 2020-06-30 18:59:17

     Update_time: 2020-06-30 18:59:17

      Check_time: NULL

       Collation: latin1_swedish_ci

        Checksum: NULL

  Create_options: transactional=1

         Comment:

Max_index_length: 137438945280

       Temporary: N

1 rows in set (0.001 sec)

Det finns många parametrar att konfigurera relaterade till Aria Storage Engine. Du kan hitta en fullständig lista på den officiella dokumentationswebbplatsen.

Aria Storage Engine Tools

Låt oss se några verktyg för att arbeta med denna lagringsmotor.

aria_chk

Aria_chk används för att kontrollera, reparera, optimera, sortera och få information om Aria-tabeller. Med MariaDB-servern kan du använda CHECK TABLE, REPARATION TABLE och OPTIMIZE TABLE för att göra liknande saker.

Det här verktyget ska inte användas när MariaDB körs eftersom det antar att tabellen inte kommer att ändras under hans användning.

$ aria_chk [OPTIONS] aria_tables[.MAI]

I likhet med MyISAM lagras Aria-tabellinformationen i två olika filer:

MAI-filen innehåller bastabellinformation och indexet.
MAD-filen innehåller data.

Aria_chk takes one or more MAI files as arguments.

For example, to check all your tables and repairs only those that have an error, run this command in your data directory:

$ aria_chk --check --force --sort_buffer_size=1G */*.MAI

Checking Aria file: db1/table1.MAI

Data records:       0   Deleted blocks:       0

- check file-size

- check key delete-chain

- check index reference

- check record links

...

aria_pack

Aria_pack är ett verktyg för att komprimera Aria-tabeller. De resulterande tabellerna är skrivskyddade och vanligtvis cirka 40 % till 70 % mindre. Filnamnet som används av detta verktyg är .MAI-indexfilen.

$ aria_pack [options] file_name [file_name2...]

Aria_pack komprimerar varje kolumn separat, och när den resulterande informationen läses behöver endast de individuella raderna och kolumnerna som krävs dekomprimeras, vilket möjliggör snabbare läsning.

$ aria_pack /var/lib/mysql/world/country

Compressing aria_pack /var/lib/mysql/world/country.MAD: (549 records)

- Calculating statistics

- Compressing file

37.71%

Remember to run aria_chk -rq on compressed tables

När en tabell har packats, använd kommandot aria_chk -rq för att bygga om dess index.

$ aria_chk -rq --ignore-control-file /var/lib/mysql/world/country

Recreating table '/var/lib/mysql/world/country'

- check record delete-chain

- recovering (with sort) Aria-table '/var/lib/mysql/world/country'

Data records: 549

- Fixing index 1

State updated

aria_läs_logg

Aria_read_log är ett verktyg för att visa och använda loggposter från en Aria-transaktionslogg.

$ aria_read_log OPTIONS

Du måste använda ett av alternativen "-d" eller "-a":

a:Tillämpa logg på tabeller:ändrar tabeller. Du bör göra en säkerhetskopia först. Visar mycket information om du inte använder parametern --silent.
d:Visa kort information som läses från postens rubrik.

$ cd /var/lib/mysql

$ aria_read_log -d

You are using --display-only, NOTHING will be written to disk

The transaction log starts from lsn (1,0x2007)

TRACE of the last aria_read_log

Rec#1 LSN (1,0x2007) short_trid 0 redo_create_table(num_type:30) len 1042

Rec#2 LSN (1,0x2421) short_trid 0 redo_create_table(num_type:30) len 527

Rec#3 LSN (1,0x2638) short_trid 61986 long_transaction_id(num_type:36) len 6

Rec#4 LSN (1,0x2641) short_trid 61986 file_id(num_type:35) len 22

Rec#5 LSN (1,0x265d) short_trid 61986 undo_bulk_insert(num_type:39) len 9

Rec#6 LSN (1,0x266a) short_trid 0 incomplete_log(num_type:37) len 2

Rec#7 LSN (1,0x266f) short_trid 61986 commit(num_type:27) len 0

...

Slutsats

Som du kan se har Aria Storage Engine många förbättringar mot MyISAM, och det är ett utmärkt lagringsmotoralternativ att använda. Det är också lätt att använda eftersom det är en del av MariaDB Server-installationen, så bara genom att ange ENGINE-tabellparametern räcker det för att aktivera det.

MariaDB arbetar fortfarande med den här lagringsmotorn, så förmodligen kommer vi att se nya förbättringar i framtida versioner snart.