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:
| 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:
Az 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.
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:
| 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!
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:
| RO/RW performance quotinent | |
| MySQL | 1.21x |
| PostgreSQL | 5x |
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:
| 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
Szerző: blackshepherd
8 komment
Címkék: performance postgresql freebsd mysql benchmark sysbench oltp
Ajánlott bejegyzések:
A bejegyzés trackback címe:
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 és az adatvédelmi tájékoztatóban.
prometheus_X 2009.10.04. 15:39:08
Tyra3l 2009.10.04. 19:28:48
Tyra3l 2009.10.04. 19:32:39
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