MySQL - på vei mot PostgreSQL, Oracle? (del 2)

[roac]

Tror raid 5 er svært avhengig av kontrolleren. Hvis kontrolleren er bra nok burde raid 5 ha x-1/x (hvor x er antall disker) så bra lese/skrive ytelse som raid 0. Det er nok ikke slik i praksis dog.

Å skrive én blokk på et RAID 5 sett innebærer lesing av to blokker og skriving av to blokker. Dette er langt værre enn på RAID 1 eller RAID 10, som bare trenger å skrive to blokker. Men, caching bedrer selvfølgelig på situasjonen.

[blackbrrd]

Å skrive én blokk på et RAID 5 sett innebærer lesing av to blokker og skriving av to blokker. Dette er langt værre enn på RAID 1 eller RAID 10, som bare trenger å skrive to blokker. Men, caching bedrer selvfølgelig på situasjonen.

Du trenger da ikke lese data for å skrive i raid5?? Det hørtes helt fjernt ut! Har du noen referanser?

[roac]

Du trenger da ikke lese data for å skrive i raid5?? Det hørtes helt fjernt ut! Har du noen referanser?

Referanser: Alt som beskriver hvordan RAID fungerer, f eks boken SQL Server 2000 High Availability. (Mener denne er grundig nok til å beskrive dette, men har den ikke her). Årsaken til lesingen er rett og slett paritet. Når du skriver en ny blokk på RAID 5 må også ny paritet skrives, og for å få til det må ny paritet beregens, hvilket krever ett av to:

 

1. Alle datablokkene unntatt den som oppdateres leses, da har kontrolleren dataene fra alle stripene (inklusive den oppdaterte), og kan derfor beregne paritet og skrive denne og den nye datablokken til disk. Med tre disker vil dette faktisk føre til at bare en blokk trenger å leses, så det er mulig at det ikke er fult så ille som jeg skisserte.

 

2. Paritetsblokken og de gamle dataene i blokken som skal skrives leses, til sammen to blokker. XOR mellom dette gir paritet uten den blokken som oppdateres, xor med nye data gir ny paritet.

 

Det er ikke mulig å skrive til RAID fem uten å lese disse data fra disk, eller å ha dem i cache. Dette er en vesentlig svakhet med RAID 5, og en av grunnene til at RAID 10 anebfales fremfor RAID 5 til databaser.

 

De fleste RAID-kontrollere jeg har sett jobber etter modell to, men jeg har ikke sett dem med bare tre disker, så det er mulig at de da er smarte nok til å falle tilbake til den første modellen.

 

Håper dette var oppklarende.

 

Edit: Denne artikkelen er kanskje av interesse:

Performance Characteristics of PERC 3/QC Release 1.2 RAID Controller

Endret 4. august 2005 av roac

[Martin Lie]

Tror det roac refererer til er "small write"-problemet. Her, fra OpenBSDs raidctl-manual:

 

"Tuning RAID 5 sets is trickier. In the best case, IO is presented to the

RAID set one stripe at a time. Since the entire stripe is available at

the beginning of the IO, the parity of that stripe can be calculated be-

fore the stripe is written, and then the stripe data and parity can be

written in parallel. When the amount of data being written is less than

a full stripe worth, the `small write' problem occurs. Since a `small

write' means only a portion of the stripe on the components is going to

change, the data (and parity) on the components must be updated slightly

differently. First, the `old parity' and `old data' must be read from

the components. Then the new parity is constructed, using the new data

to be written, and the old data and old parity. Finally, the new data

and new parity are written. All this extra data shuffling results in a

serious loss of performance, and is typically 2 to 4 times slower than a

full stripe write (or read)."

[Martin Lie]

Det smarteste hadde vært å lage en trigger i torderstatussnap som la inn siste status i torder tabellen. Har ikke kommet så langt, en kjapp db server får heller treske noen millisekunder lenger.

Joda, men premisset for spørsmålet ditt måtte jo være at man hadde et databasesystem som ikke støttet subselects? Og jeg vil tro at de databasene som ikke støtter subselects heller ikke støtter triggere.

[Martin Lie]

Vi har portet en applikasjon fra å bruke mssql server til postgres 7.2 for ca 3 år siden. Ytelsesmessig ganske likt, men det krever endel omskriving av sql.

...bare hvis man bruker MS-spesifikt syntax, og ikke har et mellomlag. Er mest vant til Java-utvikling jeg, der jeg hovedsaklig bruker Hibernate som ORM-verktøy. Er sjeldent jeg trenger å skrive spørringene manuelt - og er takknemlig for det.

[roac]

Tror det roac refererer til er "small write"-problemet. Her, fra OpenBSDs raidctl-manual:

 

"Tuning RAID 5 sets is trickier. In the best case, IO is presented to the

RAID set one stripe at a time. Since the entire stripe is available at

the beginning of the IO, the parity of that stripe can be calculated be-

fore the stripe is written, and then the stripe data and parity can be

written in parallel. When the amount of data being written is less than

a full stripe worth, the `small write' problem occurs. Since a `small

write' means only a portion of the stripe on the components is going to

change, the data (and parity) on the components must be updated slightly

differently. First, the `old parity' and `old data' must be read from

the components. Then the new parity is constructed, using the new data

to be written, and the old data and old parity. Finally, the new data

and new parity are written. All this extra data shuffling results in a

serious loss of performance, and is typically 2 to 4 times slower than a

full stripe write (or read)."

Det er problemet med skriving av små mengder data om gangen, ja. Noe som er vanlig på databasesystemer. Man kan som beskrevet fjerne behovet for lesing fra disk ved å sørge for at hele striper blir lest og skrevet om gangen. Men, det vil få en seriøst negativ innvirkning på leseytelsen, fordi enhver leseoperasjon mot databasefilen da vil innebære lesing av en en eller flere striper, med andre ord at alle diskene settes i sving. Ved flere samtidige leseoperasjoner vil det føre til en grov degradering av ytelsen siden to blokker ikke lenger kan leses uavhengig av hverandre, på to forskjellige disker.

[blackbrrd]

Vel, vi har ikke så sinnsykt med skriveroperasjoner og ja, de er 99,99% av gangene mindre enn stripe size tenker jeg.

 

Joda, men premisset for spørsmålet ditt måtte jo være at man hadde et databasesystem som ikke støttet subselects? Og jeg vil tro at de databasene som ikke støtter subselects heller ikke støtter triggere. 

 

Premisset mitt var av nysgjerrighet og lurte på om det evt ville gå kjappere enn subselects. Ser dog ut til at å ikke ha subselects fører til et helvete når man lager spørringer

 

Pureblade:

I hvor store sammenhenger bruker du Hibernate? Sitter med endel store tabeller og ganske mange av dem, ca 400 tabell delt på to databaser. Litt nysgjerrig på hvordan Hibernate er å jobbe med

 

Hvordan funker Hibernate med indre spørringer som den over o.l.? Hva med joins som går over 10-20 tabeller?

 

Ah, også hadde det vært interessant å vite hvordan hibernate ville fungere med rmi (remote method invocation) i den slikt oppsett:

dbserver -(jdbc)- midleware -rmi- client

 

*nysgjerrig*

Endret 4. august 2005 av blackbrrd

[deviant]

Det står ingenting om plattform valg f.eks. støtter jo postgres og mysql "alt" mens ms kun går på windows og oracle støtter windows og til en viss grad linux.

 

"Til en viss grad linux" må vel være en understatement. Linux er en sertifisert Oracle platform. Oracle utvikles i stor grad på Linux, og ny Oracle teknologi som regel tilgjengelig på Linux relativt lenge før den blir gjort tilgjengelig for Microsoft Windows.

[Martin Lie]

*grmf* Den mail-utsendings-funksjonen (når det har kommet nye poster i en tråd) funker ikke alltid like bra... Så ikke innlegget ditt før jeg fikk mail om deviants innlegg.

 

Premisset mitt var av nysgjerrighet og lurte på om det evt ville gå kjappere enn subselects. Ser dog ut til at å ikke ha subselects fører til et helvete når man lager spørringer

Ja, for visse typer spørringer.

 

I hvor store sammenhenger bruker du Hibernate? Sitter med endel store tabeller og ganske mange av dem, ca 400 tabell delt på to databaser.

Hehe, hvordan bedømmer man hvor "stor" en sammenheng er? Hvis det er snakk om tabeller har jeg ikke jobbet mot mer enn ca. 50 tabeller, men jeg vil påstå at større databaser ikke nødvendigvis er med komplekse selv om de har flere tabeller. Det er jo ikke snakk om å bruke alle 400 tabellene samtidig? Akkurat nå bruker jeg Hibernate ifm. et administrasjonssystem for fondsselskaper.

 

Litt nysgjerrig på hvordan Hibernate er å jobbe med

Når man jobber med databaser via Hibernate, så jobber man i en objektorientert verden i stedet for en relasjonell. Enkle ting som lasting og lagring (enkle SELECT/INSERT/UPDATE) av objekter (entiteter) gjøres nesten uten kode i det hele tatt, mens for mer avanserte spørringer kan man bruke HQL - Hibernate Query Language eller criteria query (man lager et "mal-objekt", og så henter Hibernate objektene som matcher "malen" din). HQL er til forveksling veldig likt SQL, men i spørringene bruker man klasser i stedet for tabeller, egenskaper i stedet for kolonner, o.l. Hvis man har helt spesielle krav er det også mulig å håndkode SQL-statements der man trenger det, men dette er ikke noe jeg har noe særlig erfaring med.

 

Jeg vil ikke påstå av ORM-verktøy passer for alle prosjekter. Men det vil gi en forbedring for mange prosjekter.

 

Hvordan funker Hibernate med indre spørringer som den over o.l.? Hva med joins som går over 10-20 tabeller?

Hibernate er "bare" et wrapper-lag som ligger over JDBC. Subselects støttes hvis det underliggende database-systemet støtter dem (og den underliggende JDBC-driveren). Joining er enklere, fordi man tenker ikke i kryssprodukter, primærnøkler og fremmednøkler osv.

 

Typisk (simpel) SQL-join, der man er ute etter alle ordrer med status-endringer på en gitt dato:

 

SELECT O.* FROM Status AS S INNER JOIN Order AS O ON S.orderid = O.id WHERE S.date = '2005-08-13'

...hvorpå du må parse de forskjellige Order-kolonnene og lage Order-objekter av dem.

 

HQL:

SELECT status.order FROM Status AS status WHERE status.date = '2005-08-13'

 

...hvorpå du direkte får ut en tabell med Order-objekter. Det blir i bakgrunnen automatisk utført et SQL-statement inkl. JOINing, fordi order-egenskapen til status-objekter er definert som en peker til Order-klassen (aka fremmednøkkel til Order-tabellen), samt at Order-egenskapene (aka kolonnene i Order-tabellen) automatisk blir registrert på sine respektive Order-objekter.

 

Nå er det ikke alle spørringer som gir like klar fordel til HQL da, men det går hvertfall igjen at man slipper å parse String-verdiene som kommer fra en SQL-spørring over til objekter/egenskaper. Man sparer en del kode på det, og blir dermed mer effektiv (er min erfaring). Man må selvsagt omstille tankegangen sin for spørringer litt, men det tar ikke så lang tid - vil påstå man tjener på det innen kort tid.

 

Ah, også hadde det vært interessant å vite hvordan hibernate ville fungere med rmi (remote method invocation) i den slikt oppsett:

dbserver -(jdbc)- midleware -rmi- client

 

*nysgjerrig*

Det har jeg ikke tenkt over. Men så vidt jeg vet har ikke Hibernate noen konsepter om distribuert arkitektur. Det handler kun om å forenkle og effektivisere JDBC. Så vidt jeg kan se måtte du bruke Hibernate i din middleware, men ikke fra klienten. Klienten vil jo allerede fra før av kun forholde seg til objekter, og vil ikke vite (eller bry seg) om det er en relasjonell database eller noe annet som brukes til persistering.

 

(Hibernate er for øvrig et Java-verktøy. .NET-plattformen har (etter hva jeg hører) ikke kommet like langt i å lage gode ORM-verktøy.)

[perbu]

Jeg ser fram til et konstruktivt, men kritisk innlegg fra din side i nærmeste framtid, der du går mer i dybden på hva som var mangelfullt, osv.

Det er veldig enkelt. Dere prøver å nå frem til til et bedriftsmarket. Det bedriftsmarkedet vil ha er råd. Artiklene dere skriver bør rådgi (ikke alle da, selvsagt. Dere kan jo komme med nyheter også). Spørsmål som bør besvares er "Hvorfor skal vi velge MySQL fremfor Oracle?". Hvilke konsekvenser har f.eks. MySQL sin GPL-lisens for mitt produkt.

 

En oppramsing av mer eller mindre verifiserbare fakta iblandet en del objektivt prat er ikke det jeg ser etter.

[deviant]

Det er veldig enkelt. Dere prøver å nå frem til til et bedriftsmarket. Det bedriftsmarkedet vil ha er råd. Artiklene dere skriver bør rådgi (ikke alle da, selvsagt. Dere kan jo komme med nyheter også). Spørsmål som bør besvares er "Hvorfor skal vi velge MySQL fremfor Oracle?". Hvilke konsekvenser har f.eks. MySQL sin GPL-lisens for mitt produkt.

 

En oppramsing av mer eller mindre verifiserbare fakta iblandet en del objektivt prat er ikke det jeg ser etter.

MySQL kommer heldigvis med dual lisens, slik at man kan unngå GPL om ønskelig.

 

Forøvrig er jeg enig. Det jeg ser etter er gjerne informasjon om erfaringer og praktisk impact. En ren sammenligninsanalyse passer nok bedre for hobbybrukeren.

 

Jeg drifter selv noen av de mest belastede oracle og mysql web-løsningene i landet, og mine erfaringer er relativt enkle. MySQL håndterer ikke kombinasjonen av høy belastning, store datamengder og forholdsvis mye updates særlig bra.

 

Uten å gå i detalj kan jeg generelt jeg si at en vanlig mysql databaseserver (2 x Xeon CPU, 4 GB minne, 10 x 15k ultra320 disker i hardware 0+1 RAID) klarer 2500 spørringer i sekundet mot en tabell med 2-3 GB fordelt over 8-10 millioner rader. Dette selvsagt avhengig av et utall parametere som det er skrevet flere bøker om.

 

Oracle i praktisk produksjon er mye raskere enn MySQL, selv på enkle spørringer. Det tror jeg kommer av at de fleste applikasjoner kjører mange like eller lignende spørringer, noe Oracle vet å dra nytte av.

 

Trenger jeg transaksjonshåndtering i en belastet base velger jeg ikke MySQL.

 

MS-SQL kjører kun på Windows og er derfor uaktuelt for de fleste oppgaver i mitt driftsmiljø. Dette er spesielt sant nå som Oracle har et lisensalternativ som er priset på nivå med MS-SQL. (Oracle Standard One)

Endret 13. august 2005 av deviant

[Martin Lie]

I hvor store sammenhenger bruker du Hibernate? Sitter med endel store tabeller og ganske mange av dem, ca 400 tabell delt på to databaser.

Glemte forresten å si at to databaser ikke er noe problem. Man kan konfigurere to ulike datakilder for de to databasene. Skal du ha spørringer mot begge databasene inn i samme transaksjon, så kreves JTA (som altså kan brukes, men ikke kreves, for transaksjonsbehandling sammen med Hibernate). Integrerer man det hele med Spring, så blir det riktig så enkelt og trivelig å jobbe med. Man får da også muligheten for deklarative transaksjoner som bonus (ved hjelp av AOP-støtten (aspektorientert programmering) til Spring).

[roac]

Uten å gå i detalj kan jeg generelt jeg si at en vanlig mysql databaseserver (2 x Xeon CPU, 4 GB minne, 10 x 15k ultra320 disker i hardware 0+1 RAID) klarer 2500 spørringer i sekundet mot en tabell med 2-3 GB fordelt over 8-10 millioner rader. Dette selvsagt avhengig av et utall parametere som det er skrevet flere bøker om.

Heh, 10 disker i RAID 0+1? Jeg håper dette var en skrivefeil og at det skulle stått RAID 1+0. RAID 0+1 er striper som speiles, mens RAID 1+0 er speil som stripes. Lese/Skriveoperasjonene er for alle praktiske formål de samme, men med RAID 0+1 sitter du igjen med et stripesett i det en enkelt disk feiler.

Endret 13. august 2005 av roac

[roac]

MS-SQL kjører kun på Windows og er derfor uaktuelt for de fleste oppgaver i mitt driftsmiljø. Dette er spesielt sant nå som Oracle har et lisensalternativ som er priset på nivå med MS-SQL. (Oracle Standard One)

Oracle har helt klart kommet seg med tanke på prising, men et par ting som kanskje bør trekkes fram i denne sammenhegen, siden du nevner Oracle Standard One):

 

Oracle Standard One støtter ikke clustering, ei heller replikering. Videre har den etter det jeg ikke se noe tilsvarende Analysis Services (Business Intelligence) i SQL Server. Prisen er omtrent den samme som det SQL Server 2005 Standard Edition vil komme på. SQL Server 2005 Standard Edition inkluderer de funksjonalitetene jeg trakk fram, og har i tillegg en langt hyggeligere prising i feiltolerante løsninger enn det Oracle har, og det samme gjelder for løsninger med flerkjerneprosessorer.

 

Min konklusjon blir at man får mer for pengene med SQL Server 2005 når den kommer enn det man får med Oracle, såfremt ikke Oracle nok en gang ser på prispolitikken sin. Det største usikkerhetsmomentet for min del med SQL Server 2005 er hvilken versjon som kommer til å bli inkludert i Small Business Server, og når denne blir sluppet med SQL Server 2005 i steden for SQL Server 2000.

[deviant]

Uten å gå i detalj kan jeg generelt jeg si at en vanlig mysql databaseserver (2 x Xeon CPU, 4 GB minne, 10 x 15k ultra320 disker i hardware 0+1 RAID) klarer 2500 spørringer i sekundet mot en tabell med 2-3 GB fordelt over 8-10 millioner rader. Dette selvsagt avhengig av et utall parametere som det er skrevet flere bøker om.

Heh, 10 disker i RAID 0+1? Jeg håper dette var en skrivefeil og at det skulle stått RAID 1+0. RAID 0+1 er striper som speiles, mens RAID 1+0 er speil som stripes. Lese/Skriveoperasjonene er for alle praktiske formål de samme, men med RAID 0+1 sitter du igjen med et stripesett i det en enkelt disk feiler.

Det skal selvsagt være RAID 1+0 (også kalt RAID 10). I dette tilfellet; 5 speil som så er stripet. Legg forøvrig merke til at en del rimelige kontrollere jeg har kommet over ikke støtter så mange array konfigurasjoner og derfor benytter 0+1 om man skal ha mer enn 4 disker i settet.

Endret 15. august 2005 av deviant

[deviant]

MS-SQL kjører kun på Windows og er derfor uaktuelt for de fleste oppgaver i mitt driftsmiljø. Dette er spesielt sant nå som Oracle har et lisensalternativ som  er priset på nivå med MS-SQL. (Oracle Standard One)

Oracle har helt klart kommet seg med tanke på prising, men et par ting som kanskje bør trekkes fram i denne sammenhegen, siden du nevner Oracle Standard One):

 

Oracle Standard One støtter ikke clustering, ei heller replikering. Videre har den etter det jeg ikke se noe tilsvarende Analysis Services (Business Intelligence) i SQL Server. Prisen er omtrent den samme som det SQL Server 2005 Standard Edition vil komme på. SQL Server 2005 Standard Edition inkluderer de funksjonalitetene jeg trakk fram, og har i tillegg en langt hyggeligere prising i feiltolerante løsninger enn det Oracle har, og det samme gjelder for løsninger med flerkjerneprosessorer.

 

Min konklusjon blir at man får mer for pengene med SQL Server 2005 når den kommer enn det man får med Oracle, såfremt ikke Oracle nok en gang ser på prispolitikken sin. Det største usikkerhetsmomentet for min del med SQL Server 2005 er hvilken versjon som kommer til å bli inkludert i Small Business Server, og når denne blir sluppet med SQL Server 2005 i steden for SQL Server 2000.

Det er nok ingen tvil om at MS-SQL er rimeligere, men differansen er såpass liten at det ikke byr på vanskelige spørsmål når løsningene skal budsjetteres

 

Oracle har forresten endret en del på lisensieringen sin rundt flerkjerne cpu, virtualisering og små-clustere.

 

Business Intelligence funksjonaliteten du nevner jeg ikke sett på, men lover at jeg skal gi MS-SQL mer oppmerksomhet så snart Microsoft er klare med en versjon for UNIX.

[blackbrrd]

Oracle sin database har vel den fordelen at den kan kjøre på linux som man kan få tak i gratis.

 

Jeg er rimelig sikker på at en windows server variant som takler f.eks 8 cores og mer enn 4gb minne koster endel..

 

Oracle sin rabatt for flerkjerner er forresten latterlig, leste i en annen artikkel at de tar betalt fullt for den første core'n og 0,75 for de påfølgende. Også runder de oppover

 

Mao,

dual core = 1+0,75 = 1,75 => 2 = null rabatt

dual dual core = 1+0,75x3 = 3,25 => 4 = null rabatt

quad dual core = 1+0,75*7 = 6,25 => 7 = bittelitt rabatt

 

Husker desverre ikke hvor jeg leste dette, muligens theinquirer.com

Endret 15. august 2005 av blackbrrd

[perbu]

Oracle sin database har vel den fordelen at den kan kjøre på linux som man kan få tak i gratis.

Du vil ikke kjøre Oracle på en usupportert plattform. Iallefall ikke noe som minner om produksjon. Og skal du ha en supportert plattform så har du vær så god å hoste opp en god del kroner.

[blackbrrd]

Oracle sin database har vel den fordelen at den kan kjøre på linux som man kan få tak i gratis.

Du vil ikke kjøre Oracle på en usupportert plattform. Iallefall ikke noe som minner om produksjon. Og skal du ha en supportert plattform så har du vær så god å hoste opp en god del kroner.

Jupp, virker som du har rett der:

 

http://www.oracle.com/technology/tech/linu...inux_faq.html#5

What distributions of Linux does Oracle support?

 

 

The following distributions are certified and supported by Oracle:

 

Red Hat Enterprise Linux AS and ES (RHEL)

Novell SUSE LINUX Enterprise Server (SLES)

Asianux (only supported in the Asia/Pacific region). The products supported by Oracle, as part of Asianux, include:

Red Flag DC 4.1 Asianux Inside

Miracle Linux 3.0 Asianux Inside