- A hozzászóláshoz be kell jelentkezni
- 3791 megtekintés
Hozzászólások
koszi!
meglepett hogy MySQL ennyivel lassabb olvasasban....
- A hozzászóláshoz be kell jelentkezni
ha a gép ua., akkor engem is.
- A hozzászóláshoz be kell jelentkezni
ott van, hogy innodb engine-nel, amit nem sebességre, hanem tranzakcióra terveztek. ez benne is van a mysql doc-ban, ami gyors mysql alatt az a myisam táblatípus.
_______
14.77 %
- A hozzászóláshoz be kell jelentkezni
De a tranzakciokezeles annyira alap, hogy nem mondhatunk le rola a sebesseg miatt...
- A hozzászóláshoz be kell jelentkezni
+1 és a postgresql-nél az engine nem tudja a tranzakciót? Bár nem vagyok szakértő, de szerintem jogos 2 tranzakciókezelt enginet összehasonlítani. Ki nem sza**** a MyISAM-ot, nem élünk mi a kőkörban.
- A hozzászóláshoz be kell jelentkezni
aha, tranzakciókezelés KELL. KÖTELEZŐ.
Ja, meg kéne tanítani az embereket a tranzakciók kezelésére is. ugyanis egy-egy insert eltolásakor nem gecimindegy, hogy tranzakcióban történt-e vagy nem?
Pl a Drupal is olyan atomfontos inserteket meg update-eket művel, sőt, egyszerre száezret, hogy mindenképpen tranzakcióban kell futtatni.
Persze közben sírsz, hogy milyen picsalassú az oracle.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Szóval azt mondod, hogy bőven elég az async ext2, a journaling fájlrendszerek az emberek többségének teljesen feleslegesek.
suckIT szopás minden nap! HP backup system ROM
- A hozzászóláshoz be kell jelentkezni
jártam én már úgy, hogy egy bonyolultabb lekérdezéscsoport myisam-mal 1.5 perc volt, innodb-vel meg 7-8 mp... (ugyanaz a gép, ugyanaz a mysql verzió)
- A hozzászóláshoz be kell jelentkezni
MyISAM. Most adatbázist kezelünk, vagy SQL nyelven lekérdezhető Excel táblázunk? Döntsük már el.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
mondjuk nem akarunk 2 masodpercet varni egy selectre?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
LOL! Engine, amit nem sebessegre terveznek :)
- A hozzászóláshoz be kell jelentkezni
A heap (memory) meg még gyorsabb.
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
ha visszajottek a hackathlonrol a gepek, megcsinalom ugyanezt linux es solaris alatt, meglassuk. :)
- A hozzászóláshoz be kell jelentkezni
Solaris, vagy OS? A Linux és OS kész van. Nincs mire büszkének lennetek.
A Sun korábban csinált már ilyen összehasonlítást (www.sun.com/x64/docs/MySQL-sysbench-benchmark.pdf), ahol természetesen a Slowaris jött ki győztesnek.
Én kb. ugyanazokat a grafikonokat kaptam, csak a címke volt fordítva...
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
Solaris elsokorben a tervezett, aztan ha lesz idom, akkor OpenSolaris. muti a grafikonokat ;-)
meg azert lehet am alatta tuningolni az operacios rendszert is (direkt nem irtam OSt, nehogy felreertheto legyek), altalaban senki nem tol default installt ala..
- A hozzászóláshoz be kell jelentkezni
Sokan jönnek ezzel a szöveggel, de ez szerintem elég nehezen védhető, ha figyelembe vesszük, hogy a nem tuningolt Linux szarrá ver mindent a default installjával...
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
Magyaran ott a default beallitasok jobban kedveznek a MySQL-nek, mint mas oprendszerek default beallitasai.
- A hozzászóláshoz be kell jelentkezni
És jobban kedveznek a desktop felhasználásnak, az x szervernek, teljesen eltérő workloadoknak stb.
A Sun biztos direkt szállítja olyan pocsék beállításokkal a Solarist, hogy legyen munkája a zongorahangolóknak.
Messze nem elképzelhetetlen, majd Z megmutatja mennyit lehet javítani ezzel a teljesítményen.
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
Amugy Linuxra miert nem keszitettel ezen a hardveren benchmarkot? Ahogyan lattam, csak FreeBSD-vel benchmarkoltal. Igy aztan nem latom megalapozottnak az allitasaidat.
- A hozzászóláshoz be kell jelentkezni
Pár hozzászólással lejjebb megtalálod a választ.
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
Erre én is kíváncsi vagyok. Kb. 4 éve volt egy olyan esetem, hogy a FreeBSD alatt futó mysql szerverrel komoly teljesítményproblémák voltak. Mivel nem igazán volt időm kísérletezni, linuxra cseréltem a BSD-t: a mysql sokkal gyorsabb lett (ugyanazon a gépen), a teljesítményproblémák megszűntek.
Persze azóta sok idő eltelt.
- A hozzászóláshoz be kell jelentkezni
Komoly teljesítményproblémák ma már talán nincsenek, de még mindig a Linux a leggyorsabb. (spoiler a következő cikkekhez :)
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
Ha már spoilerkedsz és azt, amire gondolok: Pg-t is tervezed tesztelni Linux alatt? Egy nagyon régi leírásban javasolták, hogy Pg-t inkább BSD alatt - ha jól emlékszem, az IO ütemezővel indokolták -, csak ugye azóta eltelt pár év, és érdekelne, hogy mi változott.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Igen. Nem. :)
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
"8086-klónunkon" na ezen borultam :)
- A hozzászóláshoz be kell jelentkezni
Köszi ezt a cikket is.
- A hozzászóláshoz be kell jelentkezni
Ez így nem ér... Egy baromira félrekonfigurált MySQL-t használt a csóka! Nyilvánvaló, hogy még a kulcsokat sem adta meg rendesen (ez onnan látszik, hogy exponenciális a görbe felfutása, holott jól konfigurált kulcsok esetében b-tree-t használ, ami meg nyilvánvalóan lineáris). Én is tudok félrekonfigurált Postre-vel szánalmas adatokat kihozni.
- A hozzászóláshoz be kell jelentkezni
Részletesebben? Pontosan mitől is olyan baromira félrekonfigurált?
Némi hasonlóságot vélhetsz felfedezni az általam, és a Sun által használt konfigban, ami nem véletlen...
suckIT szopás minden nap! MySQL történelem
- A hozzászóláshoz be kell jelentkezni
Nem jól nézed az ábrát. Nem a növekedés exponenciális, hanem a vízszintes skála logaritmikus.
Az ábra egyetlen szempontból tanulságos: Az InnoDB 16 magig skálázódik. A Postgres 22+ magig skálázódott. Hogy skálázódott volna-e tovább, azt az adott hardveren nem lehetett vizsgálni, mivelhogy összesen 24 mag volt.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni