ARCHIV

Jak ušetřit místo na disku v MySQL databázi

Moderní možnosti InnoDb v nových verzích MySQL.

20.9.2012 20:00 | Miloslav Ponkrác | přečteno 5633×

InnoDb – Antelope a Barracuda

InnoDb pracuje se soubory na disku, které jsou buď ve formátu Antelope nebo Barracuda. Barracuda je novější formát, který umí o něco více než Antelope.

InnoDb verze 1.0, které je součástí MySQL až do verze 5.4, dokáže pracovat pouze s formátem Antelope.

InnoDb verze 1.1, který je součástí MySQL 5.5 a vyšší, umí pracovat s oběma formáty.

A teď pozor! Hlavní globální soubory InnoDb jsou vždy pouze a jenom ve formátu Antelope. Pokud si nastavíte možnost vytvářet zvláštní soubor pro každou tabulku (volba --innodb_file_per_table), pak volitelně mohou být tyto zvláštní soubory ve formátu Barracuda. V jakém formátu budou tyto soubory jednotlivých tabulek určuje konfigurační volba --innodb_file_format, která může mít jednu ze dvou hodnot: Antelope nebo Barracuda. Od MySQL 5.5.7 je defaultní hodnota této volby Barracuda, pod tuto verzi je defaulní hodnota Antelope.

Co z toho vyplývá? Pokud nenastavíte volbu --innodb_file_per_table, pak některé vlastnosti a možnosti InnoDb zůstanou zablokovány.

Pokud z toho bude následující trend i v budoucích verzích MySQL, pak to znamená, že bez --innodb_file_per_table zůstane spousta možností InnoDb zablokovaných.

Je třeba se také zmínit, že samotné nastavení --innodb_file_per_table už šetří diskovým místem. Bez tohoto nastavení jsou všechna data InnoDb engine ukládána v globálním souboru či sady souborů. Tyto soubory se obvykle (jak to bývá nakonfigurováno) zvětšují při potřebě dalšího prostoru, ale nikdy se nezmenšují. Pokud tedy vymažete z databáze 20 GB dat, pak hlavní globální soubory InnoDB stále okupují o 20 GB místa plus další režie navíc.

Možnosti formátu Barracuda

Novinky InnoDb 1.1 a formátu Barracuda jsou dvě: Možnost komprese datových souborů. A také možnost dynamického ukládání datových řádků, které lépe zacházejí s místem při ukládání velkých blobů či dlouhých řetězců.

InnoDb klasicky ukládá datové řádky jako „compact“, kde texty i bloby jsou ve stejné stránce jako je zbytek datového řádku. Nová možnost formátu Barracuda „dynamic“ ukládá texty a bloby mimo data zbytku datového řádku. Snižuje se tak počet I/O operací, protože zbytek dat celé tabulky zabírá málo datových stránek a lze je rychleji číst, vyhledávat, měnit a kešovat.

Kromě toho si u formátu Barracuda můžete nastavit datové řádky jako „compressed“, které dělají to co „compact“, ale navíc komprimují dikový prostor jak u datových stránek, tak u stránek indexů.

Jak nastavit novinky u MySQL a InnoDb

Dané novinky jsou doménou MySQL 5.5.x a vyšší. Ve skutečnosti to není novinka, protože MySQL 5.5 se stala stabilní a hlavní verzí už 3.12.2010.

Verzi MySQL 5.5 považuji za hodně revoluční, protože má velmi mnoho významných vylepšení oproti předchozím verzím. Jako významné bych považoval konečně možnost čistého ošetření a zpracování chyb v procedurách a triggerech, konečně pořádnou podporu Unicode v možnostech o jakých se v předchozích verzích ani nesní (včetně nových dalších Unicode kódování v datových typech sloupců) – teprve od MySQL 5.5 je až možné používat všechny Unicode znaky, totálně přepracovaná a velmi dobrá práce s thready včetně nižších požadavků na prostředky počítače. A také bylo konečně opraveno mnoho nedodělků, které byly způsobeny nejistotou předchozích vlastníků.

Varování: Následující změny dělejte na čistém databázovém stroji bez dat a vytvořených databázových tabulek. Případně vše zazálohujte pomocí mysqldump nástroje a začněte od nuly. MySQL musí předpokládat, že diskové soubory má v nějakém formátu a změna v již existující databázích jí zmate. Můžete si tak i poničit existující data.

Dále je nutné nastavit umožnit používání v konfiguraci MySQL. Do konfiguračního souboru, obvykle mysql.conf je třeba do sekce [mysqld] přidat:

innodb_file_per_table

innodb_file_format=Barracuda

Alternativně je možné zadat tyto volby do příkazového řádku MySQL serveru:

mysql --innodb_file_per_table --innodb_file_format=Barracuda … 

Komprimovat jednotlivé tabulky je pak možné pomocí SQL příkazů:

Nastavit formát řádku lze klauzulí ROW_FORMAT = typ_radku:

CREATE TABLE dummy ( … ) ENGINE=InnoDb ROW_FORMAT=compressed;

Další doporučení pro InnoDb a šetření diskovým prostorem

InnoDb engine špatně pracuje, pokud má databázová tabulka dlouhý primární klíč. To samé platí pro indexy. Pak je neefektivní a případný index velmi plýtvá diskovým místem. Což se projevuje i na snížení výkonu. InnoDb tabulky by proto měly mít krátký primární klíč (myšleno délkou v najtech), tedy ideálně buď číselný, nebo krátký řetězcový.

U každé tabulky specifikujte primární klíč nebo nějaký unikátní (unique) index. Pokud nespecifikujete primární klíč, ale specifikujete unikátní index, pak MySQL první unikátní index použije vnitřně jako primární klíč. Pokud tedy z nějakého důvodu nemáte primární klíč, ale máte několik unikátních indexů, vězte, že na jejich pořadí záleží. Uveďte jako první ten, po kterém může MySQL „hmátnout“ jako po primárním klíči, protože to také udělá. Nejlepší je ovšem explicitně primární klíč definovat.

Pokud administrujete databázi pro řadu uživatelů, zvažte použití volby --sql_mode=NO_ENGINE_SUBSTITUTION, která způsobí, že všechny databázové tabulky budou vytvořeny s defaultní enginem, tedy většinou InnoDb, bez ohledu na to, jaké parametry uživatel zadá do klauzule ENGINE= u SQL příkazů CREATE TABLE nebo ALTER TABLE.

--
Ing. Miloslav Ponkrác
www.ponkrac.net

Verze pro tisk

DISKUZE Prečo len InnoDB? 30.9.2012 16:42 msx.   Re: Prečo len InnoDB? 1.10.2012 14:06 Miloslav Ponkrác   Re: Prečo len InnoDB? 4.10.2012 18:05 MaReK Olšavský     Re: Prečo len InnoDB? 4.10.2012 22:13 Miloslav Ponkrác       Re: Prečo len InnoDB? 5.10.2012 07:45 MaReK Olšavský         Re: Prečo len InnoDB? 5.10.2012 21:37 Miloslav Ponkrác Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.