Příspěvky

1

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 18. 04. 2025, 19:49:10 »

Pokud bych nechtěl opouštět mariaDB/Mysql, tak lze použít MyRocks místo innoDB. Chlubí se že má až 10 krát menší zápisy, je optimalizovaná na SSD, měla by umět partitioning a data obsahují několikanásobně méně místa na disku díky efektivní kompresi. Jak je to ale odolné proti výpadkům elektřiny jsem nenašel.
Jedinou zmínku co jsem našel byla.

MyRocks (MariaDB only)   Designed for write-heavy workloads, MyRocks is optimized for crash resilience but might not be suitable for all use cases.

Jestli má MyRocks a Aria stejné nedokumentované nedostatky jako MyIsam co se týče paralelního čtení a zápisů se nelze nikde dočíst.

2

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 23:42:03 »

Jo a postgresa instaluj z postgresql.org, anzto tuto verzi podporuji originalni timescale baliky
V distre h byva postgres i timescale, ale jenom v pure OSS variante, ktera je orezana a neumi komprimaci. Potrebujes community versi, to je mezistupen mezi pure OSS a komercni variantou

Používám teď FreeBSD, ti na to mají automatizovanou kompilaci/balíček https://www.freshports.org/databases/timescaledb/
Je to ta verze s podporou komprimace? Předpokládám, že by to mohla být ta comunitty (TSL) protože freebsd nemá takové problémy s licencemi.  Mají tam napsáno licence Apache TSL. No mělo by se to poznat minimálně podle toho odkud a jaké zdrojáky to stahuje.

3

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 23:09:48 »

Mám ZFS, takže některé ochranné prvky, které dělá innoDB jsou zbytečné, protože jsou dělány na úrovni souborového systému.

ZFS je dost pomalý filesystém - a při velké zátěži jsou s ním s databázemi problémy.

To by mohl být jeden z důvodů, proč pozoruji při přechodu na innoDB takové zpomalení zápisů.
Pod Linuxem ZFS nebylo použitelné ani s innoDB, vznikala tam write aplifikace a kromě špatného výkonu to ničilo disky. Tedy používal jsem ext4. Byl jsem pak překvapen, že na FreeBSD se stejným hardware najednou problémy nebyly. A ZFS fungovalo s MyIsam dobře.

MyISAM neřeší konzistenci - zápisy končí ve filesystémové cache - a v případě havárie můžete příjít o data z filesystémové cache - což vzhledem k primitivnímu formátu nemusí být problém - můžete mít ale nakopnutý index, a to už problém být může.

Potvrzuje to je pravda. Ale index menší tabulky lze celkem snadno a rychle jednou za 5 let případně opravit. Stejně tak oprava tabulky jednou za 5 let je relativně rychlá. Větší tabulka se skládá s partition. Mohu to rozbít a opravit jen tu poškozenou, což je také rychlé. Navíc také tu poškozenou mohu přejmenovat a nahradit ji  novou prázdnou.
Celý systém tak v době opravy může běžet bez problémů.

InnoDB má mnohem složitější formát a pokud by došlo ke ztrátě konzistence, tak to není jen o ztrátě pár záznamů.

Myslím že máte pravdu. Když se InnoDB pokazí je to horší a často je lepší začít obnovou ze zálohy.

ZFS vám pomůže jen v tom, že si můžete udělat snapshot a vrátit se k nějakému snapshotu.
Pokud by se ale rozbila konzistence v MySQL, tak je vám ZFS na dvě věci. InnoDB má na rozdíl od MyISAM vlastní write cache - o kterou v případě havárie můžete přijít, a tak musíte mít konzistentní transakční logy. Pokud byste je neměl, tak to, že přijdete o pár záznamů je to nejmenší - můžete mít nakopnutý index, což rozbije vyhledávání - unikátní index nemusí být unikátní, atd atd. MyISAM je do jisté míry "inmemory db", takže některé operace mohou být velice rychlé. Má velice primitivní formát - který je relativně odolný vůči chybám. InnoDB funguje už úplně jinak, a případné chyby konzistence v InnoDB mají mnohem horší dopad.

Ano souhlasím.   Řešením by mohlo být na hlavní databázi nepoužívat ZFS, aby se snížila režie zápisů. Nebo  prostě zvolit vhodný kompromis nastavení. Ale jak přesně jej vybrat?  Také by mohla být možnost,  na hlavní databázi zůstat na MyIsam a pro jakékoli náročnější čtení používat jen neblokující repliky s innoDB, které ale nebudou odolné vůči havárii. Ale může jich být více a jdou relativně snadno znovu nahodit, když se data poškodí. Např. se vrátím k poslednímu snapshotu před havárií a během pár vteřin replika všechno dožene do aktuálního stavu.

4

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 22:42:02 »

A já nemusel databázi startovat z několik minut starého snapshotu nad ZFS, protože z dat hlavní databáze se stala neopravitelná fašírka.

Nechci býti kverulant, ale to, co s daným nastavením bude na tom ZFS snapshotu patrně bude neopravitelná fašírka taky, jen o 10 minut starší.

Připojuji se k předřečníkovi - fakt tušíte, co děláte?

Snapshot je velmi rychlá operace. Na tak krátkou dobu si mohu dovolit zamknout všechny tabulky a flushnout všechno na disk. Po tu velmi krátkou dobu by měly být blokovány další zápisy, ale nikoli čtení. Tedy pokud to innoDB podporuje. Pak snapshot nebude rozbitý.  S MyISam s tím problém nebyl.

5

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 22:34:04 »

tak, pokud data nepošleš na disk, těžko ti pomůže zfs .

Např. na ZFS mohu vypnout double write, protože zfs je copy on write a tak se nemůže stát, že něco se zapíše jen napůl.
Také mohu vypnout checksumy.

Kde ty dokumentace vůbec hledáš? Vždyť za ty roky má innodb popsané snad všechny varianty.
Pokud chceš, aby ti zápis neblokoval čtení, tak hledej věci jako dirty ready (READ UNCOMMITTED v innodb).

Mě je ale úplně jedno co mi vrátí select. Tedy jestliže nejnovější zápisy v poslední vteřině vynechá nebo nikoli, nebo je vynechá jen někdy. Důležité je jen to, aby to běželo rychle a efektivně a čtení se zápisy neblokovalo navzájem. Tedy nevím kterou variantu si mám vybrat.

Z tvých experimentů a nastavení mám špatný pocit, vypadá to, že prostě nevíš co děláš. Např. innodb_doublewrite=0 je skvělé, ale v takovém případě musíš na zfs nastavit innodb_log_write_ahead_size na ideálně dvojnásobek page_size, aby nedošlo k částečnému zápisu.

Na tohle jsem nikde nenarazil.  Pokud to někdo nastavuje tak na 16K, ale přitom nenastavuje page_size.

Nastavit innodb_buffer_pool_size na 40G je šílenost.

Na více místech radí, že to má být 70-80% paměti co je k dispozici. Stroj má 64 GB.

Že různí lidé na internetu radí různé věci na mne dělá dojem, že je to opravdu špatně dokumentované.

Podotýkám, že na replice vůbec nejde o bezpečnost dat, protože je to už kopie. A repliku mohu kdykoli obnovit z jiné repliky, co běží na jiném stroji.
Na hlavní databázi, až s ní přejdu také na innoDB, by byla dobrá vlastnost, aby to výpadek elektřiny/pád systému přežilo a po nastartování to mohlo ihned pokračovat. Možná ztráta dat za několik vteřin před pádem není vůbec podstatná.  Navíc se dá obnovit z replik a kdyby se nějaký záznam náhodou neobnovil, tak se celkem nic neděje.

6

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 21:09:40 »

Mno, nebylo receno o jaka data jde, lec kdyz je rec o mozne ztrate 20 vterin dat, asi pujde o nejaky time-series.
A na to je v postgresu extenze TimescaleDB, ktera ma luxusni vlastnosti vcetne automatickeho komprimovani time-series dat, vysledek je ze zabere na disku cca 10% mista. Resi problematiku ruchleho zapisu.
K tomu patroni cluster a prohledavani dat a backup resit na online replice.

Jedná se o telefonní hovory. TimesclaDB vypadá, že by  mělo jít použít i když to není úplně typický případ a nenašel jsem žádný příklad, že by to někdo používal na ukládání hovorů.  Každý hovor má hodně atributů. Nejdůležitější je čas, linka, uživatel, volající, volané číslo, délka, délka zvonění,destinace, cena. A spousta dalších méně důležitých atributů.

Asi by to chtělo ze začátku ukládat tím starým způsobem a navíc i do TimescaleDB. Mohu tam také zkušebně nalít ty data zkusit jestli se operace výrazně zrychlí. V každém případě by to byl dost velký zásah v porovnání jen se změnou z MyIsam na InnoDB.

7

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 12:25:24 »

Mám ZFS, takže některé ochranné prvky, které dělá innoDB jsou zbytečné, protože jsou dělány na úrovni souborového systému.
Zatím innoDB používám jen na replice hlavní databáze.  Replik je několik.   Tedy věci jako ACID a ochranu v případě výpadku elektřiny nepotřebuji, protože v nejhorším případě si repliku nahodím znovu.
Ale potřebuji maximální rychlost zápisu a malé opotřebení SSD disků. Rychlé čtení se také hodí.
A hlavně aby čtení neblokovalo zápis a zápis čtení jako je to u MyIsam. Žádné další "výhody" innoDB nepotřebuji, protože zdržují a opotřebovávají disky a pro můj use case nejsou potřeba.

Pro hlavní databázi, až budu dělat přechod na innoDB bude nejspíše to stejné jen s tím rozdílem, že v případě výpadku elektřiny nechci aby se databáze úplně rozbila, ale nevadí mi, že přijdu např. o posledních 10 sekund zápisů.
Ale potřebuji, aby tabulky byly v použitelném stavu po nastartování se mohlo pokračovat. A já nemusel databázi startovat z několik minut starého snapshotu nad ZFS, protože z dat hlavní databáze se stala neopravitelná fašírka.


Je spousta použití databází, kdy ACID není středobod. Ale dobrý výkon a rychlost, nízké opotřebení a možnost paralelního čtení a zápisů ano. Bohužel k takovému použití jsem moc dokumentace nenašel.  Možná nezbude než experimentovat. Vytvořit si repliku, které občas "vypnout proud" a zkoumat stav databáze.  Jestli se občas stane, že z dat zbude jen nepoužitelné fašírka nebo nikoli. Nebo tabulky budou vyžadovat opravy v řádech hodin nebo dokonce dnů. Ztrát některých zápisů v poslední minutě před vypnutím elektřiny mne netrápí.

8

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 16. 04. 2025, 23:47:11 »

Je rychlost zápisu velmi podobná jako u myISAM.  Tedy další špatně dokumentovaná nevýhoda innoDB je, že defaultní nastavení je mnohonásobně pomalejší pro zápis, což je ale možné vyladit vhodným nastavením.

Nezlobte se, ale to není ani nevýhoda, ani špatně dokumentovaná. Možná před pokusy byste si měl přečíst alespoň tohle https://dev.mysql.com/doc/refman/8.4/en/mysql-acid.html
To, co jste udělal je, že jste v podstatě vypnul integritu nad databází, kterou InnoDB nabízí (přesnější popis najdete v dokumentaci).

Asi něco (velmi volný příklad) podobného, jako kdybyste u diskového pole zapnul zápisovou cache bez baterky, a stěžoval si, že pole bez toho zapisuje pomalu.

Já ACID nepotřebuji. Proto jsem tak dlouho zůstal u MyIsam. A nyní se ukazuje, že InnoDB umí velkou část těch dobrých  věcí jen za cenu podstatné snížení rychlosti zápisů. Ale naštěstí to jde vypnout a tím tuto  špatně dokumentovanou nevýhodu innodB  (pomalost zápisů) eliminovat. Všichni ti co píší o výhodách InnoDB zapomínají zmínit, že je to  za cenu pomalejších zápisů. Ale lze najít vhodný kompromis nastavením.
Z vlastností innoDB potřebuji jen to, aby zápisy nečekaly na dokončení předchozího čtení a následující čtení zase na dokončení předchozích zápisů. Zápisy jsou obecně rychlé, ale v myIsam čekají na dokončení předchozího čtení. Tedy jeden náročnější select dovede zamčít celou tabulku pro všechny operace, pokud se v jeho průběhu vyskytne nějaký zápis.

9

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 16. 04. 2025, 23:32:53 »

A když už do toho hrabete, nechcete to předělat rovnou na postgresql?

O tom jsem přemýšlel. Ale pokud vím postgreSQL vyniká hlavně  v konzistenci a pokročilém použití. Já spíše potřebuji jen hrubou rychlost a funkčnost 24/7 na což postgreSQL zas tak dobrý není. Pokud by se mi ztratil náhodně jeden záznam z milionu, netrápí mne to. Stejně tak mne netrápí kdybych např. při výpadku elektřiny (počítám že by se mohlo přihodit jednou za 10 let) přišel třeba o 20 vteřin dat. Naopak kdybych musel někdy v noci opravovat či optimalizovat nějakou tabulku třeba půl hodiny a proto ji uzamčít, je to velký problém.
A taky se mi nechce učit nic nového, když vlastně nevím jestli bych si vůbec polepšil. Spíše nikoli.

Od MyISam odcházím z toho důvodu, že zápisy blokují následující čtení.    Tedy pokud bych měl dva delší selecty, mohou probíhat paralelně bez problémů, pokud mezi nimi nebyl žádný zápis. Ale pokud v okamžiku delšího selectu přijde zápis, tak ten čeká na dokončení selectu. A následující select zase čeká na dokončení toho zápisu, takže se to celé ucpe jen kvůli jednomu delšímu selectu.  To by mělo innodb vyřešit.  Pokud by ale existovala možnost nastavit u MyIsam, že má zápis menší prioritu než čtení a zápis by čekal až na okamžik, kdy není žádný požadavek na čtení, mohli bychom dále používat myIsam. Zápis je totiž  v našem případě vždy rychlý. Ale bohužel změnit tu prioritu se mi nepovedlo.

10

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 16. 04. 2025, 23:16:37 »

Vypadá, že s tím není problém a budeme tak mít možnost si vyzkoušet právi s inodbt a přesvědčit se, že např. nepoužíváme nějaké dotazy, které by byly na inoddb výrazně pomalejší.

A jak zjistujete kolik ktery dotaz trva? Jako jiste, lze to logovat na aplikacni vrstve, nez to vleze do konektoru, ale.. ten netusi nic o vytizeni DB a zda je tam s dotazem sam, nebo se jich tam provadi paralelne stovka, takze tento zpusob muze/bude produkovat false positives.

Já to měřím jinak.  Databáze s innoDB replikuje všechny zápisy na hlavní databázi, která má stále MyIsam.
Pokud chci měřit to, jak rychle fungují zápisy na clonu, tak clonování zastavím třeba na deset minut.
Po  deseti minutách klonování opět rozjedu a sleduji jak rychle slave dohání master databázi.
Slave v závislosti na svém nastavení a rychlosti fungování zápisů je schopen za jednu vteřinu skutečného času dohnat 0-150 vteřin.  V nejhorším případě se zpoždění dále zhoršuje, protože replika nestíhá. V nejlepším případě za 1 vteřinu dožene 150 vteřin skutečných zápisů. Tedy 10 minut dožene za cca 4 vteřiny.

Měřím tak jen rychlost zápisů, nikoli čtení. A samozřejmě musím brát v potaz dobu, kdy měření provádím, např. v noci je zápisů na hlavní databází méně, takže to nemohu porovnávat s počtem zápisů např. ve všední den dopoledne.

Tímto způsobem mohu měřit množství zapsaných dat na disk a tedy i opotřebení SSD disků a jak se to mění s různou konfigurací jak ZFS tak databáze samotné. Při špatném nastavení je možné méně kvalitní SSD disky zničit za jediný rok, při dobrém nastavení jsou to teoreticky až desítky let.
V reálném čase mohu porovnávat množství zapsaných dat dvou různých replik hlavní databáze s různou konfigurací.

11

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 16. 04. 2025, 23:03:36 »

Po přidání následujících hodnot do server.cnf je rychlost zápisu do innoDB tabulky srovnatelná s rychlostí u myISam s defaultním nastavením.

Kód: [Vybrat]

innodb_file_per_table = ON
innodb_doublewrite = 0
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 5
innodb_buffer_pool_size = 42949672960

thread_stack = 256K

sync-binlog = 0

Je rychlost zápisu velmi podobná jako u myISAM.  Tedy další špatně dokumentovaná nevýhoda innoDB je, že defaultní nastavení je mnohonásobně pomalejší pro zápis, což je ale možné vyladit vhodným nastavením.

12

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 16. 04. 2025, 13:23:14 »

Replikace databáze myIsam -> InoDB už běží.   Pokud replikaci zastavíme, má co dělat, aby to vůbec dohnala. Tedy pro zápis je pomalejší na stejném hardware s defaultním nastavením řádově tak 80 krát oproti myIsam.  Zabíjí to hlavně ty commity po každé transakci. Upravím nastavení innodb a dám vědět jak se to zlepšilo.

Že je jen přechodem z myIsam na InnoDB dosáhnout řádově až 100 násobné zpomalení zápisů, je pro mne také překvapující. Nikdo z těch co porovnávali  innoDB s MyIsam to nezmínil. Předpokládám ale, že to půjde vyladit.  Na replice by nám mohl stačil commit klidně jednou za 5 vteřin, ale není jisté jestli se to dá až takto nastavit.

13

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 16. 04. 2025, 12:46:49 »

Máme replikaci master-slave. Na master používáme zatím myisam. Chci přejít na inodb. Takže jsme provedli export přes mysqldump s tím, že import provedeme do inodb (používá se tam partitiong - funguje to jinak než v myisam) a dále pustíme replikace, aby se myisam ve zkušební době replikovala do inodb a mohlo se nanečisto vyzkoušet.
Vypadá, že s tím není problém a budeme tak mít možnost si vyzkoušet právi s inodbt a přesvědčit se, že např. nepoužíváme nějaké dotazy, které by byly na inoddb výrazně pomalejší.
Záloha by měla stačit přes zfs snapshot, ale mít možnost zálohu vytvořit a obnovení provést pomoci mysqdump jsem považoval také za dobré. Např. pro přechod na mnohem novější verzi databáze a podobně si člověk netahá s sebou možné náhodné chyby na binární úrovni. Prostě začít úplně nanovo. Ale není to moc použitelné, je třeba do toho ručně zasahovat, aby se obešli z mého pohledu nedokonalosti inodb. Např. ani nemohu obrovskou tabulku importovat v jednom kroku, nebo se mariadb úplně kousne. Po měsících to jde, ale trvá to moc dlouho, takže se to musí ručně optimalizovat.

Ideálně bychom potřebovali něco jako mysqldump, která ale bude podporovat manýry inodb.

14

Server / Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 16. 04. 2025, 10:24:46 »

Jaké má výhody inodb oproti myisam se píše všude možně.
Nyní se testuji přechod na myisam a nárážím na podstatné nevýhody inodb, o který se ale téměř nikdo nezmiňuje.

Začal jsem tím, že pomocí mysqldump jsem provedl export databáze.
Import ale netrval cca dvě hodiny jako u myisam, ale celý víkend.

Problém je v tom, že inodb nepodporuje ALTER TABLE DISABLE KEYS, které použije mysqldump pro zrychlení importu.

To že  ALTER TABLE DSIBLE KEYS funguje jen na zastaralé myisam je jaksi špatně zdokumentováno jen tak mimochodem, jako by to bylo něco nepodstatného.

Výsledek je že se updatují klíče po každém INSERT, což operaci hrozně zpomaluje a ničí se při tom disky. 

Zrychlit import  lze také provedením příkazů před importem:

Kód: [Vybrat]

SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;

Po importu

Kód: [Vybrat]

COMMIT;
SET unique_checks=1;
SET foreign_key_checks=1;

Dobré řešení je vytvořit tabulku bez indexů. Nalít tam data a indexy vytvořit až úplně nakonec.
Ale zdá se takový postup mysqldump nepodporuje a nezbývá než ručně editovat SQL příkazy, aby se indexy vytvořili až po importu. Což je krajně nepohodlné.
Existuje nějaký elegantnější způsob jak obnovit databázi ze zálohy, aby se rychlost alespoň řádově blížila běžné rychlosti tabulek myisam?

Překvapuje mne, že mysqldump nemá na takové použitý vůbec volby. A nemá volby ani na to, aby každou tabulku ukládal do jiného souboru (strukturu a data zvlášť), aby bylo možné ruční zásahy dělat snadněji.

Jaké další nevýhody a nedodělky má inodb o kterých se běžně nepíše?

Existuje něco lepšího než mysqldump, který by lépe pracoval s nedostatky inodb?

Předpokládám, že nikdo nechce čekat desítky minut nebo dokonce dny na obnovení databáze ze zálohy na novém stroji úplně zbytečně.

15

Server / Re:Zvažuji přechod z Linuxu na FreeBSD

« kdy: 15. 04. 2025, 23:19:41 »

Chtěl jsem si vyrobit vlastní jls, který bude uvádět ip adresu i pro vnet a také bude zobrazovat příznat autostart pro různé jaily.  Ale objevil jsem již hotový skript, který se jmenuje jmore.

https://vermaden.wordpress.com/2024/11/22/new-jless-freebsd-jails-list-manage-tool/

https://github.com/vermaden/jmore

Aby ti fungovalo i pro mne, tak jsem udělal dvě drobné úpravy.

Na řádku 157 a podobných dalších jsem přidal "/jails/*/config.conf \" aby to prohledávalo mé konfiguráky k jednotlivým jailům, co nemají standardní umístění.

A úplně nakonec jsem vložil:

Kód: [Vybrat]

echo -n "autostart:"
sysrc -n jail_list

Což vypíše jaily, které mají nastavený automatický start při nastartování systému.

jmore nyní vypíše např.:

Kód: [Vybrat]

JAIL       JID  TYPE  VER        DIR                      IFACE      IP(s)
----       ---  ----  ---        ---                      -----      -----
jail1      3    vnet  14.2-R     /jails/jail1/rootfs      epair154b  192.168.164.154/24
jail2     11    vnet  14.2-R     /jails/jail2/rootfs      epair156b  192.168.164.156/24
jail3      5    vnet  14.2-R-p3  /jails/jail3/rootfs      epair155b  192.168.164.155/24
autostart:jail1 jail2 jail3

Tedy přesně jak bych si to představoval. Ukazuje to navíc verzi a patchlevel FreeBSD. Líbí se mi, že je to jednoduché a kdybych chtěl vypisovat i něco dalšího, dá se to snadno upravit.

FreeBSD je top právě v té jednoduchosti ! Když si chce člověk něco upravit, tak se v tom nezahrabe.