it-swarm-eu.dev

Jaké jsou důvody ** NE ** použití paměťového modulu MEMORY v MySQL?

Nedávno jsem zjistil, že MySQL má "paměťový" engine, o kterém jsem nevěděl (většina práce s databází je pro hobby projekty, takže se přiučím, co potřebuji). Vypadá to, že by mi tato možnost měla přinést drasticky vylepšený výkon, takže jsem zvědavý, jestli s tím existují nějaké nevýhody. Dva, o kterých vím, jsou:

  1. Musím mít dost RAM), abych udržel dotyčné tabulky.
  2. Pokud se stroj vypne, tabulky se ztratí.

Věřím, že # 1 by neměl být problém, protože používám AWS EC2 a mohu se v případě potřeby přesunout na typ instance s větší pamětí. Věřím, že dokážu zmírnit # 2 tím, že v případě potřeby vrátím zpět na disk.

Jaké jsou další problémy? Může paměťový modul někdy poskytnout horší výkon než MyISAM nebo InnoDB? Myslím, že jsem četl něco, co se u tohoto motoru liší indexy; je to něco, čeho se musím bát?

30
Michael McGowan

Při pohledu na seznam dostupnosti funkcí na http://dev.mysql.com/doc/refman/5.1/en/memory-storage-engine.html vyskočí dva možné problémy:

  1. Nebyla potřeba žádná transakce nebo podpora FK, což znamená, že budete muset spravovat transakční integritu a referenční integritu ve svém vlastním kódu (což by nakonec mohlo být mnohem méně efektivní než nechat DB udělat to za vás, i když to do značné míry závisí na vaší aplikaci očekávané vzorce chování).
  2. Pouze zamykání na úrovni tabulky: mohlo by to být významnou překážkou škálovatelnosti, pokud vaše aplikace potřebuje více souběžných zapisovatelů do stejné sady tabulek nebo v případech, kdy vaše operace čtení používají zámky k zajištění konzistentního čtení dat - v takových případech tabulka založená na disku, která podporuje mnohem jemnější zámek granularity bude fungovat mnohem lépe, pokud je dostatek jeho obsahu v současné době v mezipaměti v RAM.

Kromě toho, za předpokladu, že máte dostatek paměti RAM, by tabulka založená na paměti měla být rychlejší než tabulka založená na disku. Je zřejmé, že musíte vzít v úvahu snímky na disk, abyste vyřešili problém, který se stane, když dojde k resetu instance serveru, což pravděpodobně celkově neguje výkonnostní výhodu, pokud se data potřebují často zachytávat (pokud můžete žít se ztrátou jednoho dne v takovém případě byste mohli zálohu pořídit pouze jednou denně, ale ve většině případů by to nebylo přijatelné).

Alternativou může být:

  1. Používejte tabulky založené na disku, ale ujistěte se, že máte více než dost RAM), abyste je mohli v každém okamžiku držet všechny v RAM (RAM $ ===) více, než si myslíte, že musíte započítat jakékoli jiné procesy v počítači, OS IO vyrovnávací paměti/mezipaměť atd.)
  2. Naskenujte celý obsah (všechna data a indexové stránky) tabulky při každém spuštění a načtěte obsah do paměti pomocí SELECT * FROM <table> ORDER BY <pkey fields> pro každou tabulku následovanou SELECT <indexed fields> FROM <table> ORDER BY <index fields> pro každý index

Tímto způsobem jsou všechna vaše data v RAM, takže se musíte starat pouze o výkon I/O pro operace zápisu. Pokud je běžná pracovní sada aplikace mnohem menší než celá databáze DB (což obvykle platí - ve většině aplikací se většina uživatelů bude dívat pouze na nejnovější data, bude-li čas), může být lepší výběr toho, o kolik skenujete pro předběžné načtení do paměti, což umožňuje načíst zbytek z disku na vyžádání.

27
David Spillett

Existuje spousta případů, kdy se nepoužívá paměťový engine - a kdy bude InnoDB rychlejší. Stačí jen přemýšlet o souběžnosti a ne o triviálních testech s jedním vláknem.

Pokud máte dostatečně velký fond vyrovnávacích pamětí, stane se InnoDB také rezidentní pro operace čtení. Databáze mají mezipaměti . Zahřívají se!

Rovněž - nepodceňujte hodnotu zamykání na úrovni řádků a MVCC (čtenáři neblokují spisovatele). To může být "pomalejší", když zápisy musí přetrvávat na disk. Alespoň však během této operace zápisu nebudete blokovat, jako byste byli na paměťové tabulce (žádné MVCC; zamykání na úrovni tabulky).

15
Morgan Tocker

Pro záznam. Pro uložení některých informací jsem otestoval tabulky Mysql v paměti. A testoval jsem PHP APC (APCu) pro uložení stejných informací.

Pro 58 000 registrů. (varchar + celé číslo + datum).

  1. Originální informace 24mb v textovém formátu (formát csv).
  2. PHP APC používá 44,7 MB RAM.
  3. Tabulka Mysql využívá 575 MB RAM.

Tabulka má pouze jeden index, takže si nemyslím, že je to hlavní faktor.

Závěr:

Tabulka paměti je nikoli možnost pro „velké“ tabulky, protože používá příliš mnoho paměti.

3
magallanes

Další nevýhodou tabulek založených na MEMORY je to, že nemohou být ve stejném dotazu vícekrát odkazovány. Alespoň to chování bylo nalezeno až do v5.4. Jak u CTE (od v8.x) není pro složité procedury nutné používat mezilehlé tabulky založené na mem.

2
Kondybas

Kromě předchozích odpovědí. přímo z manuálu MySQL 5.7:

"Výkon paměti MEMORY je omezen tvrzením vyplývajícím z provádění podprocesu s jedním vláknem a režie tabulky při zpracování aktualizací. To omezuje škálovatelnost při zvyšování zátěže, zejména u směsí příkazů, které zahrnují zápisy."

... a to je velmi skutečné omezení. Například: když máte několik relací, které se pokoušejí vytvořit hezké rychlé tempové tabulky MEMORY, může jednozávitování způsobit vážné omezení výkonu.

1
Eljuan

Tabulky MEMORY nejsou určeny k trvalému ukládání, zejména pro velké podmnožiny dat nebo cokoli, kde je uchovávání kritické. Jejich nejlepší účel z mé zkušenosti spočívá v uložení přechodných záznamů během vytváření a populace dočasných tabulek během složitých procedur, které za tímto účelem fungují výrazně rychleji než většina ostatních typů tabulek za předpokladu, že vaše prahová hodnota mezipaměti pro motor je nastavena dostatečně vysoko, aby nevyvolávala zápis na disk. To může za tímto účelem pracovat rychleji než MyISAM nebo InnoDB, protože neexistuje žádný disk I/O, a v případě tabulky, která je zapouzdřena v rámci specifického postupu, indexování a vztahy nemají tak velký význam, jako jsou kde by se očekávala vytrvalost.

1
mopsyd

Podle příruček MySQL a MariaDB nejsou úložiště MEMORY podporovány BLOB a CLOB (různé typy TEXT). Pro naše vlastní účely to učinilo paměťový modul MEMORY téměř k ničemu.

http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html

Tabulky MEMORY nemohou obsahovat sloupce BLOB nebo TEXT.

https://mariadb.com/kb/en/mariadb/memory-storage-engine/

Typy s proměnnou délkou, jako je VARCHAR, lze použít v tabulkách MEMORY. Sloupce BLOB nebo TEXT nejsou podporovány pro tabulky MEMORY.

Při pokusu převést pouze část databáze do paměti MEMORY jsem zjistil, že cizí klíče mezipaměťového modulu nejsou podporovány. Všechny tabulky, které by měly mít odkazy na cizí klíče na tabulky obsahující BLOB/CLOB, by tedy měly být také v typech paměti bez paměti (to alespoň ovlivňuje podřízené tabulky InnoDB).

1
user2134886