|
||
|
Maanantai, 24.2.2003 NEC, Intel ja Microsoft 2. paikalle TPC-C-suorituskykyvertailussaNECin valmistama 32-prosessorinen palvelin on vallannut kakkospaikan TPC-C-suorituskykytestissä, jossa mitataan palvelimen kykyä toimia transaktioita suorittavana tietokantapalvelimena. Intel Itanium 2 (McKinley) -prosessoreihin ja Windows Server 2003 -käyttöjärjestelmän testiversioon perustuva palvelin suoritti 433 000 transaktiota sekunnissa ja sijoittui tuloslistalla ohi 32-prosessorisen Power4-prosessoreihin perustuvan IBM eServer pSeries 690 -palvelimen. Listan kärkipaikkaa pitää hallussaan Fujitsun SPARC64 -prosessoreihin perustuva 128-prosessorinen Primepower 2000, jonka saavuttama tulos, 456 000 transaktiota sekunnissa, on helmikuulta 2002.
|
|
|
Copyright © 1998-2007 - Coredump Oy. ISSN 1458-476X. |
||
Anonyymi kommentoija, 24.2.2003 10:25:01
Meillä on onneksi käytössä "oikeat" database tuotteet joilla ei tuollaisia ongelma ole. En väitä etteikö niissäkin ole fixeja mutta niiden määrä ja boottailun määrä on RATKAISEVASTI pienempi. Tämän vuoksi on valinta Microsoftiin todella lyhytnäköinen ja kallis päätös projektille. Kaiken lisäksi jos valitsee esimerkiksi Oraclen, voi olla varma että projekti ei päädy sellaiseen tilanteeseen että on pakko käyttää Microsoftin tuotetta jossakin kohtaa. Kun taas Microsof tekee tuotteensa siten että lähes aina on olemassa jokin toiminto joka ei toimi minkään muun kanssa oiken kun heidän omien viritysten kanssa. Muunmuassa LDAP toteutus jonka microsoft on sotkenut sekaisin heidän domain ajattelun kanssa on kouluesimerkki siitä mitä microsoft tekee. Niin ja JAVA:
Anonyymi kommentoija, 24.2.2003 14:53:42
Microsoft pohjaiset tietokanta järjestelmät ovat ainna olleet niinsanottujen pikku kantojen järjestelmiä. Joiden etu on ollut ostamisen helppous, ja näennäinen halpuus.
Kuinka niin perustele, maailmassa on järeitäkin MS-SQL toteutuksia, myös suomessa. Itsekin olen ollut toteuttamassa erästä, jossa dataa taltioidaan kuukaudessa n. 250 Gt
Mutta kin kyse on 32 prosessorin palvelimesta, on siitä molemmat edut poissa. Sitä ei ole helppoa ostaa eikä se ole halpa. Ja kun puhutaan tuollaisista järjestelmistä, on ostotapahtuma yleensa pitkähkön evaluoinnin tulos. Ja siinä yleensä Microsoft jää kakkoseksi, kun vertaillaan hintoja saavutettuun hyötyyn, Mm availibility ja tco. Kuvaavaa tuohon availibilityyn on Microsoft tuotteiden ainainen buuttailu jonkun updaten takia. mm slammer päivitys aiheuttaa buuttauksen.
Ihnako totta ? heh heh.
Nuo boottaukset ovat myrkkyä availibility prosenteille, sekä aiheuttavat todellisen päänsäryn projektityölle jota kannan ympärillä tehdäään. Esimerkiksi palvelua kehittää 10 henkilön tiimi, jotka ovat ajastaneet päivitykset esimerkiksi 3 kuukauden välein. Jotta päivitykset saadaan sinne on koodi yleensä koodattava, sen jälkeen testattava ja sitten vasta laitettava tuotantoon. Tämä tarkoittaa vähintään kolmea ympäristöä. Ja jos noita ympäristöjä joutuu päivittämään viikoittain, erilaisilla security patcheillä. On projektityö todellisissa vaikeuksissa. Koska ympäritöt ja koodattu data ei ole synkronissa, eikä testattua.
Ei pidä paikkaansa.
En väitä etteikö niissäkin ole fixeja mutta niiden määrä ja boottailun määrä on RATKAISEVASTI pienempi.
Ehkä, ehkä ei. Väitän, että yhtälailla em. tuotteissa on vikoja, ne eivät vain tule 'suuren yleisön' tietoisuuteen siten kuin MS:n tuotteista löytyvät viat.
Ota selvää asioista äläkä esitä mutu tietoa.
Tämän vuoksi on valinta Microsoftiin todella lyhytnäköinen ja kallis päätös projektille. Kaiken lisäksi jos valitsee esimerkiksi Oraclen, voi olla varma että projekti ei päädy sellaiseen tilanteeseen että on pakko käyttää Microsoftin tuotetta jossakin kohtaa.
Niinpä, Oracle on vastaus kaikkiin ongelmiin ? Kerronpa sinulle erään asian, tiedän parikin projektia, joista Oracle on skipattu, ja se vasta maksaakin.
Esim. Anttilan BI järjestelmää rakennettiin Oraclen päälle ja todettiin ettei toimi ja kannan koko oli vain n. 100 Gt.
Että jätä ne lässytykset sikseen. Voisit lisäksi käydä päivittämässä tietoja kantojen suorituskyky eroista TPC.org organisaation palvelussa.
Kun taas Microsof tekee tuotteensa siten että lähes aina on olemassa jokin toiminto joka ei toimi minkään muun kanssa oiken kun heidän omien viritysten kanssa.
Muunmuassa LDAP toteutus jonka microsoft on sotkenut sekaisin heidän domain ajattelun kanssa on kouluesimerkki siitä mitä microsoft tekee. Niin ja JAVA:
Etpä paljoa aiheesta tiedä, sillä LDAP toteutus on yhteensopiva. niin ja JAVA oli Microsoftin Javascript vai pitäisikö sanoa Ecmascript tulkki, jolla ei ole mitään tekemistä Javan kanssa, ja ongelma syntyi siitä että Microsoftin implementaatio antoi paremman suorituskyvyn uin Sunin toteutus. MS:n versio oli COM enabled l. laajennettu Windows yhteensopivaksi, kieli sinänsä oli yhteensopiva. No kaikkihan tietää miten SUN tähän reagoi.
bungle, 25.2.2003 01:10:08
http://www.teradata.com/solutions/data_warehousing...
"See the animal in his cage that you built, are you sure what side you're on?" -- Trent Reznor
bungle, 25.2.2003 01:16:35
http://www.teradata.com/solutions/data_warehousing...
"See the animal in his cage that you built, are you sure what side you're on?" -- Trent Reznor
Anonyymi kommentoija, 24.2.2003 18:09:19
Microsoft pohjaiset tietokanta järjestelmät ovat ainna olleet niinsanottujen pikku kantojen järjestelmiä. Joiden etu on ollut ostamisen helppous, ja näennäinen halpuus.
Kuinka niin perustele, maailmassa on järeitäkin MS-SQL toteutuksia, myös suomessa. Itsekin olen ollut toteuttamassa erästä, jossa dataa taltioidaan kuukaudessa n. 250 Gt
Jos olet töissä ja tunnet kannat niin kerroppa minulle sitten systeemistänne esimerkiksi seuraavia asiaoita (jotka jo kertovat kannasta jotakin)
Kuinka monelle yhtäaikaiselle käyttäjälle se on suuniteltu.
Kuinka paljon kannasta on indeksoitu. Ja kuinka usen indekseista ajetaan refresh.
Entä kuinka monta vapaamittaista kenttää kannassanne on.
Entä paljonko teidän tietokannassanne tulee taulu lukkoja jos ajetaan siitä yleisin kyselynne. Tiedätkö edes mitä tarkoitta table lock.
Entä pystyykö teidän kannsat ottaa backupin lennossa. siten että taataan että yksikään tietue ei katoa. En ole vilä kuullut Sql serveristä tätä tehtävän.
Mutta sinä M$ ihminen olet juuri tuollainen joka tuijottaa lisenssi hintaa, ja unohtaa muut kulut. Taidat olla myynti puolella toissä, mutta et tiedä palvelun elinkaaresta yhtään mitään. Se että anttilan projekti oli epäonnistunut johtui toden näköisesti siitä että sitä oli toteuttamassa ei ammattilaiset.
Niinpä, Oracle on vastaus kaikkiin ongelmiin ? Kerronpa sinulle erään asian, tiedän parikin projektia, joista Oracle on skipattu, ja se vasta maksaakin.
Esim. Anttilan BI järjestelmää rakennettiin Oraclen päälle ja todettiin ettei toimi ja kannan koko oli vain n. 100 Gt.
Että jätä ne lässytykset sikseen. Voisit lisäksi käydä päivittämässä tietoja kantojen suorituskyky eroista TPC.org organisaation palvelussa.
Kun taas Microsof tekee tuotteensa siten että lähes aina on olemassa jokin toiminto joka ei toimi minkään muun kanssa oiken kun heidän omien viritysten kanssa.
Muunmuassa LDAP toteutus jonka microsoft on sotkenut sekaisin heidän domain ajattelun kanssa on kouluesimerkki siitä mitä microsoft tekee. Niin ja JAVA:
Etpä paljoa aiheesta tiedä, sillä LDAP toteutus on yhteensopiva.
Kerro mihin LDAP toiminnassa tarvitaan microsoftin doman autentikointia. Minäpä kerron. Jos yritys tekee LDAP ratkaisun M$ tuotteen varaan. Sillä he sitovat kätensä jatkossa siihen että ei ikinä ole realistista vaihtaa LDAP tuotetta toiseen koska käyttäjän autentikointi tieto on sidottu Domain ajatteluun. Tässä vain yksi esimerkki. Joten ala ala täällä valehtelemaan että se on yhteensopiva.
niin ja JAVA oli Microsoftin Javascript vai pitäisikö sanoa Ecmascript tulkki, jolla ei ole mitään tekemistä Javan kanssa, ja ongelma syntyi siitä että Microsoftin implementaatio antoi paremman suorituskyvyn uin Sunin toteutus. MS:n versio oli COM enabled l. laajennettu Windows yhteensopivaksi, kieli sinänsä oli yhteensopiva. No kaikkihan tietää miten SUN tähän reagoi.
No sano jos JAVA oli niin loistava niin miksi meillä on yleensä versio ongelmia.
Anonyymi kommentoija, 24.2.2003 18:22:48
Microsoft pohjaiset tietokanta järjestelmät ovat ainna olleet niinsanottujen pikku kantojen järjestelmiä. Joiden etu on ollut ostamisen helppous, ja näennäinen halpuus.
Kuinka niin perustele, maailmassa on järeitäkin MS-SQL toteutuksia, myös suomessa. Itsekin olen ollut toteuttamassa erästä, jossa dataa taltioidaan kuukaudessa n. 250 Gt
Sinä et erottele esimerkikisi mitä on tuo data.
Jätät ilmeisen tahallaan kertomatta muunmuassa sen että jos dataa talletetaan 250gt /kk, niin pajonko sitä poistetaan kuukaudessa.
Taitaa olla niin että puhut palturia ja olet kaiken lisäksi kaveri joka ei tiedä kannoista yhtään mitään.
Taitaa olla 250gt mukana error logitkin. Kerro nyt hyvänen aika montako joinattua hakua sinun valheellisesi paikka kestää. Entä minkä kokoinen on indeksi.
Kerro vielä haetaanko tuosta kannasta mitään vai onko se pelkkä entry kanta jota käsitellään muualla.
Kuinka monta yhtäaikaista käyttäjää suoriutuu kannassasi, jos samalla ajetaan indeksejä uusiksi.
toisin sanoen kyllä valheen tunnistaa jo kaukaa.
Nuo boottaukset ovat myrkkyä availibility prosenteille, sekä aiheuttavat todellisen päänsäryn projektityölle jota kannan ympärillä tehdäään. Esimerkiksi palvelua kehittää 10 henkilön tiimi, jotka ovat ajastaneet päivitykset esimerkiksi 3 kuukauden välein. Jotta päivitykset saadaan sinne on koodi yleensä koodattava, sen jälkeen testattava ja sitten vasta laitettava tuotantoon. Tämä tarkoittaa vähintään kolmea ympäristöä. Ja jos noita ympäristöjä joutuu päivittämään viikoittain, erilaisilla security patcheillä. On projektityö todellisissa vaikeuksissa. Koska ympäritöt ja koodattu data ei ole synkronissa, eikä testattua.
Ei pidä paikkaansa.
Meillä on onneksi käytössä "oikeat" database tuotteet joilla ei tuollaisia ongelma ole.
Niinpä onko mainitsemasi oikea database tuote joku kallis Oracle bugisine työkaluineen vai megakallis DB2 ?
En väitä etteikö niissäkin ole fixeja mutta niiden määrä ja boottailun määrä on RATKAISEVASTI pienempi.
Ehkä, ehkä ei. Väitän, että yhtälailla em. tuotteissa on vikoja, ne eivät vain tule 'suuren yleisön' tietoisuuteen siten kuin MS:n tuotteista löytyvät viat.
Ota selvää asioista äläkä esitä mutu tietoa.
Tämän vuoksi on valinta Microsoftiin todella lyhytnäköinen ja kallis päätös projektille. Kaiken lisäksi jos valitsee esimerkiksi Oraclen, voi olla varma että projekti ei päädy sellaiseen tilanteeseen että on pakko käyttää Microsoftin tuotetta jossakin kohtaa.
Niinpä, Oracle on vastaus kaikkiin ongelmiin ? Kerronpa sinulle erään asian, tiedän parikin projektia, joista Oracle on skipattu, ja se vasta maksaakin.
Esim. Anttilan BI järjestelmää rakennettiin Oraclen päälle ja todettiin ettei toimi ja kannan koko oli vain n. 100 Gt.
Että jätä ne lässytykset sikseen. Voisit lisäksi käydä päivittämässä tietoja kantojen suorituskyky eroista TPC.org organisaation palvelussa.
Kun taas Microsof tekee tuotteensa siten että lähes aina on olemassa jokin toiminto joka ei toimi minkään muun kanssa oiken kun heidän omien viritysten kanssa.
Muunmuassa LDAP toteutus jonka microsoft on sotkenut sekaisin heidän domain ajattelun kanssa on kouluesimerkki siitä mitä microsoft tekee. Niin ja JAVA:
Etpä paljoa aiheesta tiedä, sillä LDAP toteutus on yhteensopiva. niin ja JAVA oli Microsoftin Javascript vai pitäisikö sanoa Ecmascript tulkki, jolla ei ole mitään tekemistä Javan kanssa, ja ongelma syntyi siitä että Microsoftin implementaatio antoi paremman suorituskyvyn uin Sunin toteutus. MS:n versio oli COM enabled l. laajennettu Windows yhteensopivaksi, kieli sinänsä oli yhteensopiva. No kaikkihan tietää miten SUN tähän reagoi.
Anonyymi kommentoija, 24.2.2003 18:30:59
Microsoft pohjaiset tietokanta järjestelmät ovat ainna olleet niinsanottujen pikku kantojen järjestelmiä. Joiden etu on ollut ostamisen helppous, ja näennäinen halpuus.
Kuinka niin perustele, maailmassa on järeitäkin MS-SQL toteutuksia, myös suomessa. Itsekin olen ollut toteuttamassa erästä, jossa dataa taltioidaan kuukaudessa n. 250 Gt
Mutta kin kyse on 32 prosessorin palvelimesta, on siitä molemmat edut poissa. Sitä ei ole helppoa ostaa eikä se ole halpa. Ja kun puhutaan tuollaisista järjestelmistä, on ostotapahtuma yleensa pitkähkön evaluoinnin tulos. Ja siinä yleensä Microsoft jää kakkoseksi, kun vertaillaan hintoja saavutettuun hyötyyn, Mm availibility ja tco. Kuvaavaa tuohon availibilityyn on Microsoft tuotteiden ainainen buuttailu jonkun updaten takia. mm slammer päivitys aiheuttaa buuttauksen.
Ihnako totta ? heh heh.
Nuo boottaukset ovat myrkkyä availibility prosenteille, sekä aiheuttavat todellisen päänsäryn projektityölle jota kannan ympärillä tehdäään. Esimerkiksi palvelua kehittää 10 henkilön tiimi, jotka ovat ajastaneet päivitykset esimerkiksi 3 kuukauden välein. Jotta päivitykset saadaan sinne on koodi yleensä koodattava, sen jälkeen testattava ja sitten vasta laitettava tuotantoon. Tämä tarkoittaa vähintään kolmea ympäristöä. Ja jos noita ympäristöjä joutuu päivittämään viikoittain, erilaisilla security patcheillä. On projektityö todellisissa vaikeuksissa. Koska ympäritöt ja koodattu data ei ole synkronissa, eikä testattua.
Ei pidä paikkaansa.
Meillä on onneksi käytössä "oikeat" database tuotteet joilla ei tuollaisia ongelma ole.
Niinpä onko mainitsemasi oikea database tuote joku kallis Oracle bugisine työkaluineen vai megakallis DB2 ?
En väitä etteikö niissäkin ole fixeja mutta niiden määrä ja boottailun määrä on RATKAISEVASTI pienempi.
Ehkä, ehkä ei. Väitän, että yhtälailla em. tuotteissa on vikoja, ne eivät vain tule 'suuren yleisön' tietoisuuteen siten kuin MS:n tuotteista löytyvät viat.
Ota selvää asioista äläkä esitä mutu tietoa.
Tämän vuoksi on valinta Microsoftiin todella lyhytnäköinen ja kallis päätös projektille. Kaiken lisäksi jos valitsee esimerkiksi Oraclen, voi olla varma että projekti ei päädy sellaiseen tilanteeseen että on pakko käyttää Microsoftin tuotetta jossakin kohtaa.
Niinpä, Oracle on vastaus kaikkiin ongelmiin ? Kerronpa sinulle erään asian, tiedän parikin projektia, joista Oracle on skipattu, ja se vasta maksaakin.
Esim. Anttilan BI järjestelmää rakennettiin Oraclen päälle ja todettiin ettei toimi ja kannan koko oli vain n. 100 Gt.
Että jätä ne lässytykset sikseen. Voisit lisäksi käydä päivittämässä tietoja kantojen suorituskyky eroista TPC.org organisaation palvelussa.
Kun taas Microsof tekee tuotteensa siten että lähes aina on olemassa jokin toiminto joka ei toimi minkään muun kanssa oiken kun heidän omien viritysten kanssa.
Muunmuassa LDAP toteutus jonka microsoft on sotkenut sekaisin heidän domain ajattelun kanssa on kouluesimerkki siitä mitä microsoft tekee. Niin ja JAVA:
Etpä paljoa aiheesta tiedä, sillä LDAP toteutus on yhteensopiva. niin ja JAVA oli Microsoftin Javascript vai pitäisikö sanoa Ecmascript tulkki, jolla ei ole mitään tekemistä Javan kanssa, ja ongelma syntyi siitä että Microsoftin implementaatio antoi paremman suorituskyvyn uin Sunin toteutus. MS:n versio oli COM enabled l. laajennettu Windows yhteensopivaksi, kieli sinänsä oli yhteensopiva. No kaikkihan tietää miten SUN tähän reagoi.
Kerro kuinka montaa yhtäaikaista ihmistä koskee jos anttilan järjestelmä kaatuu.
noin 5 vuotta sitten olin tekemässä toiminnanohjaus järjestelmää joka muodostui useista kannoista jotka sijaitsivat NS suurkoneilla. Niiden käsittelemä laskutus ja tilaus data vastasi silloin 15% suomen nettoviennistä ulkomaille. Se oli keskitason kriittinen järjestelmä. Joka ollessaan pois päältä olisi aiheuttanut 12 tunnin sammumisen jälkeen tehtaiden pysähtymisiä. Mutta jo 3 tunnin poissa olo olisi aiheuttanut jo tuntuvia taloudellisia menetyksiä.
Siellä ei käytetä SQL Serveriä. Eikä sitä ed mainittujen syiden takia ikinä uskalletakkaan.
Anonyymi kommentoija, 25.2.2003 11:36:48
:D Voi kehveli mitä sontaa. SUNilla ei ole MITÄÄN tekemistä JavaScriptin kanssa. JS on Netscapen selainskriptauskieli, jonka nimeen laitettiin Java koska Java on trendikäs sana. M$n versio on Jscript, jonka pohjalta ECMA-standardi tehtiin yhteistyössä NSn kanssa:
http://searchdatabase.techtarget.com/sDefinition/0...
M$ yritti myös laittaa oman version Javasta Windowsiin, mikä ei onnistunut:
http://sektori.com/uutiset/4174/microsoftille
bungle, 24.2.2003 17:51:08
1. Microsoftilla oli oma "laajennettu ja twiikattu" Java kääntäjä
2. JavaScript syntyi Netscapen tekemänä ja oli alun perin nimeltään LiveScript. Microsoft teki oman implementaationsa tästä eli JScriptin. Sitten ECMAn toimesta on standardoitu ns. ECMAScript, joka muistuttaa suuresti Microsoftin JScriptiä.
3. Java ei ollut Microsoftin ECMAScript tulkki.
4. Microsoftin Java kääntäjä teki sellaista java-bytekoodia ja antoi työkaluja ja komponentteja, jotka sitoivat ajettavan java-koodin windows käyttöjärjestelmään ja Microsoftin Java-virtuaalikoneeseen.
5. Kaikki tietävät, että Javan tavoitteena on ollut alustariippumattomuus.
6. Alkuperäinen vastaaja saattoi viitata myös siihen, että Microsoftin SQL Serveriin ei saa kunnollista JDBC ajuria suoraan MS:ltä. MS:n tekemä ajuri on huono.
7. JavaScriptillä ja Javalla ei ole mitään tekemistä toistensa kanssa, kuin etäisesti toisiaan muistuttava syntaksi.
"See the animal in his cage that you built, are you sure what side you're on?" -- Trent Reznor
gmarx, 24.2.2003 18:24:56
Oraclesta on kuitenkin versio yli kymmenelle eri käyttöjärjestelmälle ja mielestäni jo se tekee siitä monessa tapauksessa paremman vaihtoehdon kuin MS-SQL.
reg, 24.2.2003 15:37:37
Itse sanoisin, että jos Anttila ja kumppanit eivät saa systeemiä toimimaan Oraclella se ei välttämättä ole Oraclen vika, toimiihan O isommissakin järjestelmissä.
Aurinkoisin kevätterveisin,
Anonyymi kommentoija, 24.2.2003 10:47:31
Tässä windows-koneessa oli 32kpl itanium2 1GHz prossuja ja tulos oli 433000 eli voitaisiin laskea tpm/cpu joka on 13531.
Mukavasti listalta löytyy muuten samanlainen, mutta 4-prosessorinen redhat linux-kone. Siinä tulos on 80494 ja samanlaisia prossuja on 4kpl, eli tpm/cpu on 20124. Huikaisevasti parempi kuin windows-itanium2 myllyssä.
kinnunen, 24.2.2003 11:29:00
jkarjanl, 24.2.2003 12:19:52
Täytyy silti myöntää että jos tuo testi on edes jotensakin puolueettomasti tehty, niin kyllähän on Wintel-koneessakin vääntöä. Kilpailu on aina hyväksi, ja siinä että myös Windows-alustalla voidaan toteuttaa jatkossa järeitäkin projekteja ei ole mitään vikaa. Ongelmaksi nouseekin ehkä juuri tuo availability-prosentti, ja mahdollinen liiallinen sitoutuminen yhden valmistajan tekniikkaan.
Anonyymi kommentoija, 24.2.2003 12:49:20
Totuus on se että jos koneessa on vähemmän prosessoreita on sen vikaantumis herrkkyys pienempi. Sen sijaan jos koneita on paljon clusterissa on sen vikaantumis herkkyys kiinni kuormantasaus järjestelmän toiminnasta.
Helpoin ratkaisu on aina pätevä. "Keep it simple"
xtrust, 24.2.2003 13:16:15
Fujitsu-Siemensin Primergy tuoteperhe on taas Intel-pohjaisia prosessoreja käyttävä.
Ihan kivoja koneita sinänsä. Tein pari vuotta sitten tuotetestausta tuollaisella. Virtuaalikonepartitiot ja kaikki :-)
oma, 24.2.2003 13:27:14