MySQL történelem

2009.10.03. 19:40

You can read this article in english!

Ez a cikk a PostgreSQL történelem folytatása, az előzményeket, és a mérés hátterét ott ismerheted meg.

Láttuk mit tud a PostgreSQL, nézzük mire képes a nagy ellenség!

Először is tekintsük át, hogy a tesztelt verziók (4.1.25, 5.0.85, 5.1.38, 5.4.1 és 6.0.11) mikor jelentek meg:

MySQL versions
branch/version/release date First release Tested release
4.1 2003-04-03 2008-12-01
5.0 2003-12-22 2009-08-11
5.1 2005-11-29 2009-09-01
5.4 2009-04-05 2009-06-22
6.0 2007-04-30 2009-05-11


Két kakukktojás van a tesztben. Az egyik az 5.4, amely a Sun szerint egy "performance & scalability" release:

suckit: mysqlwater.pngAz 5.4-es kiadás a MySQL azon problémáját igyekszik valamelyest kiküszöbölni, amely elsősorban a -milyen ironikus- a Sun CMT-s szerverein jelentkezik: sok szálnál elég gyatrán teljesít. Az 5.4-es release tulajdonképpen egy nem várt kiadás, hiszen korábban a 6.0 volt napirenden, de nyilván ki kellett valamit tolni az ajtón, ha már egy milliárd elment az akvizícióra...
Az 5.4 egyelőre béta állapotban van, a tapasztalatok szerint azért túl sok probléma az 5.1-hez képest nincs vele.

A másik gyanús versenyző a 6.0, amely tulajdonképpen már meg is szűnt, ilyen formában ugyanis sosem lesz kiadva. Ez a kiadás számos újdonságot hozott volna (falcon, maria storage engine), csak időközben sok minden megváltozott...

Ugyanúgy a read only sysbench OLTP teszttel kezdünk, 1 millió soron, 24 processzoros, 128 GiB memóriás 8086-klónunkon. A használt backend az InnoDB.

suckit: mysql-history.png

A grafikon igen látványos. Értelemszerűen a leggyegébb eredményeket a 4.1-es verziótól kapjuk, amely 64 szálon valamiért nagyon rosszul érzi magát, viszont utána még az 5.0-ás fölé is gyorsulja magát. A többire nem is nagyon vesztegetném a szót, hiszen az 5.4-es mindenkit kenterbe ver. Bár a maximumát 16 szálnál éri el, és utána már csak komoly veszteségek árán képes a klienseket kiszolgálni, viszonylag szépen tartja magát 128 szálig, ahonnan kisebb csökkenés után durva esés következik. Hiába van brutálisan sok, brutálisan erős CPU-nk, ha 1024 kliens rángatja a MySQL szerverünket, pont ugyanannyi teljesítményt kapunk, mint ha egy CPU-nk lenne (egy klienssel).

Nézzük táblában:

MySQL RO OLTP performance
  Peak TPS Peak performance at # of clients
4.1.25 3959 16
5.0.85 4423 14
5.1.38 4504 16
5.4.1 4795 16
6.0.11 4566 16


Érdekes módon szinte mindegyik MySQL verzió 16 szálnál érte el a csúcsteljesítményét, a legnagyobb, és a legkisebb között az eltérés 21 százalék, ennyit sikerült gyorsulnia a MySQL-nek a 4.1-ről az 5.4-re. Látszik, hogy az 5.4-be belepakolt változások hiányoznak a 6.0-ból, amely körülbelül az elődje (az 5.1) teljesítményét hozza.

Nézzük a read write tesztet is!

suckit: mysql-history-rw.png

Az 5.4 itt is szépen teljesít, bár a görbe vége gyorsabban konyul lefelé, de ez bőven betudható a FreeBSD gyengeségének is (mint ahogy természetesen minden más része is grafikonnak, a PostgreSQL-es tesztekből mindenesetre az látszik, hogy a FreeBSD többre is képes lenne).

A 4.1-es ugyanazt a furcsa mintát produkálja, csak nagyobb lyukkal, és sok szálon némiképp érthetetlen emelkedéssel.

A PostgreSQL-hez képest a MySQL becsületére válik, hogy bár a read only teljesítménye töredéke a Postgresének, a RO és RW tesztek közötti eltérés viszont sokkal kisebb:

Difference between RO and RW TPS
 RO/RW performance quotinent
MySQL1.21x
PostgreSQL5x


Azt hiszem kimondható tehát, hogy a jellemzően olvasásintenzív feladatokra a PostgreSQL jelenleg a (sokkal) jobb választás, míg a MySQL akkor lehet jó, ha változik is az adatbázis (némi tuninggal valószínűleg a PostgreSQL is feljebb hozható).

Táblázatos forma:

MySQL RW OLTP performance
  Peak TPS Peak performance at # of clients
4.1.25 2124 10
5.0.85 2445 10
5.1.38 2604 12
5.4.1 3193 14
6.0.11 2659 14

 

A fentiekből egyet biztosan állíthatok: a vizsgált verziók között a teljesítmény (bár nem túl nagy mértékben, de) folyamatosan nőtt, így a MySQL-re sem mondható az, hogy az új funkciók bekerülése mindenképpen lassítaná az adatbázist.

A használt konfiguráció a következő volt:

[mysqld]
datadir = /mnt/mysql
port = 3306
socket = /tmp/mysql.sock
skip-locking
max-connections = 3500
set-variable = key_buffer=1600M
transaction_isolation = REPEATABLE-READ
innodb_data_file_path = ibdata1:100M:autoextend
innodb_buffer_pool_size = 64G
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 1G
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 300
innodb_locks_unsafe_for_binlog = 1
innodb_max_dirty_pages_pct = 90
innodb_thread_concurrency = 0
[isamchk]
set-variable = key_buffer=12M

A bejegyzés trackback címe:

http://suckit.blog.hu/api/trackback/id/tr281409322

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

prometheus_X 2009.10.04. 15:39:08

Szimpatikus anyag, de kíváncsi lennék egy MyISAM engine alapú tesztre is, mivel ez az a tárolómotor, amely a legendák szerint jóval gyorsabb az InnoDB-nél.

Tyra3l 2009.10.04. 19:28:48

Ja, de akkor meg azert nem lenne fair az osszehasonlitas, mert a postgres-ben nem lehet kikapcsolni a tranzakcio kezelest, idegen kulcsokat, stb.

Tyra3l 2009.10.04. 19:32:39

blackshepherd: fix szeles tablaknal gyorsabb a myisam ha csak olvasast vesszuk figyelembe.
viszont ha van kevert iras/olvasas, ami altalaban eles hasznalatban jellemzo, akkor elvesziti ezt az elonyt, mivel innodb-ben van row szintu lock, amivel elerheto hogy amig A query modositja a tabla elejet, addig B query nyugodtan olvashatja a sorokat varakozas nelkul.
imho

Tyrael

blackshepherd · http://suckit.blog.hu 2009.10.04. 20:36:42

@Tyra3l: Legközelebb most már megnézem azt is, de elég szűknek látom a felhasználási területét. Nekem legalábbis eszembe nem jutna MyISAM-ot használni...

carstep 2009.10.05. 11:03:26

En vegyesen hasznalom a MyISAM-t es az InnotDB-t, akar egy adatbazison belul is. Amig nincs tranzakcio-igenyes muveletre szuksegem, addig hagyom a MyISAM-n a tablat. Mivel Agile fejlesztesen vagyok igy lattam celszerunek es mivel olvasasintenziv az alkalmazas, azert minden lepes megfontolando. Koszonom a teszteket, erdekesnek tunik a Postgre is, bar van MSSQL tapasztalatom, de azt hiszem a Postgre-t is kulon meg kellene tanulnom :-)

bagoj ur 2009.10.05. 12:28:42

Egy varcharos teszt engem is igen érdekelne, mivel sokat használom. Nem akarom más botjával csapkodni a csalánt, de ha lesz időd megismételni a tesztet csak a legújabb verziókkal, varchar mezőkkel, arra vevő lennék.

tbs1001 2009.10.06. 10:07:44

Innodb engine memóriaéhesebb, mint a myisam. Bár valóban SOKKAL jobb. Myisam sem ördögtől való, csak meg kell fontolni mire is használjuk.