Fórum Root.cz
Hlavní témata => Server => Téma založeno: xsouku04 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:
SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;
Po importu
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ě.
-
Pffff ....představa, že se ve dvě ráno hrabu v databázi, aby se vůbec stihl import, mě docela děsí...
-
existuje, replikace, např. galera a wsrep, obnova databáze trvá tak rychle jak jsme schopní na disk nalít data, tj. v našem případě rychlostí 3 GB/s. Backupy jsou pak kontinuální.
Mysqldump a import přes sql jsem neřešil roky. Používali jsme vždy bulk query, vypnout contraints je sice super, ale hodí se to jen tehdy, když importuješ do prázdných tabulek.
-
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.
-
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.
-
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.
Koukněte na mariadb-backup popř. xtrabackup z Percony - používat mysqldump na zálohu čehokoliv většího než blogííííšek je docela hardcore.
BTW ten problém s klíči není kvůli tomu, že innodb je hloupá, ale že na rozdíl od myisam je transakční, takže si nemůže dovolit čuňárny, které používá právě mysqldump k urychlení importu. Binární backupy/restore tohle řeší.
-
Tady může být jiné úzké hrdlo - ZFS je přece COW filesystém. Zkusil bych COW vypnout pro databázi, je-li to možné.
Nepíšeš ještě jak veliká ta DB je a jak rychle se zapisuje. Měl jsem různě veliké DB s InnoDB a replikací - jedině, kdy to déle trvalo bylo dohnání master na začátku, pak nebyl problém.
-
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.
-
A když už do toho hrabete, nechcete to předělat rovnou na postgresql?
-
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.
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.
-
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í.
-
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.
-
Taky tohle https://stackoverflow.com/a/3818773
-
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.
-
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.
-
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.
Uprimne, tohle plne plyne z teorie.
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.
Pak kouknete sem, tohle Vam muze dost pomoct.
https://dev.mysql.com/doc/refman/8.4/en/innodb-transaction-isolation-levels.html
-
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.
nevím, proč máš opakovaný problém poukazovat na špatnou dokumentovanost, naopak je to dokumentované poměrně jasně.
Pokud používáš ext, mrkni ještě na O_DIRECT_NO_FSYNC, zrychlí ti to zápis.
Mysli na to, že všechny tyhle nastavení ti snižují spolehlivost ukládaných dat, pokud se něco rozbije, musíš tabulku opravovat, to může způsobit velké výpadky, ztráty dat.
Cest jak celý innodb engine udělat velmi rychlý je mnoho a nemusí se vypínat věci, které snižují spolehlivost.
-
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í.
-
tak, pokud data nepošleš na disk, těžko ti pomůže zfs :).
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).
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. Nastavit innodb_buffer_pool_size na 40G je šílenost.
-
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?
-
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.
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.
-
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.
-
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. 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. 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ů. 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.
-
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.
jednodusene receno, timescale je parttitioning na steroidech. Pokud mas atribut, podle ktereho to muze data rozsekat na chunky, typicky cas, a pokud tcoje dotazy typicky dotazuji pres casova okna, hodne ti to pomuze.
PoC mas hotovy za den, pgloaderem natahej mysql data vcetne komplet steuktury do postgresu, ty velke datove tabulky zkonvertujj na timescale hypertabulky s kompresi treba pro tyden stare chunky. Co zkomprimujes uz neupdatujes, to ale v tvym usecase nevadi.
Hylertabulka je z pohledu klienta pro CRUD transparentni.
Hlavni prinos je hlavne v tom chunkovani, postgres pracuje jenom s prave potrebnymi chunky a i mazani starych dat se dela zahazovanim chunku bez nutnosri transakcniho delete.
A pri instalaci nezapomen na timescaledb-tune, tahle utilitka ti poladi konfigurak postgresu
-
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
-
Jo a nezapomen pak i na to patroni, kde bude leader urcen ciste pro zapisy a cteni backup dat apod na replikach.
jako bonus k tomu dostanes HA setup.
Pomoci haproxy nebo pgbounceru s externim chckem leadera si vystavis port pro zapis na 6543, port pro ciste cteni z repliky na 7432 a tvoje aplikace nemusi zadne prepinani nijak resit, staci aby umely reconnect spadle konexe
-
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.
-
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.
-
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.
-
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.
-
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.
Ten port sa kompiluje buď s Apache, alebo TSL licenciou. Štandardne je TSL zapnutá, takže aj balíček bude v tejto verzii.
Vidieť sa to dá v https://cgit.freebsd.org/ports/tree/databases/timescaledb/Makefile (https://cgit.freebsd.org/ports/tree/databases/timescaledb/Makefile), konkrétne v častiach
OPTIONS_DEFAULT= SSL TSL
a
TSL_DESC= Enables TSL licensed code in additon to Apache license code
-
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.
-
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.
MyRocks by mělo být postavené nad RocksDB - https://github.com/facebook/mysql-5.6/wiki/Getting-Started-with-MyRocks
rockdb podporuje neblokujici snapshoty - tudiz by cteni nemelo blokovat zapis https://github.com/facebook/rocksdb/wiki/rocksdb-faq
-
Ach jo, za ta tvoje starost o životnost disků ... :)
V PostgreSQL jsem importoval 90GB databázi (z textového SQL souboru příkaz po příkazu takto):
Nainstaluji nový PostgreSQL nové verze. V nastavení nastavím fsync=off. Zapnu Postgres službu.
Pomocí příkazu psql naimportuji tu 90GB databázi, na moderním NVMe disku rychlostí klidně 2GB/s, tedy za 45 minut.
Potom opět vypnu službu postgresql, změním nastavení fsync=on. Zapnu postgresql službu.
Import 90GB DB ze souboru trvá i s uvařením kávy 1h reálného času. A ještě jednou připomínám, pro standardní běh je extrémně důležité mít fsync=on!
ZFS je ok, BTRFS je ok, snapshoty jsou OK a klidně tam mohou zůstat několik let. Na běžný provoz PostgreSQL to nemá žádný vliv, na moderním NVMe je běžný počet commits per seconds 100tis.
A životnost disků i po plné práci celý víkend (s fsync=on) je více než 5 let záruky (Samsung Pro řada).
Takže pokud ten NVMe disk odejte den po záruce, dá se klidně za 10tis. Kč koupit nový, větší a výkonnější.
Moje první SSD, které jsem si koupil v roce 2007 a má 60GB stále funguje. Dodnes. Stále má 200MB/s a stále cca 5000iops. Což tehdy byla špička. Takže i po 18 letech drží data. Pochopitelně dneska už není v produkci, tak mám Samsung Pro NVMe.
-
Jedná se o telefonní hovory.
Sorry, ale tohle tady opravdu řešíš už více než rok? Pro koho pracuješ? TMOBILE, O2? Tam opravdu nemají datacentrum storage grade disky s automatickou výměnou do 4h od selhání, což je v běžných datacentrech zvykem?
Těch metadat (kdo kdy komu jakdlouho volal) vůbec není moc. Takže tohle zvládne jak InnoDB, tak i PostgreSQL, který je naopak přesně stavěn na nonstop provoz 24/7 (ve firmě, kde jsem pracovat od 2008 do 2019) měl PostgreSQL databázový server uptime 6 let a služba běžela 6 let nonstop!!!).
Kdejaké datacenter grade nvme disk umí až dva miliony iops. Opravdu máte v nějaké malé firmičce tolik hovorů a opravdu to musíte ukládat na nejlevnější disky, které odejdou za rok?
Vůbec nic z tvých diskusí nedává smysl. Úplně všechno, na co se tady dva roky ptáš je vyřešeno před 20 lety. Stačí to jen nainstalovat na normální serverový hw a ty disky tam vydrží 6 let záruky a dodavatel diskového pole je při selhání chodí sám do 4h vyměňovat. A je tam několik náhradních disků, takže když selže jeden disk zrovna zítra ve státní svátek, tak tam někdo přijede v úterý. Datům se nic nestane a výkon zůstane stále stejný.
Tohle má každý telefonní operátor vyřešeno příslušnou technologií už od sedmdesátých let. I u nás český telekom ještě v době analogových linek byl schopen dodat výpis hovorů - tehdy vytištěné na jehličkové tiskárně!!!
Takže CO VLASTNĚ ŘEŠÍŠ?
-
Reaguji na to co napsal Tomáš Crhonek.
Pod pojmem SSD Samsung pro mi to najde jen tohle https://www.alza.cz/samsung-990-pro-1tb-d7516911.htm
Což není ani serverový disk. Já používám tohle https://www.alza.cz/wd-red-sn700-nvme-1tb-d6998050.htm
Kapacita 1TB, životnost 2000TBW. Tedy disk lze cca 2000 krát přepsat. Dříve to byly disky s kapacitou 512 GB s životností cca 600 TBW. Všechny disky vydržely to co měli v popisu.
Oni jsou to ale dva různé problémy. Jeden problém byl v tom, že ZFS mělo v mém případě více jak desetinásobnou write applification oproti tomu, jakou by mělo mít dle všech pouček a návodů.
To jsem nyní vyřešil přechodem z Linuxu na FreeBSD. Tam to na stejném hardware a při stejném zatížení prostě nedělá. Přechod na FreeBSD má i další podstatné výhody, např. že mi přijde že ve FreeBSD je vše jednodušší a lépe zdokumentované, tedy nemám už potřebu příliš zkoumat, kdy přesně a proč se to násobné zapisování v Linuxu vyskytuje.
Druhý problém na který jsem narazil a který z prvním souvisí jen okrajově a o kterém je tohle vlákno je ten, že při defaultním nastavení innoDB jsou zápisy více jak 10 krát pomalejší než než u defaultního nastavení MyISAM.
Výsledek je, že když importuji CSV soubor do nové databáze se 264 milióny záznamy, tak na to místo dvou hodin potřebuji celý víkend. Rozdíl je možné srovnat vhodným nastavením innoDB. Změna nastavení nespočívá ve vypínání sync!
Pokud by zkombinoval ZFS write amplification a neoptimální nastavení databáze, zničí to v mém provozu pravděpodobně i ty nejlepší disky a poběží to pomaleji, než kdyby databáze jela na deset let starém hardware. Řešit to lepším hardware je nesmysl.
MySQL/MariaDB neumožňuje vypnout sync, píše se, že tato možnost je jen pro testování. To bych mohl vypnout jen nastavením ZFS, aby ZFS sync jen předstíralo. Což ale není nutné i když u repliky databáze by to nijak nevadilo, ta se dá za pár minut nahodit znovu z posledního snapshotu.
Ostatní změny nastavení InnoDB konzistenci dat tak zásadně neohrožují. Např. z toho, že se provádí automatický comit po každém jednotlivém přidání záznamu, žádná výhoda neplyne, jen je vše mnohonásobně pomalejší.
Např. zde je návod jak nastavit InnoDB pro monitoring hovorů. Nastavení je docela brutální, ale brutálně to také zvýší propustnost a sníží zápisy na disk. S tímto nastavením to zvládá ukládat více jak 15 000 hovorů za vteřinu (CPS =calls per second). A to každý hovor vyžaduje více záznamů!
https://www.voipmonitor.org/doc/Scaling#SSDs
Ze zkušenosti vím, že pravděpodobnost, že budou data po výpadku elektřiny nebo pádu kernelu poškozena i při tomto nastavení, není velká.
Jaký přesně mají vliv jednotlivé parametry, i když je to věc naprosto zásadní, zůstává nedokumentováno.
Budu nucen si to nějak vyzkoušet např. vypínáním elektřiny nějakému klonu a zvolit vhodný kompromis.
V případě poškození dat je vždy možné se vrátit v čase 5 minut a začít od posledního snapshotu, což není žádná katastrofa. Navíc zápisy v mezičase budou uchovány na klonech, tedy je možné je doplnit později.
Kdykoli čtu srovnání MyIsam a InnoDB, vždy se píše o výhodách InnoDB, ale to že je v InnoDB defaultně cca 10 krát pomalejší pro zápis, v podstatě vždy zapomene propagátor zmínit. Porovnávám výkon v defaultní konfiguraci. InnoDB je možné zrychlit na úroveň MyISAM, ale důsledky pro bezpečnost dat nejsou řádně dokumentovány. To je pro mne dost překvapivé, když jedním z hlavních výhod InnoDB má být lepší bezpečnost dat a fakt, že se tabulky opraví sami, rychle a plně automaticky.
-
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.
-
U toho write amplification, o kterém často píšete, se mi to upřímně moc nezdá.
Resp. může se to samozřejmě vymknout z kloubů v nějakých specifických situacích (kdy máte např. nějaké šílené zarovnání a dělá vám to hromadu zbytečných RMW cyklů, nebo máte např. zvol, který jede všechno přes ZIL, nad ním ještě další FS, zapnete žurnálování na všech vrstvách atp.).
Ale zaráží mě, že jste se za tu dobu nedobrali, kde k tomu dochází. Při správné konfiguraci není úplně realistické, že by OpenZFS na Linuxu mělo samo o sobě desetinásobnou WA a jen přechod mezi systémy to magicky vyřešil.
I ten tweak, co jste zmiňoval ve vlákně o FreeBSD, že je to už v pohodě, když jste prodloužil zfs_txg_timeout, mi přijde v téhle aplikaci trochu haluz (hlavně proto, že MySQL posílá sync(), který tu transakci uzavírá mnohem častěji).
Abyste to nějak rozumně porovnal, musíte zapsat opravdu identická data. Ideálně nějaký připravený test, nebo třeba i sysbench pro MySQL. Jestliže vám tam jednou vycházela odhadovaná WA menší než jedna, tak to znamená jen, že pokud je na datasetu zapnutá komprese, tak to s těmi konkrétními daty mělo lepší poměr.
Další věc je, že byste to měl opravdu počítat exaktně (fyzicky zapsaná data / logicky zapsaná data). Což nezjistíte jen iostatem. Logicky zapsaná data z databáze s innodb se dají zjistit přes globální status (SHOW GLOBAL STATUS LIKE '%WRITTEN%';), tam jsou čítače od spuštění.
Další místo, kde se to dá dohledat, kolik se zapsalo z aplikací, jsou statistiky pro jednotlivé datasety. V Linuxu je to v /proc/spl/kstat/zfs na FreeBSD se to vypíše přes: sysctl kstat.zfs.zroot.dataset
Mám na to takový skript.., co to vyfiltruje (první parametr je dataset, např. zpool/mysql ).
Vyjede vám akumulovaný počet zapsaných bajtů (nwritten), I/O operací, kolik šlo přes ZIL atp.
#!/bin/sh
dataset=$1
zpool=${dataset%%/*}
objset=$(zfs list -H -o name,objsetid \
| awk -v ds="$dataset" '$1 == ds { printf("objset-0x%x", $2) }')
sysctl kstat.zfs.${zpool}.dataset.${objset}
Akumul. počet bajtů zapsaných do zařízení se na FreeBSD nejsnáz zjistí přes iostat -Ix.
Když mu dáte parametr -I a neuvedete periodu, tak vám dá akumulované hodnoty od startu systému. Parametr -x dá každé zařízení na svůj řádek. Zápisy jsou v pátém sloupci kw/i (pozor na jednotky, je to v kB).
Tzn. je potřeba spočítat rozdíly (deltu) za dobu, co to měříte. A pak to mezi sebou podělit, abyste dostal WA u ZFS.
Jde to analogicky i u jiných filesystému a aplikací, ale tam už se musí typicky zapojit nějaký tracing, kdy budete odchytávat syscally pro zápis a sčítat hodnoty. Na FreeBSD přes DTrace, na Linuxu třeba přes bpftrace, perf atp.
Ještě krátce k tomu hardware, ta terabajtová SSDčka, co máte, mají zhruba 1DWPD. Tzn. reálný problém by měl nastat, pokud zapíšete vyšší stovky GB denně (samozřejmě včetně WA na úrovni databáze i FS), aby to začal být problém. Upřímně si nedovedu moc představit, kolik záznamů musíte denně zalogovat, ale asi bych úplně nečekal, že v tomhle bude problém i při použití "normální" databáze s transakcemi, replikací atp. pokud se to rozumně nastaví.
-
Reaguji na to co napsal Tomáš Crhonek.
OK, já budu reagovat na každý tvůj odstavec.
Pod pojmem SSD Samsung pro mi to najde jen tohle https://www.alza.cz/samsung-990-pro-1tb-d7516911.htm
Což není ani serverový disk.
Ano, není to ani serverový disk a i tak je naprosto skvělý. Já ve skutečnosti používám Samsung EVO, tedy vyloženě zákaznický disk určený do desktopů a zatím ani jeden neodešel.
NVMe Samsung pro mám jeden.
Já používám tohle https://www.alza.cz/wd-red-sn700-nvme-1tb-d6998050.htm
Kapacita 1TB, životnost 2000TBW. Tedy disk lze cca 2000 krát přepsat. Dříve to byly disky s kapacitou 512 GB s životností cca 600 TBW. Všechny disky vydržely to co měli v popisu.
Výborně, jenže i tenhle disk s 600TB Write toho umí zapsat daleko, daleko, daleko více. Když si s tím hráli kluci z webu CDR nebo potom Deep In IT (diit.cz), tak těch 600TB překročili mnohokrát a disk stále fungoval, tedy zapisoval a četl správná data. Výrobce prostě musí na krabičku disku napsat nějaké vlastnosti čistě jen proto, aby se mu jich nevracelo z reklamací moc. I tenhle WD Red určitě přežije třeba 10x600TB. V době 5 let záruky naprosto 100%
Oni jsou to ale dva různé problémy. Jeden problém byl v tom, že ZFS mělo v mém případě více jak desetinásobnou write applification oproti tomu, jakou by mělo mít dle všech pouček a návodů.
Dejme tomu že to tak je. Ale opravdu by se při 10x write aplification u ZFS zapsalo více než 600TB telefonních dat za 5let? O tom dost pochybuju. Ta tvoje telefonní data mohou mít třeba 512B na jedno volání a to ještě přeháním. Takže 600TB je 1 171 875 000 hovorů! Opravdu tam budeš během 5 leté záruky zapisovat miliardu hovorů? Opravdu? A pokud ano, tak si za těch 5 let záruky zcela jistě vyděláš na nový disk.
To jsem nyní vyřešil přechodem z Linuxu na FreeBSD. Tam to na stejném hardware a při stejném zatížení prostě nedělá.
Používám jak linux, tak freebsd na serverech v práci a tak velký rozdíl mezi IO vrstvou v nich není. Linux vůbec nezapisuje na disky 10 tolik než FreeBSD. Takže tady se může jednat jen o chybu v zápisu zapsaných dat na disk. Tedy ve statistice a nikoliv v počtu zápisů jako takových.
Přechod na FreeBSD má i další podstatné výhody, např. že mi přijde že ve FreeBSD je vše jednodušší a lépe zdokumentované, tedy nemám už potřebu příliš zkoumat, kdy přesně a proč se to násobné zapisování v Linuxu vyskytuje.
Souhlasím a blahopřeji. Dokumentace FreeBSD je skvělá, proto jej mám na produkčním serveru už 9 let.
Druhý problém na který jsem narazil a který z prvním souvisí jen okrajově a o kterém je tohle vlákno je ten, že při defaultním nastavení innoDB jsou zápisy více jak 10 krát pomalejší než než u defaultního nastavení MyISAM.
Výsledek je, že když importuji CSV soubor do nové databáze se 264 milióny záznamy, tak na to místo dvou hodin potřebuji celý víkend. Rozdíl je možné srovnat vhodným nastavením innoDB. Změna nastavení nespočívá ve vypínání sync!
OK, já MyISAM používal naposledy v roce 2007, takže změna proti InnoDB nebo od roku 2009 PostgreSQL mě vůbec nezajímá. Na disky (rotační, ssd nmve) to nemělo žádný vliv a ani PostgreSQL na první verzi BTRFS mi nikdy nezničil žádný z těch EVO disků.
Pokud by zkombinoval ZFS write amplification a neoptimální nastavení databáze, zničí to v mém provozu pravděpodobně i ty nejlepší disky a poběží to pomaleji, než kdyby databáze jela na deset let starém hardware. Řešit to lepším hardware je nesmysl.
Ne nezničí. Jednak opravdu nebudeš mít v DB 1 miliardu hovorů za 5 let a i kdyby ano, tak ten WD Red disk do 5 let můžeš klidně reklamovat. Já takto osobně vyreklamoval asi 20x HDD Samsung 3TB 7200rpm. Pokaždé to byla výměna za jiný kus, rukou mi prošlo 40 disků a zaplatil jsem pouze nákup těch původních 20. Reklamace v Alze, TS Bohemia fungují na jedničku z hvězdičkou. Tohoto se nemusíš bát.
MySQL/MariaDB neumožňuje vypnout sync, píše se, že tato možnost je jen pro testování. To bych mohl vypnout jen nastavením ZFS, aby ZFS sync jen předstíralo. Což ale není nutné i když u repliky databáze by to nijak nevadilo, ta se dá za pár minut nahodit znovu z posledního snapshotu.
OK, v pořádku. Já také někdy vytvořím 256GB RAM disk, DB importuji do něj, vypnu službu a potom těch 256GB oddíl překopíruju na SSD. Takže pokud nejde v MySQL vypnout fsync, tak je to ok, stále máme ramdisky.
Ostatní změny nastavení InnoDB konzistenci dat tak zásadně neohrožují. Např. z toho, že se provádí automatický comit po každém jednotlivém přidání záznamu, žádná výhoda neplyne, jen je vše mnohonásobně pomalejší.
OK. A je to tak pomalé, že se ty telefonní hovory nestačí zaznamenávat? I nejhorší zákaznícký disk má 50 tis. IOps. Opravdu zaznamenáváš 50tis hovorů za sekundu? A i kdyby, tak za 5 let je to pouze 788 400 000 zápisů. Což je pořád cca polovina toho, co ti garantuje výrobce, jak jsem spočítal o několik odstavců výše.
Např. zde je návod jak nastavit InnoDB pro monitoring hovorů. Nastavení je docela brutální, ale brutálně to také zvýší propustnost a sníží zápisy na disk. S tímto nastavením to zvládá ukládat více jak 15 000 hovorů za vteřinu (CPS =calls per second).
15 tis. hovorů za sekundu je nic. Disky WD mají pět let záruky a tohle zvládnou bez problémů.
Budu nucen si to nějak vyzkoušet např. vypínáním elektřiny nějakému klonu a zvolit vhodný kompromis.
V případě poškození dat je vždy možné se vrátit v čase 5 minut a začít od posledního snapshotu, což není žádná katastrofa. Navíc zápisy v mezičase budou uchovány na klonech, tedy je možné je doplnit později.
Skvělé!!! Takto jsem si v roce 2009 hrál s PostgreSQL. Vypínal jsem HW s tehdy ještě rotačními disky. Disky přežily 10x vypnutí za hodinu po 8h pracovní doby. I HDD to bez problémů přežili. Ty první 1TB WD Green. Ano Green! I tyto green disky měly tehdy 5 let záruky.
Kdykoli čtu srovnání MyIsam a InnoDB, vždy se píše o výhodách InnoDB, ale to že je v InnoDB defaultně cca 10 krát pomalejší pro zápis, v podstatě vždy zapomene propagátor zmínit. Porovnávám výkon v defaultní konfiguraci. InnoDB je možné zrychlit na úroveň MyISAM, ale důsledky pro bezpečnost dat nejsou řádně dokumentovány. To je pro mne dost překvapivé, když jedním z hlavních výhod InnoDB má být lepší bezpečnost dat a fakt, že se tabulky opraví sami, rychle a plně automaticky.
Jak jsem psal, zkušenosti s MyISAM mám naposledy v roce 2007. Od té doby jsem používal na MySQL InnoDB a od roku 2009 už jen PostgreSQL. PostgreSQL používám dodnes. Tedy 16 let! A aktuálně mi běží na diskách HDD Samsung Iron Wolf (NAS grade), které mají 8 let a už jsou dááávno po záruce. Ale stále běží.
Tedy 15tis hovorů za sekundu je pro dnešní EVO disky zcela bez problémů a PRO disk to vydrží 100% a u Samsungu máš na něj 5 let záruky. Stejně jako u WD.
-
U toho write amplification, o kterém často píšete, se mi to upřímně moc nezdá.
Mě také ne. Rozdíl mezi Linux a FreeBSD určitě není 10x a rozdíl mezi mít DB na XFS nebo na ZFS také neudělá dalších 10x a přechod MyISAM na InnoDB také neudělá 10x. Dohromady tedy 1000x write amplification.
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.
-
https://www.voipmonitor.org/doc/Scaling#SSDs
Ze zkušenosti vím, že pravděpodobnost, že budou data po výpadku elektřiny nebo pádu kernelu poškozena i při tomto nastavení, není velká.
Jaký přesně mají vliv jednotlivé parametry, i když je to věc naprosto zásadní, zůstává nedokumentováno.
Dokumentace existuje
https://dev.mysql.com/doc/refman/8.4/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit
-
U toho write amplification, o kterém často píšete, se mi to upřímně moc nezdá.
Mě také ne. Rozdíl mezi Linux a FreeBSD určitě není 10x a rozdíl mezi mít DB na XFS nebo na ZFS také neudělá dalších 10x a přechod MyISAM na InnoDB také neudělá 10x. Dohromady tedy 1000x write amplification.
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.
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. Neběžela tam hlavní databáze, ale její repliky. Vyřešil jsem to převod na ext4.
Na ext4 byl počet zápisů naprosto zanedbatelný. Počet zápisů na ext4 byl menší než desetinásobný. Ale beru v úvahu, že ZFS má přirozeně více zápisů než ext4, protože je to copy on write např. s méně efektivními updaty, což je v databázích velmi běžná operace. Indexy se updatují věčně. Rozdíl byl ale více jak desetinásobný proti tomu co bych považoval ještě za přirozené, normální a snesitelné a to ještě s nějakou rezervou. Ten rozdíl mezi ext4 a ZFS ale byl mnohem větší než desetinásobný.
Je ale pravda, že pokud někdo nemá opravdu hodně zapisující databází, amplifikace se vůbec nevšimne, neb rezerva životnosti disku je tam dostatečná. Věřím že právě proto jsem snad jediný, kdo ten problém pozoroval.
-
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.
Mě zatím neodešel žádný SSD disk nasazený na serveru. Magnetické čas od času odejdou.
Přetěžovat disk kvůli neoptimálnímu nastavení, aby měl co dělat, že se dožije pěti let nebo konce záruky, ale rozhodně není dobrá strategie. Pro spolehlivost provozu je lepší neřešit výměnu disku ani v záruce ani po ní. Nasazení 24/7 jakoukoli manipulaci hrozně komplikuje. Proto hledat opravdu optimální nastavení se vyplatí už kvůli tomu, že se sníží pravděpodobnost selhání disků. A platí to samozřejmě i na magnetické disky, protože zbytečné zatížením jim také nesvědčí.
Snažit se redukovat zbytečné zápisy, i kdyby to měl disk teoreticky vydržet, je dobrá strategie.
-
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.
-
U toho write amplification, o kterém často píšete, se mi to upřímně moc nezdá.
Resp. může se to samozřejmě vymknout z kloubů v nějakých specifických situacích (kdy máte např. nějaké šílené zarovnání a dělá vám to hromadu zbytečných RMW cyklů, nebo máte např. zvol, který jede všechno přes ZIL, nad ním ještě další FS, zapnete žurnálování na všech vrstvách atp.).
Ale zaráží mě, že jste se za tu dobu nedobrali, kde k tomu dochází. Při správné konfiguraci není úplně realistické, že by OpenZFS na Linuxu mělo samo o sobě desetinásobnou WA a jen přechod mezi systémy to magicky vyřešil.
I ten tweak, co jste zmiňoval ve vlákně o FreeBSD, že je to už v pohodě, když jste prodloužil zfs_txg_timeout, mi přijde v téhle aplikaci trochu haluz (hlavně proto, že MySQL posílá sync(), který tu transakci uzavírá mnohem častěji).
Abyste to nějak rozumně porovnal, musíte zapsat opravdu identická data. Ideálně nějaký připravený test, nebo třeba i sysbench pro MySQL. Jestliže vám tam jednou vycházela odhadovaná WA menší než jedna, tak to znamená jen, že pokud je na datasetu zapnutá komprese, tak to s těmi konkrétními daty mělo lepší poměr.
Další věc je, že byste to měl opravdu počítat exaktně (fyzicky zapsaná data / logicky zapsaná data). Což nezjistíte jen iostatem. Logicky zapsaná data z databáze s innodb se dají zjistit přes globální status (SHOW GLOBAL STATUS LIKE '%WRITTEN%';), tam jsou čítače od spuštění.
Další místo, kde se to dá dohledat, kolik se zapsalo z aplikací, jsou statistiky pro jednotlivé datasety. V Linuxu je to v /proc/spl/kstat/zfs na FreeBSD se to vypíše přes: sysctl kstat.zfs.zroot.dataset
Mám na to takový skript.., co to vyfiltruje (první parametr je dataset, např. zpool/mysql ).
Vyjede vám akumulovaný počet zapsaných bajtů (nwritten), I/O operací, kolik šlo přes ZIL atp.
#!/bin/sh
dataset=$1
zpool=${dataset%%/*}
objset=$(zfs list -H -o name,objsetid \
| awk -v ds="$dataset" '$1 == ds { printf("objset-0x%x", $2) }')
sysctl kstat.zfs.${zpool}.dataset.${objset}
Akumul. počet bajtů zapsaných do zařízení se na FreeBSD nejsnáz zjistí přes iostat -Ix.
Když mu dáte parametr -I a neuvedete periodu, tak vám dá akumulované hodnoty od startu systému. Parametr -x dá každé zařízení na svůj řádek. Zápisy jsou v pátém sloupci kw/i (pozor na jednotky, je to v kB).
Tzn. je potřeba spočítat rozdíly (deltu) za dobu, co to měříte. A pak to mezi sebou podělit, abyste dostal WA u ZFS.
Jde to analogicky i u jiných filesystému a aplikací, ale tam už se musí typicky zapojit nějaký tracing, kdy budete odchytávat syscally pro zápis a sčítat hodnoty. Na FreeBSD přes DTrace, na Linuxu třeba přes bpftrace, perf atp.
Ještě krátce k tomu hardware, ta terabajtová SSDčka, co máte, mají zhruba 1DWPD. Tzn. reálný problém by měl nastat, pokud zapíšete vyšší stovky GB denně (samozřejmě včetně WA na úrovni databáze i FS), aby to začal být problém. Upřímně si nedovedu moc představit, kolik záznamů musíte denně zalogovat, ale asi bych úplně nečekal, že v tomhle bude problém i při použití "normální" databáze s transakcemi, replikací atp. pokud se to rozumně nastaví.
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ě.
-
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.
-
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.
-
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.
-
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í.
-
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.
-
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]
-
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 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ě.
-
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
-
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č).
-
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…
-
https://vaibhavjha.substack.com/p/understanding-why-count-can-be-slow
-
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ý.
-
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!
-
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/