Nevýhody InnoDB oproti MyISAM v MariaDB

Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #45 kdy: 22. 04. 2025, 12:27:39 »

Mě se to také nezdá. Proto o tom píši. To zničení těch disků není žádná teorie, ale skutečnost po roce provozu. Kdy díky ZFS a té amplifikaci to ve smartu disku hlásilo vypotřebovanou životnost i když disky stále fungovaly.

A máš správné zarovnání? A rozumně velký recordsize (viz např. https://www.percona.com/blog/mysql-zfs-performance-update/ ) ? Innodb na ZFS provozuji (optimalizované dle onoho popisu) a nepozoruji nadměrné ošoupání NVMe.


Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #46 kdy: 22. 04. 2025, 12:43:24 »
A máš správné zarovnání? A rozumně velký recordsize (viz např. https://www.percona.com/blog/mysql-zfs-performance-update/ ) ? Innodb na ZFS provozuji (optimalizované dle onoho popisu) a nepozoruji nadměrné ošoupání NVMe.

Jen pozor na jednu věc, jestli měl tazatel do teď MyISAM (počítám že i na Linuxu předtím), tak většina z těch "současných" návodů s parametry pro InnoDB nemá smysl.
Já se až do téhle diskuze chytil taky ;)

Nevím, jen jak jsem psal, prostě 10x změna v WA je divoká, pokud se skutečně změnila jen platforma (ten základ OpenZFS je víceméně stejný pro oba systémy, byť tam samozřejmě jsou trochu jiné I/O schedulery na blokové vrstvě).
Spíš bych tipoval, že tam těch změn je víc - Linux -> FreeBSD, možná verze MariaDB (tam je to taky občas divočina, mění se občas zásadní defaulty mezi desetinovými verzemi, pokud to není explicitně uvedené), taky to ZFS mohlo být trochu jinak nastavené atp.
Nicméně jestli jsem to pochopil správně, tak to stejně teď zkouší celé na FreeBSD a k tomuhle by se musel vracet.

Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #47 kdy: 22. 04. 2025, 12:54:38 »

Mě se to také nezdá. Proto o tom píši. To zničení těch disků není žádná teorie, ale skutečnost po roce provozu. Kdy díky ZFS a té amplifikaci to ve smartu disku hlásilo vypotřebovanou životnost i když disky stále fungovaly.

A máš správné zarovnání? A rozumně velký recordsize (viz např. https://www.percona.com/blog/mysql-zfs-performance-update/ ) ? Innodb na ZFS provozuji (optimalizované dle onoho popisu) a nepozoruji nadměrné ošoupání NVMe.

S recordsize jsem experimentoval, ale má to minimální vliv.  Protože když s větším recordsize zase funguje lépe komprese (to jsem si vyzkoušel i ve freeBSD), tedy rozdíl není násobný. Špatné zarovnání by to být mohlo, ale to by mělo zvýšit zápis předpokládám maximálně dvojnásobně. Všechno to doporučované ladění má jen relativně malý vliv.
Na FreeBSD mi to vychází stejně jako ostatním, výkon je to srovnatelné s ext4 podle toho jak dobře se to vyladí.
Jestli někdy přijdu na to čím to bylo, podělím se.

Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #48 kdy: 22. 04. 2025, 12:55:10 »
Díky moc za konkrétní rady. Budou se hodit. Určitě zápisy prověřím až bude vše finálně vyladěno na FreeBSD. Na Linuxu mi ZFS s hlavní databází nyní neběží, předělali jsme to na ext4, tedy budu moci tu WA ověřit příležitostně.

Nz.
Jinak na část těch testů během ladění dává smysl i virtuál (třeba QEMU/KVM na stanici, pokud máte dost paměti). Jak jsem psal, chce to zkoušet se stejnými daty z nějakého připraveného testu, u virtuálu se dá např. hezky monitorovat, co se posílá do blokového zařízení atp. Dají se simulovat nenadálá vypnutí systému a případná míra poškození (jednoduše kill -9 na konkrétní qemu proces).
Další věc je, že vám ve VM běží jen jeden daný workload, oproti celému serveru s více spuštěnými jaily (kontejnery). Což může být výhoda, pokud nemáte dané SSD vyhrazené jen na databázi, a v těch agregovaných číslech z iostatu se pak potká víc věcí.

Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #49 kdy: 22. 04. 2025, 13:12:19 »
Nevím, jen jak jsem psal, prostě 10x změna v WA je divoká, pokud se skutečně změnila jen platforma (ten základ OpenZFS je víceméně stejný pro oba systémy, byť tam samozřejmě jsou trochu jiné I/O schedulery na blokové vrstvě).
Spíš bych tipoval, že tam těch změn je víc - Linux -> FreeBSD, možná verze MariaDB (tam je to taky občas divočina, mění se občas zásadní defaulty mezi desetinovými verzemi, pokud to není explicitně uvedené), taky to ZFS mohlo být trochu jinak nastavené atp.
Nicméně jestli jsem to pochopil správně, tak to stejně teď zkouší celé na FreeBSD a k tomuhle by se musel vracet.

Přesně tak. Problém se ZFS jsem vyřešil přechodem na FreeBSD. Takže to dál již nezkoumám i když se k problému možné někdy vrátím, protože Linux používám dál pro méně zapisující databáze a jiné kontejnery.
Na FreeBSD mi ZFS funguje stejně jako ostatním.   ZFS je v pohodě použitelné i pro hodně zapisující databázi a při dobrém nastavením nemusí být Write Aplification vůbec žádná.

Nyní řeším jen optimální nastavení voleb InnoDB pro dobrý výkon tak, aby to nebylo nebezpečné pro integritu dat. Protože defaultlní nastavení způsobuje cca desetinásobně horší výkon u zápisů oproti defaultnímu nastavení MyISAM.  Kromě importu existujících dat to měřím také rychlostí jakou zastavená a znovu spuštěná replika dovede dohánět master.

Jestli tohle zničí disk jsem nezkoumal, pravděpodobně ne, ale preventivně chci zápisy minimalizovat kvůli lepšímu výkonu a menšímu opotřebení disku, což znamená menší pravděpodobnost poruch. Zbytečně nepřetěžovat stroj je vždy dobrá prevence problémů a mimo jiné to šetří třeba elektřinu. Zapsat třeba jen 5% toho co by měl disk vydržet (100 TB) za dobu osmi dost možná pomůže k tomu, že jej nikdy měnit nebudu muset.


Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #50 kdy: 22. 04. 2025, 17:07:36 »
Tazatel se asi moc dívá na nějaké zcela nezajímavé statistiky. U mne všechny disky (kromě několika Samsung 3TB) selhaly až po záruce. A vše v záruce vždy obchod vyměnil do jednoho měsíce od reklamace.

No já jenom znova uvedu statistiku svého prvního SSD disku koupeného jako v té době nejlevnější SSD disk. Kingston 64GB SSD NOW V-Series (V jako value, tedy cena, tedy nejlevnější tehdejší disk). Obrázek v příloze. Foceno dnes.

Tento disk jsem připojil v roce 2009 do svého desktopu na Windows XP 64b. Tehdy cca 40% disku byla právě ta instalace WinXP. Ok, to jsou vesměs read-only exe a dll knihovny a další read-only věci. Ten disk neumí trim, v té době se stále ještě přecházelo z EIDE na SATA a ten disk se ve WinXP choval jako HDD s 512B sektory. Ovladač převáděl IDE na SATA, v BIOSu mé desky byla jen schopnost bootovat z MBR oddílu. Takže pro OS to byl vlastně HDD a choval se k němu tak.

Dalších 60% byly moje soubory a já nejsem zrovna troškař, takže neustálé změny. Write, Read, Delete. Nonstop, přepis co měsíc. Co nepotřebuju si dávám do archivu (tehdy rar) a ukládal na 1.4MB diskety! S maximální rar kompresí se tam vešlo třeba 10MB txt souborů, a samozřejmě 1.4MB jpeg obrázků.

Zpět k tomu ssd, dodnes nevím, jaké jsou tam čipy a jaké mají erase bloky apod. Ten firmware disku se musel vyrovnat z překladem 512B zápisů do interního formátu a toto ukládat rychlostí 200MB/s na interní epromky. Bez jakékoliv pomoci od OS.

Ten disk funguje dodnes! Dodnes neztrácí data, dodnes zapisuje rychlostí 200MB/s a čte je bezpečně i po 4 letech vypnutého stavu, kdy jen leží v šuplíku. Vím to, protože od chvíle, kdy jsem zjistil co je to hash, tam mám v každém adresáři soubor sha-512.sum. Tedy nejlevnější disk se zárukou 2roky stále funguje v roce 2025 (tedy po 16 letech), kdy mám mnohem rychlejší USB3 Flash disk o velikosti 256GB.

Proto se na statistiky writebytes ani nedívám. Jen pro zajímavost. Sleduji to, ale neloguji a nedělám z toho grafy.

Tohle platí pro všechny mé flash disky a ssd. 64GB, 120GB, 128GB, 256GB a 2x512GB. Všechny fungují a všechny jsou dávno po záruce. Letos jsem si koupil první Samsung Pro 1TB NVMe disk. Jsou mu skoro 4 měsíce (nákup v lednu 2025).

Takže tento tvůj sport beru jen jako zálibu. Já mám jiné. Zjistil jsem, jak fungují databáze a proč pro ně miliarda záznamů není vůbec nic (3x seek na HDD, protože B-TREE strom má uzly o velikosti 1024 prvků, takže tři patra = 1024*1024*1024 což je přesně miliarda (binární) záznamů. V roce 2007 jsem měl v InnoDB 900 milionů záznamů na HDD. V PostgreSQL, protože vím, že jeho interní datový typ OID je 32b znaménkový, tak umí "pouze" 2mld. záznamů na databázi. Těch DB může být neomezeně. Takže můj rekord na počet záznamů v postgresql byl něco jako 16mld záznamů, kdy jsem si co nejstupidnějí (schválně) naprogramoval erathostenovo síto a záznam, jestli je nebo není prvočíslo se ukládá jako uint8 (8B). 16TB prvočísel na disku :-D.

Takže si sportuj s minimem zápisů. Každý máme jiného koníčka.nad jediný, kdo ten problém pozoroval.
[/quote]
« Poslední změna: 22. 04. 2025, 17:11:24 od Tomáš Crhonek »

Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #51 kdy: 22. 04. 2025, 19:33:46 »
Spíš bych tipoval, že tam těch změn je víc - Linux -> FreeBSD

Já bych spíš tipoval, že "chyba" bude u firmware disků a jejich implementace SMART technologie.

Vlastně skoro nikdy mě smart nevaroval nějak moc správně.

Udělal jsem si jednou taky takový Sport, kdy jsem ze všech disků, které jsme ve firmě měli a které HW raid vyhazoval na FAILED, ve smartu bylo
Kód: [Vybrat]
HEALTH: If the device reports failing health status, this means either that the device has already failed, or that it is predicting its own failure within the next 24 hours.
Tak z těchto disků (cca 32) jsem postavil BTRFS pole typu mirror (raid-1) a ono fungovalo. Nebyla tam samozřejmě produkční data, ale vše, co jsem tam uložil jsem i přečetl bez jediné chyby od BTRFS. Vlastně jsem viděl poškozených jen asi 5 z miliónů (kontrola pomocí sha512sum).

Takže počet zápisů (ze smartu, ze zpool iostat, z čehokoliv) je prostě jen číslo.

Pouze některé disky s vadnou elektronikou už ten HBA řadič ani neviděl. Ty byly skutečně vadné.

Něco zcela jiného je reklamace, TSB i Alza běžně reklamují disky výměnou do 30 dnů, pokud jim k RMA pošlu i výpis ze řadiče, linuxu, freebsd. Podle mě to nikdo (člověk) ani nečte a jen se automaticky pošle přes dodavatele a PPL nový disk. A jestli na to mají AI, které vyhodnotí, ano toto je chyba ze smartctl, tak je to jejich problém a moje výhoda. V soukromém životě už jsem takto protočil mnoho desítek disků. Včera jsem jich 16 vyhodil, dalších 16 mám na poličce a dalších 10 v serverech doma. Tj 42 funkčních HDD u mě v bytě.


mark42

  • ***
  • 150
    • Zobrazit profil
    • E-mail
Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #52 kdy: 23. 04. 2025, 15:19:56 »
Dalších 60% byly moje soubory a já nejsem zrovna troškař, takže neustálé změny. Write, Read, Delete. Nonstop, přepis co měsíc. Co nepotřebuju si dávám do archivu (tehdy rar) a ukládal na 1.4MB diskety! S maximální rar kompresí se tam vešlo třeba 10MB txt souborů, a samozřejmě 1.4MB jpeg obrázků.

V roku 2009 robit mesacne prepis/backup/archiv na 1.4MB diskety neviem ci oznacit ako odvahu, sialenost alebo nieco medzi tym. Ak to vsetky diskety prezili, tak si loto uz nemusis podavat, stastie si si minul do konca zivota :-D

Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #53 kdy: 23. 04. 2025, 17:03:39 »
V roku 2009 robit mesacne prepis/backup/archiv na 1.4MB diskety neviem ci oznacit ako odvahu, sialenost alebo nieco medzi tym. Ak to vsetky diskety prezili, tak si loto uz nemusis podavat, stastie si si minul do konca zivota :-D

No stejně jako mladí lidé dneska, já jsem tehdy neměl peníze a byl jsem rád, že mám funkční HW. Tohle bylo 1.5 roku po mojí první práci, na účtu 150tis. Kč a 10tis. Kč/měsíc hypotéka. Tohle uvádím proto, že když jsem bydlel u rodičů, tak dávat do oblálky 10 modrým bankovek měsíčně šlo. Potom jsem se přestěhoval do vlastního a měl jsem 15 obálek na 15 měsíců bydlení. Do toho druhá práce.

Takže i ta disketa se na těch 5 jpegů z prvního připojení na internet moc hodila. Potom samozřejmě DVD vypalovačka z dalších ušetřených korun (tuším 6tis. Kč).
« Poslední změna: 23. 04. 2025, 17:05:34 od Tomáš Crhonek »

Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #54 kdy: 24. 04. 2025, 00:17:53 »

15 tis. hovorů za sekundu je nic. Disky WD mají pět let záruky a tohle zvládnou bez problémů.


Tak tohle je chvástání.
15 tisíc hovorů za vteřinu by mohlo být až půl miliardy hovorů za den. Tedy třeba 1 TB komprimavných dat denně a to nepočítám overhead s updatováním indexů a podobně, což bude více než dvojnásobek.
Tolik hovorů nedá ani celá česká republika všichni mobilní i jiní operátoři dohromady.
Jeden hovor není jeden řádek v tabulce. Ale minimálně pět, nejspíše více, sleduje se celá cesta hovoru a jednotlivé SIP pakety. Je pak možné určit, kde nastal problém.
Aby to ale bylo možné, je třeba mít vyladěné nastavení InnoDB a souborového systému.

Souhlas, clovek ktery resi 15tis hovoru za sekundu je profesional ktery se nebude chodit radit do anonymniho fora…klasicky troll, spravuje databazi pro megakorporat ale jde pro radu sem…


Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #56 kdy: 25. 04. 2025, 14:36:44 »

15 tis. hovorů za sekundu je nic. Disky WD mají pět let záruky a tohle zvládnou bez problémů.


Tak tohle je chvástání.
15 tisíc hovorů za vteřinu by mohlo být až půl miliardy hovorů za den. Tedy třeba 1 TB komprimavných dat denně a to nepočítám overhead s updatováním indexů a podobně, což bude více než dvojnásobek.
Tolik hovorů nedá ani celá česká republika všichni mobilní i jiní operátoři dohromady.
Jeden hovor není jeden řádek v tabulce. Ale minimálně pět, nejspíše více, sleduje se celá cesta hovoru a jednotlivé SIP pakety. Je pak možné určit, kde nastal problém.
Aby to ale bylo možné, je třeba mít vyladěné nastavení InnoDB a souborového systému.

Souhlas, clovek ktery resi 15tis hovoru za sekundu je profesional ktery se nebude chodit radit do anonymniho fora…klasicky troll, spravuje databazi pro megakorporat ale jde pro radu sem…

Ale já jsem nikde nepsal, že mám 15 tisíc hovorů za vteřinu.  Ale že to zvládne innoDB s vhodným nastavení podle toho co píší zde. https://www.voipmonitor.org/doc/Scaling#SSDs  jeden stroj s innoDB tabulkou zvládne tohle množství hovorů zaznamenávat. Což je provoz celého státu většího než česká Repulbika. Ale ne s defaultním nastavením ale speciálním nastavením innoDB a souborového systému.  Defaultní nastavení je totiž velmi pomalé (řádově desetkrát pomalejší než default u MyISAM).
Na co upozorňuji, že ač má toto nastavení přímo obrovský vliv na výkon, jeho dokumentace je velmi slabá. Především co to udělá s integritou dat není nikde moc dokumentováno.


Jinými slovy. S dobrým nastavením to zvládne jediný výkonnější počítač (a druhý záložní). Když se to udělá špatně, mohl by si velký mobilní operátor např. ve velké Británii také postavit kvůli tomu celé nové datacentrum. A místo jednoho člověka, by to mohlo spravovat celé nové oddělení.  Rozdíl mezi špatným a dobrým fungování je v IT propastný.


Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #57 kdy: 25. 04. 2025, 14:47:26 »
Ale že to zvládne innoDB s vhodným nastavení podle toho co píší zde. Na co upozorňuji, že ač má toto nastavení přímo obrovský vliv na výkon, jeho dokumentace je velmi slabá. Především co to udělá s integritou dat není nikde moc dokumentováno.

Souhlas. Pokud vytvoříš lepší dokumentaci, třeba klidně v češtině, tak může vyjít článek zde na rootu. Jdi do toho, to myslím vážně. Takový článek by tady patřil a mohl se bys připojit vedle Pavla Štěhuleho, který tady má hromadu článků o PostgreSQL. Ty můžeš být druhý autor o InnoDB (v MySQL / MariaDB, dle tvého přání).

Rozdíl mezi špatným a dobrým fungování je v IT propastný.

Souhlasím, ale taky je to o hranicích. Pokud mi všechny moje SSD od roku 2010 dodnes přežily všechny moje totálně megalomanské pokusy (můj IT sport), tak vím, že řešit jeden parametr (zpool iostat -v 1) vůbec nemá smysl. Ano, může se to logovat a dělat z toho grafy. Já je nedělám.

Včera jsem si postavil hybridní pole (BTRFS, 500GB SSD + 120GB SSD, metadata dup, single data) a přenesl tam svých 600GB RAWů z fotáku Canon 50D (2008). Na BTRFS stats jsem se ani nepodíval. Jen opět zkontrolovat zda souhlasí všechny sha-512 sumy. Což souhlasí i dnes. Přečíst to celé trvá rychlostí 450MB/s jen pouhých 300s (5 minut). Nepotřebuju mít grafy životnosti disků, které už nemají 5 let záruku, protože zkontrolovat validitu dat je do 5 minut!


Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« Odpověď #58 kdy: 25. 04. 2025, 15:10:45 »
Včera jsem si postavil hybridní pole (BTRFS, 500GB SSD + 120GB SSD, metadata dup, single data) a přenesl tam svých 600GB RAWů z fotáku Canon 50D (2008). Na BTRFS stats jsem se ani nepodíval. Jen opět zkontrolovat zda souhlasí všechny sha-512 sumy. Což souhlasí i dnes. Přečíst to celé trvá rychlostí 450MB/s jen pouhých 300s (5 minut). Nepotřebuju mít grafy životnosti disků, které už nemají 5 let záruku, protože zkontrolovat validitu dat je do 5 minut!

A tam jsou jen ty rawy, jen za včerejšek dalších 360MB RAWů. Jeden exportovaný obrázek už je na mém serveru u Hetznera.

https://www.heronovo.cz/vcerejsi-bourka-nad-olomouci/