Datábaze v ramdisku

[karel]

rychlosti pekne jen co je pravda, ale dva ssd v raid 1 to budou mit podobne,
a co se tyka te zivotnosti ssd museli by jste do toho dene hrnout stovky gigabitu aby vam skolaboval v pristich 4 letech

ale je to pekny ze si se podelil o zkusenosti treba se to nekomu bude hodit

[Reklama]

[Santa]

OMG
Dostal som v budgete nejake zvysne zelezo co bolo na sklade, 3 dni na najdenie vhodneho riesenia a ulohu vyriesit to tak aby nebolo potrebne nic dokupovat

Mas pravdu, ze ladenie databazy je umenie hodne majstra a 90% z toho je to, ako navrhujes databazu a pises selecty, a 10% je zvysok.

zatial toto vypada stabilne i ked to krici ze NIEEEE, no uvidime co ukazu dlhodobejsie testy.

[Santa]

Karel:
mas nejake realne testy nad SSD v RAID1? myslim co sa tych rychlosti tyka. Hodilo by sa to na porovnanie

[JardaP .]

JardaP, OMG: kludne moze aj v tejto faze vypadnut masina, nakolko dochadza k rekonstrukcii RAM oddielu, ktory je tak ci tak prazdny pri boote. Preto sa /dev/rd1 inicializuje manualne tak, ze sa prida najprv disk, a nasledne ked rd1 bezi, prida sa ram oddiel, ktory sa automaticky naplni datami.

Co kdyz RAID lehne a posledni spravna kopie je v ramdisku? Pred kazdym restartem byste meli overit, v jakem stavu je RAID, jestli si muzete restart dovolit.

[Santa]

JardaP:
mate pravdu, ze pri restarte by sa to malo kontrolovat. doplnim do scriptu. Horsie sa handluju prave katastroficke pady (vypadok prudu na oboch napajacich vetvach atp....) Ako som uz spomenul, nie je to uplne idealne riesenie, ma svoje rizika...

[Reklama]

[Mirek Prýmek]

Zeptám se možná úplně pitomě, ale jedna věc mi není jasná:

Dosáhl jsi toho, že rychlost zápisu pořád odpovídá rychlosti zápisu na disk. Plus to není úplně robustní (je to trochu nestandardní řešení, u kterýho si nikdy nemůžeš být moc jistý, jaké scénáře ho položí, otestovat všechny případy nejsi schopný).

Čím se tohle liší od toho, kdybys to vůbec neřešil "ručně" a prostě nasadil nějaký FS, který má solidně zvládnutou MFU cache (např. ZFS)? Čtení budeš mít z cache (nejčastěji čtené tabulky z MFU cache nic nevytlačí) a zápis na disk, takže rychlost stejná a robustnost vyšší.

Jaký je důvod, proč to tak neudělat?

[Kolemjdoucí]

Ivan,Kolemjdoucí: ramdisk koli tomu, ze potrebujem aby len niektore schemy (databazy) boli priorizovane na citanie. buffering, ci globalne settingy su fajna vec, to boli uvodne optimalizacie. Nevies to vsak nastavit per table, ale len per engine. a ked mas tak ako my, auditovanu databazu (ked nastane update na zazname, automaticky do tzv. historickej tabulky sa pridava povodny zasnam - before update trigger) tak ramkou plytvas na X nepodstatnych veci, lebo DB engine nerozlisuje prioritu tabuliek, schem.

Pořád mi připadá že IMHO je méně práce nakonfigurovat vlastní instanci DB engine pro tuto kritickou DB, než hrátky s RAM diskem a konzistencí s HDD.
Audit na update samozřejmě nějaké stránky v RAM zabere, ale pochybuji že to překročí významnou mez třeba 5 % z uvedených 64 GB.

[JardaP .]

JardaP:
mate pravdu, ze pri restarte by sa to malo kontrolovat. doplnim do scriptu. Horsie sa handluju prave katastroficke pady (vypadok prudu na oboch napajacich vetvach atp....) Ako som uz spomenul, nie je to uplne idealne riesenie, ma svoje rizika...

Tak pokud mate stroj teto konfigurace bez UPS, tak to je hned jeste vetsi p​r​d​e​l .

[to_je_jedno]

Mirek: ja v tom vidim mladicke nadseni a zejmena nerozvaznost zpusobenou pramalou zkusenosti. Ocenil bych vsak originalitu pri hledani reseni.

Pro same stromy nevidi les a jednou se bude hodne divit pokud to takto bude provozovat. Zkuseny clovek by to samozrejme resil tak, aby zachoval spolehlivost - treba prave pres ZFS(je jedno jestli ma ty soubory v pameti protoze ramdisk nebo protoze ZFS).

[lobo]

ja by som skusil namiesto priameho pristupu do DB napchat medzi applikaciu a DB jeden service layer ktory by sa staral len o citanie a zapis

pri citani si vies pekne poriesit cachovanie(priorita, TTL,..) toho co potrebujes priamo v pamati...

[Santa]

Jaký je důvod, proč to tak neudělat?

je, a velmi jednoduchy, ZFS mi na um neprislo Je asi dovod preco mas rank GURU
Dakujem za uzitocny typ.

Tak pokud mate stroj teto konfigurace bez UPS, tak to je hned jeste vetsi p​r​d​e​l .

Obe vetvy su zalohovane cez UPS a jedna z nich este aj cez naftak, bez toho by som sa do ramdisku nepustal

Lobo:
v specifikacii mam definovane, ze ziadne data na ktore nema pouzivatel opravnenie nesmu opustit db na vyssiu vrstvu (napr na webserver). data sa filtruju priamo v db views, niekedy az na uroven stlpca, takze nejaky caching na urovni nad databazou nepripada do uvahy.

to_je_jedno
dik za konstruktivnu kritiku

[MichalMB]

Ahoj,

pro takovéto případy používáme rapiddisk www.rapiddisk.org

Vytváří vrstvu pomocí dm nad fyzickým diskem (jiným blokovým zařízením), odolnost proti výpadku je tedy srovnatelná jako bez ramdisku (v případě použití módu WRITETHROUGH).

[Oldrich]

pro takovéto případy používáme rapiddisk www.rapiddisk.org

diky

[Santa]

pro takovéto případy používáme rapiddisk www.rapiddisk.org

Super, dik za typ, hned zajtra to testnem.

[to_je_jedno]

typ neni tip.