Datábaze v ramdisku

Re:Datábaze v ramdisku
« Odpověď #30 kdy: 02. 03. 2015, 20:15:33 »
Už to tady pár lidí naťuklo, ale nikdo to asi neřekl dostatečně přesvědčivě. Takže pozor:

Vykašli se na ten ramdisk!

Já taky před pár lety podobnou kravinu udělal, protože jsem nerozumněl tomu, jak MySQL funguje. Dnes se tomu směju.

Trocha teorie: MySQL (MariaDB), resp. InnoDB (o MyISAM/Aria 1.x se snad ani nebavíme) všechny operace provádí nad strukturou nazvanou buffer_pool umístěnou v RAM. Disk z pohledu běžícího innodb funguje spíš jako swap v OS kam se hází data až když se nevejdou do paměti (resp. non-dirty data se samozřejmě neukládají, protože tam už jsou, je to analogie trochu volná).

To znamená:

Tu velikost, kterou jsi nastavil ramdisku nastav na buffer_pool v konfiguráku MariaDB, díky tomu budeš mít všechna data v paměti a při čtení se o disk ani neškrne, navíc předejdeš zbytečnému kopírování RAMDisk -> buffer_pool.

Teď zápisy: MariaDB už nemá ten deb... ehm zbytečný limit 4GB na velikost logů. Máš-li místo na disku, nastav velké logy co to jde (typicky bývají ve 2 souborech a nastavuješ velikost jednoho souboru). Tím dosáhnež toho, že každý zápis se provede pouze v RAM + sekvenční zápis do logů (místo okamžitého random zápisu do disku ve tvém RAID1) a jednou za čas (pokud budeš mít velké logy, tak to budou klidně hodiny třebas i den) se část buffer_poolu zapíše na disk (navíc innodb to dělá docela inteligentně). Pokud ti ta rychlost bude ještě pořád málo, dej si logy na jiný disk.

Suma sumárum dostaneš takto vždy lepší výkon než nejlepší možný případ toho RAIDu s ramdiskem + plotna. Data budou vždy konzistentní (vše je v logách), jediný "problém" se kterým musíš počítat je, že pokud to spadne, bude chvíli (pár minut) trvat, než se přehrají logy (to můžeš sledovat v error logu). Ale toto je mnohokrát ověřený scénář, který funguje a na který se můžeš spolehnout. Ehm až teda na pád při běžícím alter table, truncate table atd., ale to je prostě průšvih návrhu MySQL, kterému se prostě nijak nevyhneš ani svým řešením (a zas tak často se to nestává).


Santa

Re:Datábaze v ramdisku
« Odpověď #31 kdy: 02. 03. 2015, 21:43:21 »
typ neni tip.
Skutocne najhodnotnejsi prispevok k vecY...

j

Re:Datábaze v ramdisku
« Odpověď #32 kdy: 02. 03. 2015, 22:52:31 »
Pokusim sa zhrnut odpovede do jedneho prispevku:
...

Pouzivas blbou databazi and/or ji nemumis nastavit. Databaze si do pameti cachuje to, k cemu casto pristupuje, zbytek neresi.

+viz predchozi, raid je zalozenej na tom, ze v okamziku, kdy ti FS posle ze ulozeno, tak je skutecne ulozeno (na hdd). Pokud tobe ten tvuj potvrdi ulozeni, muze to byt klidne jen v RAM a tudiz v okamziku kdy to zbuchne nemas nic. Co vic, mas databazi ve zcela nekonzistetnim stavu. Vyzkousej si to. Nahod si to na testovacim stroji a posli do toho aspon par stovek inser/update a vypni to.

=> ty data vlastne nanic nepotrebujes, cemuz odpovida i cena reseni.


Už to tady pár lidí naťuklo, ale nikdo to asi neřekl dostatečně přesvědčivě. Takže pozor:

Vykašli se na ten ramdisk!

...

Tak nejak.

Trupik

Re:Datábaze v ramdisku
« Odpověď #33 kdy: 03. 03. 2015, 08:35:12 »
Pre tých, ktorí by toto chceli skúšať s PostgreSQL, doplním:

Rýchlosť behu PostgreSQL z RAMdisku je plusmínus zhodná s rýchlosťou behu z disku pri vypnutom fsync. To nie je teória, mám to overené prakticky. Takže namiesto tohoto krkolomného cvičenia stačí nastaviť v postgresql.conf parameter fsync=off. U nás to používajú vývojári na spúšťanie unit testov - tie ktoré predtým trvali 5 minút sa skrátili na 10 sekúnd. Ale na ostrý server by som to nedával.

Kolemjdoucí

Re:Datábaze v ramdisku
« Odpověď #34 kdy: 03. 03. 2015, 08:52:09 »
ktorí by toto chceli skúšať s PostgreSQL

RAM disk s PostgreSQL nikdo s mozkem v hlavě zkoušet nebude. Na nečekání na zápis na HDD je parametr synchronous_commit=off, nikoliv fsync=off.


aaa158

  • ***
  • 226
    • Zobrazit profil
    • E-mail
Re:Datábaze v ramdisku
« Odpověď #35 kdy: 03. 03. 2015, 09:44:59 »
ktorí by toto chceli skúšať s PostgreSQL

RAM disk s PostgreSQL nikdo s mozkem v hlavě zkoušet nebude. Na nečekání na zápis na HDD je parametr synchronous_commit=off, nikoliv fsync=off.

Mno, svet nie je binarny ;-) PostgreSQL z ramdisku je sice "divny" ale zalezi na use-case vsakze. A ci to funguje? Jasne ze ano ale db je riadne specificka (VELA writes/sec, plno triggerov, skoro ziadne reads), mozno by bolo treba inu technologiu, ale kedze je dany postgres (a prekopat to do niecoho ineho stoji vela $$$), znasilnuje sa postgres...

Kolemjdoucí

Re:Datábaze v ramdisku
« Odpověď #36 kdy: 03. 03. 2015, 09:59:18 »

Znásilňuje se proto, že se nečtou manuály a dokumentace.

Trupik

Re:Datábaze v ramdisku
« Odpověď #37 kdy: 03. 03. 2015, 10:59:25 »

Znásilňuje se proto, že se nečtou manuály a dokumentace.
V mojom prípade to vyzeralo tak, že prišli vývojári, či sa nedá devel databáza nainštalovať do RAMdisku. Keď prišli s takou priamočiarou požiadavkou, tak som ju priamočiaro vykonal (s poznámkou, že ide o blbý nápad). Veľa som si od toho nesľuboval, ale zjavne im to pomohlo. Tak som hľadal ďalej, či sa toto zlé riešenie nedá zlepšiť. Nakoniec som došiel ku fsync=off (podľa manuálu). Že sa rovnaký výsledok dá dosiahnuť aj cez synchronous_commit som zistil až teraz. Znie to rozhodne bezpečnejšie ako vypnúť fsync.

Kolemjdoucí

Re:Datábaze v ramdisku
« Odpověď #38 kdy: 03. 03. 2015, 11:29:26 »
Plně chápu a soucítím ;-)

ZAJDAN

  • *****
  • 2 056
    • Zobrazit profil
    • E-mail
Re:Datábaze v ramdisku
« Odpověď #39 kdy: 03. 03. 2015, 11:39:04 »
několik lidí tady zmiňujě, že dnešní databáze je zbytečné dávat do ramdisku, že si to databáze cachují do ram sami, atd.atd.
Ale proč tedy firmy jako SAP přepsali celej DB engine viz "HANA", kde jde právě o čístou implementaci do RAM paměti sevším všudy...?
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.

Kolemjdoucí

Re:Datábaze v ramdisku
« Odpověď #40 kdy: 03. 03. 2015, 11:56:24 »
HANA samozřejmě průběžně zapisuje na HDD. Rozdíl mezi in-memory a standardní DB je hlavně v politice. Standardní DB musí při COMMIT čekat na dokončení zápisu dat na HDD, zatímco in-memory DB ne, data se zapíší na HDD třeba až za pět minut.

Re:Datábaze v ramdisku
« Odpověď #41 kdy: 03. 03. 2015, 11:59:53 »
zajdan: nikdo nezpochybnuje "nacpat to do RAM", jen zpochybnujeme ramdisk a raid pole jako vhodny nastroj.
Děkuji za možnost editace příspěvku.

Ivan

Re:Datábaze v ramdisku
« Odpověď #42 kdy: 03. 03. 2015, 12:25:21 »
několik lidí tady zmiňujě, že dnešní databáze je zbytečné dávat do ramdisku, že si to databáze cachují do ram sami, atd.atd.
Ale proč tedy firmy jako SAP přepsali celej DB engine viz "HANA", kde jde právě o čístou implementaci do RAM paměti sevším všudy...?

Databaze jako Oracle, Informix anebo i MSSQL do jiste miry duplikuji funkcionalitu kernelu OS. Maji vlastni memory management, vlastni "drivery" pro pristup na disk, vlastni "lvm", vlastni scheduler (Infx), vlastni system prav, vlastni zalohovani, atd. Navic implementuji vlastni multiversioning(snapshoty).
Nu druhou stranu ale maji jiny problem, byly navrhovane v dobe kdy RAM byla draha, a pomer mezi kapacitou RAM a objemem dat na disku byl treba 1:1000. U Oracle je kapacita databaze prakticky nekonecna, protoze jeho interni adresni prostor pouziva UROWID, ktere ma variabilni delku, in-memory databaze si jednoduse vystaci s 64-bit pointerem. Pred 20ti lety by se pouzivani 64bit zdalo jako plytvani mistem, dneska je ale pameti hodne prace se skutecnymi pointery je mnohem jednodussi.

Pro vsechny databaze ale plati, ze maji svuj adresni prostor oznaceny jako neswapovatelny a obchazeji diskovou cache OS.
A pro diskove operace pouzivaji krome read/write jeste DIRECT_IO, mmap/msync, aio popr. jeste neco jineho. Databaze maji na OS specificke pozadavky, ale na druhou stranu toho vlastne chteji od OS docela malo(napr. alokuji pamet pouze pri startu) a vsechno si delaji samy. Pouze u MySQL se chybejici funkcionalita supluje prostredky operacniho systemu.

OMG

Re:Datábaze v ramdisku
« Odpověď #43 kdy: 03. 03. 2015, 14:13:58 »
V mojom prípade to vyzeralo tak, že prišli vývojári, či sa nedá devel databáza nainštalovať do RAMdisku. Keď prišli s takou priamočiarou požiadavkou, tak som ju priamočiaro vykonal (s poznámkou, že ide o blbý nápad). Veľa som si od toho nesľuboval, ale zjavne im to pomohlo. Tak som hľadal ďalej, či sa toto zlé riešenie nedá zlepšiť. Nakoniec som došiel ku fsync=off (podľa manuálu). Že sa rovnaký výsledok dá dosiahnuť aj cez synchronous_commit som zistil až teraz. Znie to rozhodne bezpečnejšie ako vypnúť fsync.
takze az za tebou prijedou vyvojari s tim, ze potrebuji mit na serveru k dispozici worldwide read/write ftp server ve kterem budou data firemni databaze, tak jim taky vyhovis? Ja ti nevim, ale pokud za mnou nekdo dojde s takovouhle peetchovinou, tak mu to slusne nacrtnu v cem je problem a pak at se jde zamyslet nekam...

ZAJDAN

  • *****
  • 2 056
    • Zobrazit profil
    • E-mail
Re:Datábaze v ramdisku
« Odpověď #44 kdy: 03. 03. 2015, 14:28:26 »
ano opravdu OMG, ale omg v tom smyslu, že namísto aby jste byli rádi, že se podělí o technickou zkušenost, tak sem zatahujte 'politicke' pohledy na věc...už se na to někteří kuvafix vyprdnite a nebo to prostě nekomentujte
Vesele, vesele do továrny dělník běží...vesele, vesele do továrny jde. Vesele se usmívá když mu soustruh zazpívá...vesele, vesele do továrny jde. Vesele si poskočí když se soustruh roztočí ...vesele, vesele do továrny jde.