PostgreSQL történelem - sebességteszt

PostgreSQL

PostgreSQL történelem címmel olvasható egy több részből álló cikksorozat első része, amely a PostgreSQL utolsó öt kiadásának sebességét hasonlítja össze egy közepes teljesítményű gépen (4 Xeon processzor, 24 mag, 128 GiB memória). Hamarosan jön a MySQL-es teszt is. :)

Szerintem nem értettelek félre. Azt kérdeztem, hogy ha legközelebb ilyennel foglalkozom, szerinted mivel lehetne összehasonlítani őket.
A sysbench FB-öt nem tud, és mivel nem is használok ilyet, arra biztos nincs időm/energiám, hogy hozzá idomítsam.

Mással kell tehát nézni, de mivel?

suckIT szopás minden nap! PostgreSQL történelem

( gUHU | 2009. 09. 29., k – 09:47 )

Nekem tetszik a cikk és köszi!

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

technikai oldalrol vilagits ra kerlek, hogy mi az, amit egy mysql+innodb nemtud (5.4es mysql), es egy oracle meg igen.

komolyan erdekel, es vagy mysqlt-fikazzuk-mert-az-szar-az-oracle-meg-az-isten dbak tollabol szarmazo irasokkal talalkoztam, vagy a-mysql-az-isten-mert-csak-ahoz-ertek dbak tollabol valokkal. arany kozeput erdekelne.. ;-)

Tapasztalatom szerint vannak, akiknek a MySQL telepítés abból áll, hogy feltolják, majd elkezdik használni MyISAM-mal. Hírből sem ismerik, hogy van más lehetőség is (mondjuk InnoDB). Belefutnak egy korrupt táblába és elkezdenek szarozni. Pedig ha csak kicsit is vennék a fáradságot, akkor lehet, hogy nem lenne ennyi problémájuk. Nyilván az InnoDB használatakor is bekövetkezhetnek problémák. Azonban én nem emlékszem arra, hogy itt a HUP alatt az InnoDB-vel bármiféle probléma is lett volna. Pedig jó néhány éve megy az oldal.

--
trey @ gépház

Ezt én is meg tudom erősíteni, nyáron átállítottam egy régi oldalamat InnoDB-re, mert be akartam vezetni a foreign key-eket, meg ujratervezni a fél adatbázist.
A kulcsokhoz még hozzá se nyúltam, de meglepő eredményt kaptam egy adatbázisgyilkos oldal letöltésekor: ami MyISAM-mal kb 1.5 perc volt, ugyanaz InnoDB-vel kb. 7-8 mp.
Pedig azt olvastam, hogy a tranzakciókezelés támogatása miatt az InnoDB lassabb lehet a MyISAM-nál. Hát nálam nem, sőt.

Nem lenne indokolt, ha a MyISAM tudna raw device támogatást, de mivel csak az InnoDB tud, ezért jó lenne, ha a system táblák is lehetnének InnoDB-sek, mert így az ember nem tud a MySQL alá tenni egy dedikált háttértárat, hogy azon legyen a teljes DB, mindenképp szükség van egy külön filerendszerre is, amelyen a system táblákat kell tárolni.

Jaja, olyat is tapasztaltunk, szerencsere nem nekem kellett vele szuttyogni. :)

De egy aprocska mysql sztori belefer. A legdurvabb elkorrumpalas nem aramszunettol, rossz hardvertol, ocska sw env-tol kovetkezett be. Hanem egy mysql server service shutdown-kor. Nem tortent semmi extra, kliensek le lettek allitva, es ahogy a nagy konyvben meg van irva, le lett allitva. Majd nemi, a db-tol teljesen fuggetlen szerveren tortent matatas utan szinten a doksik altal emlitett modon el lett inditva es ennyi. Halott db a jo db. :)

---
pontscho / fresh!mindworkz

asm, titkositas, tomorites, pont egy olyan dolog, ami egy DB dolga ;-) en szivesebben latom ezeket egy szinttel lejjebb. (volume manager/fs?)

tarolt eljarasok vannak ugy ezer eve, igaz, csak sqlben, de orabol is eleg lassu javas tarolt eljarast hivni, AFAIK.

a gridben egyetertunk... OLAPra vannak 3rd party toolok (Mondrian amit mar lattam tavolrol, de biztos van tobb mas is)

asm, titkositas, tomorites, pont egy olyan dolog, ami egy DB dolga ;-) en szivesebben latom ezeket egy szinttel lejjebb. (volume manager/fs?)

Oracle jobban szereti direktben matatni a diszkeket, nem kotelezo neki fs ra, ennek teljesitmenybeli okai vannak allitolag. Ott viszont ezek implementalasa majdhogynem kotelezo.

A titkositas pedig fs szintu db tarolas eseten sem kerulheto meg, hiszen az elobbi eseteben valoban ved lopott diszkek eseten, de ha betor a szerverre a paraszt (tekintsunk el most attol, h ez mennyire realis vagy sem), akkor mar ijb van.

---
pontscho / fresh!mindworkz

"Oracle jobban szereti direktben matatni a diszkeket, nem kotelezo neki fs ra, ennek teljesitmenybeli okai vannak allitolag"

Jól tuningolt file rendszer esetén alig van külömbség a raw device és az fs teljesítménye között. Cserébe viszont az fs jóval jobban menedzselhető.

Az ASM már teljesen más történet.

Volume manager & fs vs. ASM ügyben kicsit vitatkoztam 1-2 hete itt egy oracle-essel, és engem kb. meggyőzött arról, hogy az ASM mostmár tényleg jobb alternatívája lehet a "hagyományos" hozzáállássnak.

Végül is a zfs-el szemben is sokan mondták, hogy ne keverjük a file rendszert a vm-el... és tessék, egész jól sikerült.

Nagy shared storage környezetben, ahol gyakran allokálnak és szüntetnek meg területeket, elég reális az igény.
Volt olyan, hogy 10-15% teljesítmény javulás jött csak egy storage reorganizációból. Csak éppen akkoriban egy ilyenhez kellett 2 hónapnyi papíron számolás és pár tervezett leállás is.

A titkosítás kapcsán megjegyezném, hogy az file system vagy a volume manager által ismert legkisebb értelmesen kezelhető egység a file és a volume. Simán elképzelhető, hogy egy adatbázisban ennél "kisebb" elemeket akarunk titkosítani, mondjuk csak egy táblát, vagy egy oszlopot, vagy hasonlót. Ezt a DB maga jobban meg tudja oldani.

A FreeBSD a múltban nem volt egy MySQL bajnok. Igaz, hogy a FreeBSD 7 fejlesztése során történek előrelépések, de azért a tesztek elvégzése előtt érdemes utánaolvasni, hogy hogyan érdemes a MySQL-t fordítani, konfigurálni, mert nagyon vad eredmények is kijöhetnek. Mondom ezt lassan 8 év FreeBSD-n való MySQL futtatás után.

--
trey @ gépház

Linkeket tudsz esetleg a "hogyan érdemes a MySQL-t fordítani, konfigurálni, mert nagyon vad eredmények is kijöhetnek"-re?

Tudom, hogy a MySQL nem volt egy sebességbajnok több CPU-s környezetben, de ezen a MySQL-es, és az OS-es arcok (Linux és FreeBSD is) is sokat javítottak.

suckIT szopás minden nap! PostgreSQL történelem

Nem követtem már egy ideje a FreeBSD ez irányú fejlesztéseit, csak annyit bátorkodtam javasolni, hogy érdemes utánanézni az éppen aktuális, legjobb teljesítményt adó fordítási és konfigurálási paramétereknek mind MySQL mint PostgreSQL futtatásához, mert

- nem biztos, hogy ugyanazok a beállítások adják a legjobb teljesítményt mindkét adatbázis-kezelő alatt
- nem biztos, hogy a make install clean adja a legjobb eredményt

Ez csak olyan általános tipp volt, ami azután jött, hogy az évek alatt elég sok doksit elolvastam az éppen aktuális "killer" MySQL FreeBSD-n beállításokról.

A legutolsó amit én olvastam az ez volt:

http://people.freebsd.org/~kris/scaling/mysql.html

Ez FreeBSD 7-hez van. Lehet, hogy 8-hoz éppen van frissebb. A levlistán érdemes kérdezősködni, hogy mi a mostani módi.

--
trey @ gépház

( NagyZ v | 2009. 09. 29., k – 10:10 )

en is akarok mysqlt tesztelni, igazabol mar a vas is megvan hozza, bar ennyire nem pakoltam tele (8 mag 32g ram), csak idom nem volt eddig.. :-)

( zsalab | 2009. 09. 29., k – 11:03 )

Ha már több hozzászolásban előkerült a PostgreSQL, MySQL, Oracle akor egy kis összehasonlítás a "szabvány követésről":
http://troels.arvin.dk/db/rdbms/
Nem a legfrissebb verziók (MySQL: 5.0.18, PostgreSQL: 8.3.3, Oracle: 10g2), de időközönként frissítik az összehasonlítást.

( MysteryKe | 2009. 09. 29., k – 11:14 )

"[...] egy közepes teljesítményű gépen (4 Xeon processzor, 24 mag, 128 GiB memória) [...]"

Szeretnék én is egy ilyen "gagyi", "közepes teljesítményű" gépet :)

( mrev | 2009. 09. 29., k – 14:29 )

Az Oracle, Postgres, InnoDB közös tulajdonsága az MVCC. Ezért érdemes őket összehasonlítani. A MyISAM kilóg ebből a sorból.
--
CCC3

( msandor v | 2009. 09. 29., k – 15:27 )

én mindenre MyISAM-ot használok, mert annó nagyon rühelltem, hogy az InnoDB csak hízni tudott, de soha se csökkent a fájl mérete :-(
és eddig nem volt rossz tapasztalatom a MyISAM-mal, két-három alkalommal amikor kirántottam a tápot a gép alól, akkor megsérült egy-egy tábla, de sikeresen meg lehetett javítani...

és nincsenek sebesség problémáink, nem olyan nagyok az adatbázisok...

--
by Mikul@s

( mrev | 2009. 09. 29., k – 17:45 )

Megnéztem a sysbench weboldalán, milyen tranzakciókkal csinálja a mérést. Ezek *nagyon* egyszerű tranzakciók. Egy táblán dolgoznak, nincs bennük konkurrencia kezelés. Kevés infó vonható le az eredményből, ha valaki olyan tranzakciókban utazik, mint pl. egy átutalás, ahol egyszerre egy csomó táblában kell tájékozódni, konkurrenciát kezelni, stb.

A grafikonok alapján nem mondanám, hogy a Postgres gyorsult. Azt kéne inkább mondani, hogy egyre jobban párhuzamosodik, vagyis a kliens szálakat jobban szétosztja a magok között, amivel az összteljesítménye természetesen nő, akkor is, ha egy-egy szálon csak ugyanolyan gyors.

Az írásos grafikonon mintha egyszálú esetben is volna valami növekedés. Ezzel kapcsolatban említem, hogy a Postgres valamikor régen tele volt fsync-kel. A readme-ben azt írták, hogy az fsync lassulást okoz, de kell a biztonsághoz. Ha valaki ugyanolyan gyors szervert akar, mint egy MySQL, akkor kapcsolja ki az fsync-et. Ebből az időből származik az a vélekedés, hogy a Postgres lassabb, mint a MySQL. Azóta változott a Postgres hozzáállása és kikapcsolták a korábban defaultból bekapcsolt fsync-eket. De ez még a 8.x előtt lehetett.

--
CCC3

"Azt kéne inkább mondani, hogy egyre jobban párhuzamosodik, vagyis a kliens szálakat jobban szétosztja a magok között, amivel az összteljesítménye természetesen nő, akkor is, ha egy-egy szálon csak ugyanolyan gyors."

Mivel minden egyes kliens kapcsolat egy processz, threading pedig nincs, ebben egészen biztosan nem történt változás.

Az fsync default on, és itt is így volt. A MySQL-nél elvileg ennek a innodb_flush_log_at_trx_commit = 1 a párja, ami erre volt állítva.

suckIT szopás minden nap! PostgreSQL történelem

"fsync default on"

Régen a Postgres alatt kattogott a disk, most nem kattog.

Közben még egy dolog eszembe jutott: A 8.3 és 8.4 között azért nem tudsz különbséget tenni, mert mind a kettő elérte a hardver által lehetővé tett maximumot. Tehát nem mondanám, hogy a 8.4-gyel megtört a fejlődés, hanem azt, hogy az adott hardveren nem vizsgálható, hogy akár a 8.3, akár a 8.4 képes-e további skálázódásra. (Mivelhogy összesen 24 mag van, kb. 22 szálnál van az optimum, 1-2 mag elhasználódik erre-arra.)
--
CCC3

"Mivel minden egyes kliens kapcsolat egy processz, threading pedig nincs, ebben egészen biztosan nem történt változás."

Éppenséggel lehetne változás. Pl. a query optimalizálásban, effélékben. De ezt a benchmark biztosan nem mutatja ki, mert túl egyszerűek a lekérdezések, ráadásul mindig ugyanazok ismétlődnek.

Mondok mást. A korszerű adatbázismotorok (Oracle, Postgres, InnoDB) fő büszkesége az MVCC. Az MVCC-nek a fő haszna pedig a serializable isolation level. Ki kéne próbálni, hogy muzsikálnak az adatbázisok serializable isolation levellel.

--
CCC3

SysBench is a modular, cross-platform and multi-threaded benchmark tool for evaluating OS parameters that are important for a system running a database under intensive load.

Ez a doksi első mondata. Szerintem ez azt jelenti, hogy a rendszerparaméterek beállítására való. Nem pedig az adatbázisszerverek teljesítményének mérésére. Valamit persze mér, abból lehet következtetéseket levonni, de nem túl sokat.

A tesztben nincs egy join sem, nincs referential integrity, nincs deadlock detektálás, stb. Semmi sincs benne, amit a modern szerverek csinálnak. Összesen egy táblája van, azon ismételget egy lekérdezést. Még az sem biztos, hogy mindig végrehajtja, lehet, hogy megjegyzi az első alkalommal kapott eredményt:)

--
CCC3

( Esc | 2009. 09. 29., k – 18:01 )

A tesztnek egyik szépséghibája, hogy nincs meg a postgres configja,
valamint nincs meg, milyen beállításokkal is ment a kernel. Gondolom
alapbeállításokkal.. amik nem egy db szerverhez voltak igazítva, így
viszont kétséges hogy valósak-e az eredmények. Lehet nagyobb különbségek
is lettek volna.. avagy kisebbek.

szerintem a tesztben az volt a lenyeg hogy hogy teljesitenek egymashoz kepest a kulonbozo verziok, akkor meg tokmind1 hogy mi van alattuk (kernel hogy van konfigolva stb), az a fontos hogy ugyanaz legyen mindegyik alatt, hiszen nem abszolut ertekben a teljesitmenyre ment ki a jatek hanem az aranyokra

Lehet, hogy egészen más arányok volnának, ha bonyolultabb tranzakciókat csinálna a sysbench.

Hasonlónak képzelem a helyzetet ahhoz, amikor összehasonlítasz két programnyelvet. Mondjuk az üres ciklus C-ben 100x gyorsabb, mint Jávában (esetleg ki is optimalizálja a compiler). Ha viszont a ciklusban van 1 darab SQL lekérdezés, akkor úgy látszik, hogy a két "nyelv" egyforma gyors.
--
CCC3

Mivel a rendszer "minden" paramétere állandó volt, és csak a mért egység változott, az egymáshoz viszonyított mérési eredmények értékelése akkor mutat fals eredményt, ha valamey rendszerbeállítás jobban kedvez (vagy visszafog) a mért egységek egyikének, tehát ha a x-es verzió kihyasznál egy beállítást, amit az x+1 nem. Ellenkező esetben teljesen jól összehasonlíthatók, egymással.

.:LISA PHP Framework:.