Docela by mne zajímalo, zda se DB nějak přizpůsobily SSD (případně CoW souborovým systémům) – nic takového jsem nezaznamenal (ale je možné, že mne to jen minulo). Konkrétně jestli se DB umí při zápisu na disk (tabulky, indexy) přizpůsobit tomu, že zapisuje na disk, kde seek není penalizován – a DB by vynechala „složitost“ související se snahou nefragmentovat data. (A druhá věc je, zda se DB přizpůsobuje velikosti bloků na SSD, které – alespoň dříve – typicky bývaly větší, než bloky souborového systému.)
Zdaleka neznám všechny databázové servery, ale myslím, že to bohužel zůstává pořád na adminovi nebo možná dnes i adminovi s ChatGPT
Každý ten engine má už relativně dlouho konf. parametry, které ovládají nějakou formou paralelismus při I/O operacích, co se dá potencionálně zvýšit při použití na SSD.
Také můžete narazit na možnost ladit query planner tak, aby víc preferoval buď náhodný, nebo sekvenční přístup.
Většinou je to formou nějakého vážení (U Oracle je to volba optimizer_index_cost_adj, u Postgresu pak třeba random_page_cost resp. seq_page_cost), u některých workloadů to může hrát roli.
Nakonec tam mohou opravdu být i specifické optimalizační mechanismy primárně pro točivé disky, což je asi to, na co jste narážel. Např. innodb_random_read_ahead nebo innodb_flush_neighbors. Tam třeba nějaké změny byly, innodb_flush_neighbors byl u MySQL 5.x ve výchozím stavu povolený a od MySQL 8 to musíte explicitně zapnout.
MariaDB jde trochu dál. Nejen že to není ve výchozím nastavení povoleno, ale snaží se opravdu detekovat SSD a když se jí to povede, tak volbu ignoruje.
https://mariadb.com/kb/en/innodb-system-variables/#innodb_flush_neighborsTo je asi zatím jediné místo, kde je použitá podobná autodetekce.
U těch CoW systémů, tak tam jde o to dohledat, jestli se zbytečně nezapisuje vícekrát, než je nutné, a nezvyšuje WAF. Např. u ZFS a innodb s vypnutím doublewrite mechanismu, tam je to vcelku jasné. U některých jiných voleb to ale může být trochu sporné, viz třeba ten ZFS logbias, co jsem zmiňoval. Jedna věc může být nějaký rychlý benchmark, druhá pak jak ten výkon bude vypadat po dvou letech provozu. Atd.
U toho ZFS a innodb je tam pak ještě další aspekt, který v určitých situacích může hrát roli. A to vyladění velikostí innodb_buffer poolu a ARC u ZFS, resp. nalezení jejich optimálního mixu při dané velikosti RAM a výrazně větší databázi.
Nakonec ty velikosti bloků, to je také relativně komplexní téma, aspoň pro mě.
Vstupuje do toho hodně různých vrstev a subsystémů ovlivňuje to workload atp. V tuhle chvíli jsou, co vím, výchozí hodnoty (4k - Oracle; 8k - Postgres, MSSQL, Firebird; 16k - innodb). Osobně bych se primárně koncentroval na ten workload, výchozí bude asi v pohodě pro valnou většinu věcí, a jakákoliv změna má logicky i nějaké negativum. V určitých situacích, kdy tam bude hodně souběžných krátkých zápisů a modifikací, tak může kratší 4k stránka pomoct, naopak třeba pokud se u nějaké db používá komprese, tak ty delší (32, 64k) můžou znatelně zvýšit její efektivitu. Takže člověk může dojít k různým závěrům,
pokud dělá např. transakčně orientovanou službu s vysokou mírou souběžného přístupu, nebo třeba někam ukládá hromady logů a jednou za čas z toho něco vytáhne.
Nicméně vy jste spíš narážel na velikost db stránky ve vztahu ke konkrétnímu SSD.
Jak jste zmiňoval blok na SSD, tak jste nejspíš myslel stránku, což je standardně nejmenší adresovatelná jednotka na SSD. Blok u SSD pak spíš brán ve smyslu více stránek, co se mažou jedním P/E cyklem, a může mít i několik MB.
U nativní velikost stránky bude asi záležet na generaci SSD, bývalo to 4k, u novějších velkých TLC/QLC disků to může být i 8, 16k. Do systému se to, co vím, žádným standardním způsobem neindikuje, abyste to použil v nějaké autodetekci. Některá pokročilejší NVME SSD mají možnost přes standardní namespace id-ns zjistit, že podporují víc režimů komunikace s hostem (např. 4k - výchozí, 8k - optimální). Následně se pak dá režim SSD přes nvme format příkaz změnit (destruktivně!).
To přepne vnitřní režim SSD, který do té doby typicky fungoval na úrovni tzv. sub-pages, a do hosta se indikuje nová velikost fyzického sektoru.
Pak se třeba dá zvětšit i velikost log. bloku na novém FS (tam myslím i dokonce nějaká autodetekce bude) a následně i porovnat s délkou stránky v DB. Pokud bude stránka stejně dlouhá nebo delší než na FS resp. u fyz. sektoru, fajn. Jestli bude kratší, pak bych režim disku nejspíš nechal být.
Motivací k tomu přepnutí by mohla být efektivnější činnost všech vrstev. Nicméně reálný výkonnostní dopad by se pak samozřejmě musel ověřit.
Nejspíš, a to už se dívám za roh, by se mohl snížit WAF v hardware. Pokud to SSD podporuje reportování zapsaných dat na úrovni buňek i to se dá samozřejmě zjistit s nějakým referenčním workloadem.
40 Odpovědí
21920 Zhlédnutí