Nevím, jestli vám někdo dlouho něco zatajoval
Já jsem, když čtu to vlákno a vzpomínám na ty předchozí, popravdě trochu překvapený, že používáte MyISAM.
Na podobné debaty si vzpomínám tak před 15 a víc lety, když se od toho postupně odcházelo.
MyISAM je v rámci těch běžně užívaných db enginů víceméně taková anomálie - nesetkal jsem se s ničím podobným u ostatních víceuživatelských databází. Už tu padlo, že to nesplňuje ACID (nemá to referenční integritu, transakce, izolaci, neřeší to stabilní zápisy), což to téměř automaticky vylučuje z většiny komplikovanějších použití, ale také to má zamykání pouze na celou tabulku, nejen na řádky. Tzn. velmi špatně se to škáluje s více klienty při zápisu nebo změnách.
Bylo logické, že jestliže chtěli tohle řešit, museli místo vylepšování v podstatě udělat nový engine (InnoDB), který má jak zamykání řádků, tak i atributy toho ACID, protože ty věci spolu souvisí. A ano, samozřejmě je s tím (jako ve všech podobných databázích) spojená další režie.
S podobným typem enginů bez těch garancí a se zamykáním celých tabulek se setkáte víceméně jen v jednoduchých embedovaných databázích.
V dnešní době MyISAM nedává moc smysl, krom nějakého velice úzkého použití, kdy vás nebrzdí to zamykání (za určitých okolností vám to dovolí číst i při zápisech při povolené volbě - concurrent_insert) a nechcete žádný žurnál (WAL). Ideovým pokračovatelem MyISAMu je ARIA v MariaDB, která sice zachovává všechny principiální nectnosti, ale právě přidává zmíněný žurnál, aby to bylo odolnější při pádech.
Historicky to bylo hodně nasazované na web hostingy a pod dobové CMS. Tam to tak zásadně nevadilo, protože jste měl třeba desítky, stovky tisíc selectů (na které to bylo velice rychlé) na jeden insert nebo update (zjednodušeně, když se publikoval nový článek).
Problém v tom vašem vyhodnocení, je v tom, že porovnáváte výkon s jedním klientem při bulk importu (LOAD DATA dump.csv). Tam se logicky téměř vůbec neprojeví ty výhody paralelizace v InnoDB, která typicky nastává při normálním provozu, pokud se zapisuje z více klientů. Netuším jak to probíhá u vás v reálném provozu, nicméně velká většina aplikací v podobném duchu je uzpůsobená na krátké paralelní transakce, kdy se třeba i z jednoho klienta vytvoří pool s několika spojeními a sype se to souběžně. To má samozřejmě úplně jinou charakteristiku než jednovláknový import milionu řádků.
Pokud chcete zrychlit import, můžete rozdělit CSV na části (třeba příkazem split v systému) a pustit jejich import naráz.
Další možnosti pro paralelní logické dumpy a importy jsou např. s utilitami, co to řeší jako např. MyDumper nebo mysqlpump (je v MySQL, nevím teď jestli i pro MariaDB), podobně i importní nástroje MySQL shellu, kde se dá určit počet vláken.
Další možnost je zkopírování a přenos souborů s MyISAM tabulkami do nové databáze (buď ručně, nebo pomocí Percona XtraBackup, mariadbbackup), a následná in-place konverze do InnoDB (ALTER TABLE <tabulka> ENGINE=InnoDB;).
Ale tam to zrychlení v porovnání s těmi předchozími způsoby nebude zásadní, myslím, že paralelně pojede jen generování sekundárních indexů.
Vytváření a změny indexů pak hrají samozřejmě velkou roli jak při importu, tak i pokud řešíte nerychlejší zápisy. Je to vůbec v praxi docela složité téma (jaké indexy, kdy, optimalizace).
Nicméně pro bulk import z CSV do existující struktury můžete např. dropnout všechny sekundární indexy (ne primární, clustered) a pak je vytvořit znovu (tam už zas zabere ten paralelismus).
Nakonec MySQL (tuším 8 a vyšší) také umožňuje vypnout dočasně redo log (ALTER INSTANCE DISABLE INNODB REDO_LOG;), což také může pomoct při jednorázovém importu a migraci. Šlo to i historicky s nějakými workaroundy (nastavit velikost an 0), ale to byla čuňárna, u které nikdo negarantoval, že to nespadne.
Ale beru to v podstatě tak, že tohle děláte typicky jednou za uherák, když migrujete. Daleko důležitější je podle mě chování při standardním provozu.
Jinak takovéhle logování si říká o použití partitioningu, mělo by to jít krásně dělit třeba po nějakých periodách (týden, měsíc). U používání sekundárních indexů by to mohlo výrazně zrychlit jejich aktualizace při zápisu nových dat. Další benefit je ten, že když je daná nějaké retence dat a starší se mažou nebo archivují, tak odstranění partition je výrazně rychlejší než DELETE FROM <tabulka> WHERE.., protože se nevytváří žádný trans. log.
Na celý tenhle mangling s partitiony jde napsat uložená procedura, kterou pak může spouštět vnitřní scheduler v MySQL.
Byť jsem nikdy nedělal s TimescaleDB, co tu byla zmíněná, tak počítám, že ty principy jsou velmi podobné.
Nakonec pokud by to opravdu v nějakém paralelním používání mělo dlouhé odezvy, tak se to dá optimalizovat ještě dál. Např. i tak, že pokud to bude možné, uděláte nějakou "staging" tabulku, která neubude mít žádné sekundární indexy, ale jen třeba vzestupné číslo s auto inkrementem jako primární klíč (inserty tam jsou velmi rychlé). Z té to budete periodicky (zas uložená procedura např. jednou za minutu, dvě) sypat do druhé tabulky, kde už budou i další indexy podle potřeby. Většinou v dávkách (např. po tisících řádků) je to mnohem efektivnější.
...atd.
58 Odpovědí
12960 Zhlédnutí