ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
PostgreSQL történelem - sebességtesztPostgreSQL 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. :)
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 11% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 19% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 28% Egyáltalán nem ismerem. 32% Csak az eredmény érdekel. 6% Összes szavazat: 476
Új felhasználók
InformációKövess minket!Partnerünk |
Szeretném kérdezni, hogy FirebirdSQL-t tesztelsz-e majd. Nagyon kíváncsi lennék egy ilyen összehasonlításra. Persze csak a MySQL után.
Köszönöm, most belevetem magam :o)
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
Mint írtam, sysbench-csel kicsit nehéz, nincs ugyanis hozzá support. Amit találtam az ilyen command line töltsünk be, kérdezgessünk, viszont sajnos kifutottam az időből, amit erre a projektre szántam. :)
suckIT szopás minden nap! PostgreSQL történelem
Kár, pedig hiánypótló lenne egy vason a PG-t, My-t és az FB-t tesztelni.
Mivel lehet, érdemes szerinted ezeket teszelni, ami kb. összehasonlítható eredményeket ad, és kész van?
suckIT szopás minden nap! PostgreSQL történelem
Félreértettél. A 'kár' arra vonatkozott, hogy kifutottál az időből amit erre szántál.
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
Nekem tetszik a cikk és köszi!
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
+1
es varom a MySQL-est:)
Mire számítasz? :)
suckIT szopás minden nap! PostgreSQL történelem
Az MSSQL-t és OracleDB-t kenterbe veri, legalább 400%-kal :-)
--
Vittem a buliba egy üveg sósavat. Oldódjon a hangulat...
Erre egyébként én is kíváncsi lennék, kár, hogy eddig sosem volt időm megnézni (meg mintha az Oracle tiltaná is a benchmarkokat)...
Más kérdés persze, hogy a MySQL-t a fenti kettőhöz hasonlítani felesleges.
suckIT szopás minden nap! PostgreSQL történelem
azert, mert...?
Eleve a kérdést nem értem. Szerinted az MSSQL és az Oracle miben összemérhető a MySQL-lel? Teljesen más célcsoport, nagyon kicsi az átfedés a kettő felhasználói(igényei) között.
suckIT szopás minden nap! PostgreSQL történelem
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.. ;-)
technikai oldalrol vilagits ra kerlek, hogy mi az, amit egy mysql+innodb nemtud (5.4es mysql), es egy oracle meg igen.
Stabilan, onkorrumpalas mentesen mukodni. :)
---
pontscho / fresh!mindworkz
egyik haverom mindig arra panaszkodott, hogy szetszallt az ora racuk. nalam meg a mysql nem adta meg magat me'g sokszazgiga adattal. hogyvanez kerem :)
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
igy van, sajnos a rossz megiteles sokszor ebbol jon, amit irsz. pistikek igy hasznaljak, es aztan sirnak, ha valami adatvesztes van.
dehat ok nem hallottak a foreign keyekrol sem, nemhogy normalizalasrol vagy tervezesrol.
Oracle-el szintúgy ez a helyzet. Lehet azt is jól, és szarul csinálni.
Mondjuk ott még pluszként néha bejönnek a mySQL-en edződött "dba" személyek, akik azt hiszik értenek az Oracle-hez is. :)
azert azt tegyuk hozza, hogy azt is erdemes megvalasztani hogy most eppen kell-e neked innodb vagy sem, mivel (es remelem hogy ez majd a tesztbol kiderul:) ) az innodb es a myisam kozott azert kb egy nagysagrendnyi a sebesseg kulonbseg.
Ahol a MyISAM probléma nélkül megy, ott nyilván nem kell változtatni. De itt nem is arról volt szó...
--
trey @ gépház
Az enyémből biztosan nem. Eszembe nem jutna myisamot használni, SEHOL.
Végigszoptam a 3.x-től jópár crasht, hogy ezt megtanuljam.
suckIT szopás minden nap! PostgreSQL történelem
azert kivancsi lennek a tenyleges sebesseg kulonbsegre a mai modernebb verziokban legalabb. De akkro ezek szerint ez nem lesz a tesztben? :(
myisam vs innodb nem. innodb vs falcon igen.
suckIT szopás minden nap! PostgreSQL történelem
kar :( kivancsi lettem volna (megkockaztatom hogy nagy altalanossagban meg mindig ez a legelterjedtebb tablatipus amit az embeek hasznalnak)
Akkor nem csodálkozom, hogy sokak számára a MySQL a szar szinonímája.
suckIT szopás minden nap! PostgreSQL történelem
hasznalom mindkettot, meg egyikkel se volt gondom, de lehet csak mazlim van :)
az innodb neha gyorsabb tud lenni, mint a myisam, es jobban skalazodik. HTH :)
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.
Lehet már a MySQL system táblákat InnoDB-vel használni MyISAM helyett?
Szerintem erre kérdésedre választ ad a mindenkori MySQL manual megfelelő szakasza. Mondjuk nem is igazán látom, hogy hol lenne indokolt a system táblák InnoDB-re konvertálása.
--
trey @ gépház
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
nem mondtak, hogy a dd=/dev/zero of=/var/lib/mysql/valamelyiktablad bs=1M count=100 nem javitja meg a tablat?:)
Na ne! :>
---
pontscho / fresh!mindworkz
Nem hátrány, ha valaki ért is hozzá... amúgy a rac meg a single install kicsikét más, nem kéne hasonlítani.
Én üzemeltettem pár rac-ot, és atomstabil volt. Ebből gondolom, hogy valami hozzá nem értés lehet a háttérben. Amúgy meg szarvason bármi meg tud halni.
azon gondolkodtam, hogy miert pont szarvason...
oszt leesett :)
/* bocs az esetleges helyesirasi hidakert */
Újdonság hogy már szarvason is, eddig azt tudtuk csak, hogy gyöngyösön... :)
...inkabb leveszem a szemuveget... :D
/* bocs az esetleges helyesirasi hidakert */
Technikai oldalról? Tárolt eljárások (PL/SQL, java, külső programok egyszerűen), RAC, ASM, OLAP, grid, titkosítás, tömörítés, ilyesmik. De biztosan tudná még hosszasan sorolni az, aki ért is hozzá. :)
suckIT szopás minden nap! PostgreSQL történelem
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.
ZFS-sel jelenleg legfeljebb failover clustert tudsz csinálni, míg az ASM-mel bármilyen platformon megy a RAC...
suckIT szopás minden nap! PostgreSQL történelem
Hö? :)
A zfs-t csak példaképp hoztam fel, hogy a "hagyományos" hozzáállást néha érdemes felülbírálni....
Egyébként pont hogy a zfs+Sun Cluster kombóval állítólag elég nagy szopás tud lenni.
olvastam azt (epp readonly voltam), es biztos lehet az adott hasznalati mintahoz optimizalni a disk layoutot, nem tagadom. viszont hogy erre az esetek hany szazalekaban van szukseg, arrol mar vitatkozhatunk:)
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.
lassan ugyis itt az ideje ora technologiakat tanulnom.. :-)
:) :)
Két hete telepítettem én is egy enterspájz edition-t az Ultra 10-emre tanulási célból. :)
Nem lesz az overkill? Mármint az U10. :)
--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.
Tanulásra épp jó. :) Full kiépítés: 440Mhz, 1G ram. (+némi modding egy 60GB-s Maxtor és egy DVD író személyében.)
Oracle mellett Firefox és thunderbird is "hasít" rajta, videonézésre mondjuk tényleg nem alkalmas, mert az már átmegy slide-show ba...
Mondtam pár dolgot, amit a MySQL/InnoDB nem tud, de nyilván téged nehéz lesz meggyőzni arról, hogy a MySQL mindenre jó, így nem is próbálkozom vele.
A főnököd is megmondta pedig, rá meg érdemes hallgatnod. ;)
suckIT szopás minden nap! PostgreSQL történelem
ho? :) en nem mondtam, hogy mindenre jo, mint irtam, a grid pl hianyozhat annak, akinek kell.
de az esetek 95% -aban realis alternativa lehet.
Most hogy ekkora vita kavarodott, ránéztem, és meglepődtem h van a mysl-nek is opengis-es extensionnye, wow...
Bár sejtem h erre nem fog kiterjedni a dolog, szívesen látnám az ora sdo, és a postgres gis bővítményével összehasolítva (az mssql nem érdekel ;] )
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.
ez igaz, elismerem. en csak mindent-titkositunk-vagy-semmitben gondolkoztam, de a Te scenariod is teljesen realis.
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
melyik verziokat fogod megnezni?
4.1, 5.0, 5.1, 5.4, 6.0 (a falcon miatt pld).
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
OK, azért kérdeztem, hátha van valami konkrét, amiről mostanában olvastál.
suckIT szopás minden nap! PostgreSQL történelem
fogalmam sincs :)
de a mysql grafikonokat mar latom :) kivancsi leszek a koritesre :)
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.. :-)
UltraSPARC T1/T2? Ideális platform a MySQL-nek. ;)
suckIT szopás minden nap! PostgreSQL történelem
van az is :)
ez egy x4150 lenne, 8db 10krpm sas diszkkel, es xeonnal :)
Gondolom Solarisszal. Érdekelne, hogy mire jutsz, alapból a Solaris elég gyatrán muzsikált nálam.
suckIT szopás minden nap! PostgreSQL történelem
eppen most redhat van rajta, de nezhetunk egyet solarissal is, jovohet utaniheten, ha visszakaptuk a gepeket.. -)
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.
"[...] 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 :)
sub
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
é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
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
"Régen a Postgres alatt kattogott a disk, most nem kattog."
A manual szerint van alapból fsync. Esetleg régebben kattogósabb diszked volt? Vagy nem értem.
Kötve hiszem, hogy elérte volna a maximumot.
suckIT szopás minden nap! PostgreSQL történelem
"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
mondj ilyen tesztet, es megnezzuk szivesen :-)
Nem én csinálom a tesztet. Mindössze eltűnödtem a következtetéseken. Gondolom azért lett közreadva. Nem akartam cikizni sem a szerzőt sem a Postgrest. Amúgy a saját munkámban használok Oraclet és Postgrest.
--
CCC3
a sysbench altalanosan elfogadott meres.
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
loop: a sysbench altalanosan elfogadott meroeszkoz :)
És milyen eredményt tippelsz az Oraclera?
--
CCC3
Régről, nem saját:
http://img10.indafoto.hu/5/5/67805_3895931f624854147664776af718d360/5606881_00c9d58f843311103146b42bee7ee679_m.jpg
suckIT szopás minden nap! PostgreSQL történelem
Viszont könnyen hozzáférhető, használható, és így te is tudod reprodukálni az eredményeket.
De tényleg, mindenki csak boldogabb lehet, ha megosztod a tudásod, és csinálsz egy jobbat (akár a sysbenchben/-hez).
suckIT szopás minden nap! PostgreSQL történelem
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
A sysbench nyílt forrású szoftver, szerintem szívesen veszik a hozzájárulást.
suckIT szopás minden nap! PostgreSQL történelem
"ha bonyolultabb tranzakciókat csinálna a sysbench"
neked ez valami fétised? ;)
.:LISA PHP Framework:.
A mondatodban a kulcs: az arányokra teljesítmény "figyelése" nélkül,
eleve abszurd, ugyanis nem mindegy, hogy a default beállítások milyenek.. csak gondolj
bele, hogy ha az egyiknél a "memória" 4, a másiknál 24 akkor az arány is hamis lesz.
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:.
Kiraktam a használt konfigot. A kernel beállításokról később tervezek írni (de ezek azonosak volt mindegyik verziónál), de semmi extra.
suckIT szopás minden nap! PostgreSQL történelem