[HWSW]

Hozzáférhetõ a TPC oldalán a Sun OLTP világrekordja, mely felülmúlja az IBM eddigi legerõsebb eredményét. A legnagyobb szépséghiba, hogy a Sun-Oracle tandem klasztert használt, ami teljes irrelevánssá teszi a mérést.
http://www.hwsw.hu/h...er-595-db2.html' target='_blank'>http://www.hwsw.hu/h...er-595-db2.html

[Ytse]

Az Oracle a múlt héten harmadával csökkentette a szoftvereinek licencköltségét UltraSPARC T2+ processzoron és csak azon.

http://www.hwsw.hu/h...er-koltseg.html

Ha ezt nem lépi meg, 4 millió dollárral drágább lenne az új "rekorder" konfig, és ár/teljesítmény viszonya rosszabb lenne az IBM-nél (2,85 dollár vs 2,81 dollár / tpmC)

[lsarecz]

Ez a cikk sem lehet komoly, legalábbis viccnek kicsit durva

Elõször is, honnan kerül ide a tandem klaszter fogalma? Legjobb tudásom szerint a tandem klaszter maximum két szerverbõl áll, míg az Oracle által használt klaszter (Real Application Clusters) a benchmark során 12 szervert használt! Ez egy shared everything architektúra, amely ugyanolyan párhuzamosítási lehetõséget kínál, mint egy SMP szerver, hiszen minden adat a közös diszkalrendszeren található, nem pedig szerverenként felparticionálva.

Próbáltam utánakeresni, de nem találom megerõsítve azt az állítást sem, hogy a szakma évekkel ezelõtt kivetette magából a fürtözött TPC-C eredményeket. Ennek szívesen látnám bármely igazolását. Szerintem inkább arról van szó, hogy más nem tud tpc benchmark szempontból elfogadott és egyben hatékony klaszter architektúrát kialakítani, csak az Oracle. Nem véletlen, hogy a másik klaszteres eredmény is az Oracle nevéhez kötõdik.

Az SSD használata sem csak egyszerûen a megfelelõ hardver hozzáadásáról szól, azt az adatbázis-kezelõnek is támogatnia kell, ki kell tudni használni. Ez ismét egy olyan tény, ami miatt jelenleg csak az Oracle Database tudja produkálni ezt az eredményt. Persze könnyen lehet, hogy hónapokon belül más is megoldja ezt, viszont nem elegendõ "csak" belerakni a hardverbe az SSD-t, a szoftvernek is kezelnie kell.

Sárecz Lajos
Oracle Hungary Kft.

[Ytse]

@lsarecz: a tandem a Sunra és az Oracle-re vonatkozik (a két cég tandemje), nem a klaszterre, de igazad van, ez félreérthetõ...

[lsarecz]

@Bodnár Ádám: Köszi, ez tényleg nem volt egyértelmû. De továbbra sem értem, miért irreleváns a mérés attól, hogy klaszter. Ez inkább nehezítés az én értelmezésem szerint.

[[Fishi]]

Ha jól értem azért, mert "végtelen" jól skálázódik klaszterezéssel, tehát kb. csak az nem állít fel rekordot ilyen módszerrel, aki nem akar.

[Ytse]

@lsarecz: Ahogy Dani is írta a cikkben, a TPC-C benchmarkban elég könnyû fürtözéssel jó eredményt elérni, ilyen szintû skálázódás viszont a való életben ritkán mutatkozik OLTP workloadok alatt. Ez a viselkedés valószínûleg arra vezethetõ vissza, hogy a TPC-C egy elavult benchmark, végülis 1992 óta létezik, lényegében változatlan formában.

Ami a fürtözött benchmarkok hitelvesztését t illeti, szerintem nem kell jobb bizonyíték annál, mint hogy a TPC oldalán a most közzétett eredmény mellett csupán egyet lehet találni, a már említett HP-féle Itanium clusterét.

Szerintem az egész ügyet onnen kellene vizsgálni, hogy mit akart bizonyítani a Sun meg az Oracle ezzel a TPC-C eredménnyel. Nyilván nem a RAC erejét, mert -- ahogy te is írod -- a RAC-on kívül nincs másik hatékony cluster adatbázis architektúra a piacon, csak ez. Az sem nagy újság, hogy egy ilyen I/O intenzív benchmarknak jót tesz a flash memória használata merevlemez helyett, ezt sem kell túlságosan bizonygatni. Mit kell bizonyítani akkor? Azt hogy a Sun jobb az IBM-nél.

Ez az egész csak a küszöbön álló Sun-akvizíció kapcsán kialakult FUD-hadjárat elleni kampány része (counter-FUD ha úgy tetszik), Larry nagyívû nyilatkozataival, a WSJ-hirdetésekkel és Scott McNealy, James Gosling és John Fowler szerepeltetésével az OpenWorldön. Kellett valami nagyot dobni annak alátámasztására, hogy az Oracle meg a Sun együtt tényleg nyerõ kombináció, elsõsorban az aggódó (?) Sun-ügyfelek megnyugtatása miatt.

A benchmark egyáltalán nem az Oracle adatbázisról vagy a RAC képességeirõl szól.

[lsarecz]

@[Fishi]: Ha így lenne, akkor más gyártók is készítenének klaszteres benchmark eredményeket, nem gondolod?

[Ytse]

@[Fishi]: ez volt a frappáns megfogalmazása annak, amit írni akartam

[Ytse]

@lsarecz: minek készítenének? ha egy jó eredmény elérése szinte csak elhatározás kérdése, akkor felesleges egy rakat pénzt költeni rá mert másnap úgyis lesz valaki, aki megdönti a csúcsot egy nagyobb node-dal

[Ytse]

@Bodnár Ádám: akarom mondani nagyobb fürttel, még több node-dal

[Stewe]

Mi értelme van bármi áron jobbnak lenni a másiknál?

És most a bármi ár alatt nem anyagi összetevõkre gondoltam, hanem az elõttem szólók által felvetett problémákra. Miszerint elavult mérési módszerrel, nem etikus hardver összeállításban készült teszt alapján jobb rendszert bír az oracle összerakni. Ezt nem Micike meg Jolánka olvassa két kávékészítés közben. Nem szeretem, ha már a számítástechnikusokat (is) hülyének nézik....

[special]

@lsarecz: "Ez a cikk sem lehet komoly, legalábbis viccnek kicsit durva :-)"

Bár úgy látom, minden lényeges érv elhangzott, hadd válaszoljak én i s, a saját szavaimmal. Abba nagyon nem akarok belemenni, hogy a fürtözött TPC-C-nek van-e relevanciája, kérdezz körbe olyanokat, akik ezzel foglalkoznak, vagy akkor kattintsd le a linket az anyagban, mely megmutatja, hány klaszter mérést tárol jelenleg a TPC-C adatbázis.

http://www.tpc.org/t...wn_results=none

Hogy más nem tud, az egészen idáig nem volt igaz, mert Oracle RAC-ot bárki használhat, és mondjuk a HP, Dell, Sun, Fujitsu eddig nem voltak ellenérdekeltek, hogy ne csináljanak TPC-C RAC méréseket. De nem csináltak. Azt is vegyük észre, hogy ez az egész nem az Oracle 11g vagy RAC képességeirõl szól, hanem az Oracle arcozásáról a Sun hardverekkel, az IBM-mel szemben. Ez bukott meg. Nem a RAC irreleváns, hanem a TPC-C RAC eredmények.

Ami az SSD-t illeti, olyan formában igaz, hogy nem árt, ha a szoftver tudja, milyen jellemzõkkel megáldott storage van alatta, hogy maximálisan kiaknázza, de ettõl még az SSD bevetése a nem "SSD-aware" szoftvereket is gyorsítja, egyszerûen azáltal, hogy nagyságrendekkel magasabb IOPS sebességgel bír. Semmiféle kompatibilitási gond nem lehet, tekintve a szabványos interfészt, legyen SATA, SAS vagy akár FC, ez egyszerû implementációs döntés.

[dtracer]

@Bizó Dániel: Tudjuk rég, hogy az IBM felé hajlik az összes cikked, nem kell mellébeszélni.

Aki azt állítja, hogy végtelenig lehet skálázni párhuzamosítással, az még nem hallott az Amdahl-szabályról. Tessék utánaolvasni! Van a párhuzamosságnak egy optimuma, ahonnan csak romlik az összteljesítmény.

Egyébként pedig lehet szóban sárt dobálni erre a benchmarkra, de majd meglátjuk, hogy a 10 millió dolláros kihívásra akad-e válasz: http://www.oracle.co...enge-rules.html

[Haderach]

dtracer, miert van az az erzesem, hogy a sunnal dolgozol?
a cikk teljesen egyertelmuen leirja, hogy az oracle bemutatta, hogy 10 traktorral nagyob sulyt tud elhuzni, mint az IBM eggyel. egy kicsit tobb sulyt, nem sokkal.

[special]

@dtracer: érveket.

[special]

kiegészítettem egy bekezdéssel.

"Azonos SAN háttérrel egy Nehalem alapú RAC fürt sokkal kevesebb pénzbõl hozná ugyanezt a teljesítményt, mivel az egy T5440-re esõ tpmC (~643k) nagyjából megegyezik egy HP ProLiant DL370 G6 teljesítményével (~632k) - még akkor is, ha valamivel több node-ra lett volna szükség a kisebb memóriakapacitás és a lineáris alatti skálázódás miatt. Nem csak a hardver lenne olcsóbb, de legfeljebb harmadannyi Oracle licencre volna szükség. Innentõl kezdve lényegében csak azon múlna az elsõség, hogy ki mennyi pénzt szán arra, hogy a lehetõ legnagyobb fürtöt összerakja, így célja, hogy képet mutasson az OLTP-teljesítményrõl, teljességgel értelmét vesztené. Remélhetõleg a többi vállalat megállja, hogy ne lépjen rá erre az útra."

[fmosolyg]

legnagyobb szépséghiba, hogy a Sun és az Oracle klasztert használt, ami teljes irrelevánssá teszi a mérést.
Valóban, a fürtözés egy teljesen más technológia. Gõzgépek között is egy dízel motor tényleg irreleváns. És mennyire nem szép a vasúttól, hogy a hatékonyabbat választotta. Pedig milyen szépek a gõzmozdonyok...

A terhelés megosztó fürtözés az adatbázis rétegben valóban nem megszokott dolog. Ugyanúgy az újdonság varázsával hat mint a merevlemez csíkozás (stripe-olás), vagy az alkalmazás szerver farmok, amik egy hálózati terhelés megosztó segítségével több ezer felhasználót képesek kiszolgálni.

A tpc az adatfeldolgozásról szól. Nem pedig az smp teljesítmény tesztekrõl. Ha ez a teszt eredmény az www.smp-tpc.org oldalon jelenne meg, az valóban irreleváns lenne.

Fürtözni nem menõ
Valóban egy 1968-as Ford Mustang V8-as 5 literes motorral sokkal menõbb, mint egy s-max 1.8 dízel. Nem is értem, hogy miért nem jár mindenki Mustang-gal.

trónról letaszítani kívánt
trónról letaszított

a teszt túlságosan könnyen fûrtözhetõ és érhetõ el vele lineáris skálázódás, szemben a valódi OLTP-rendszerekkel
Minden tesztnek vannak hibái (, fõleg ha nem mi vagyunk az elsõk J), de a rengeteg banki rendszer, ahol terhelés megosztó adatbázis fürtözést használnak igenis valódiak.

Miért nincs több RAC-os TPC-C teszt?
A kérdés jogos. Az egyik lehetséges válasz az, hogy itt a HW gyártók versenyeznek és így természetesen õk is szponzorálják. A HW gyártók profit orientáltak. Olyan dologra költik a marketing pénzeket, ahol az megtérül. Egy ilyen teljesítmény teszten elért jó eredménynek komoly marketing értéke van. Azonban a teszt rendkívül költséges, tehát nem a kis közép kategóriás szervereket fogják itt szerepeltetni, hanem a nagyobbakat, amelyeken a nyereség is nagyobb.
Ezek alapján nem véletlen, hogy az egyetlen elõzõ RAC-os eredmény akkor készült a HP részérõl, amikor úgy látták, hogy ez egy jó fórum annak hangsúlyozására, hogy az Itanium CPU alapú rendszerek komoly teljesítményre képesek.

[suckit]

@Haderach: azért van ez az érzésed, mert valószínûleg így is van. A bayes filterem nevet is adott, de hát spamet is beenged néha, tehát teljesen nem bízok meg benne.

[bogdan]

Idézet: dtracer - Dátum: 2009. okt. 14., szerda - 10:14

@Bizó Dániel: Tudjuk rég, hogy az IBM felé hajlik az összes cikked, nem kell mellébeszélni.

ez szemenszedett hazugsag egy Itanium es HP hivorol!

a "senki sem tett kozze" erv meg kivulallokent, mint amilyen en vagyok, abszolut nem meggyozo sajnos. ha hoznatok merest (es nem elmeletit!), ami alatamasztja a furtozes linearishoz kozeli skalazodasat az lenne meggyozo erv.