Valg av databasesystem (PHP), leseytelse er viktig

[mikaelandre]

utviklerne av mysql har selv sagt at de prioriterer ytelse over funksjonalitet. derfor legger de ikke til alt som finnes av funksjoner, men prøver å hele tiden ha et system som er kjapt

[roac]

utviklerne av mysql har selv sagt at de prioriterer ytelse over funksjonalitet. derfor legger de ikke til alt som finnes av funksjoner, men prøver å hele tiden ha et system som er kjapt

Resultatet er at de får et system som er kjapt på det det kan gjøre selv, mens de tyngre operasjonene som databasen mangler støtte for å gjøre selv, blir enda tyngre, og det er en av grunnene til at MySQL ikke egner seg for komplekse løsninger. (Med forbehold om at MySQL endelig har kommet opp med vesentlig mer funksjonalitet)

[Oracel]

Lokaltog, hvilken database benytter du nå?

[genstian]

har hørt at postgresql er raskere til vanskelige oppgaver

[roac]

har hørt at postgresql er raskere til vanskelige oppgaver

Jeg har hørt at PostGres skal være god, men relativt gammeldags. Jeg vet ikke om jeg kommer til å sette av ressurser til å se på dette selv, jeg har vel allerede bortimot 10 forskjellige databaseservere jeg bruker, i større eller mindre grad. Favoritten min per dags dato er og blir Microsoft SQL Server 2005

[roac]

Kortere sagt; vil ytelsen droppe kraftig hvis 5000 brukere samtidig skal vise antallet rader i forskjellige tabeller?

 

Ja, hvis 5000 brukere skal utføre COUNT på 1 million rader samtidig så får du store performance problemer (er det derfor dette forumet til tider er siiiiiiiiirup????).

Siden denne tråden uansett er vekket til live igjen: Hvis jeg har forstått problemet rett løser SQL Server 2005 dette med snapshot isolation level. Oracle har noe tilsvarende, men er ikke sikker på hva det kalles der.

[Ueland]

kaffenils: Hvor har du det i fra?

 

Jeg vil gjerne se det systemet som klarer å ha 5000 brukere simultant på en server uansett jeg

 

Forøvrig, tok en rask test her:

 

En count på en tabell med 600 000 rader 50 000 ganger tok 8 sekunder. Da hvis man har nok minne på en server vil MySQL legge hele databasen i minne, og da tar det ikke lang tid.

 

 

Men snakker vi systemer med 5000 SIMULTANE brukere så er det nok et cluster som er løsningen.

[roac]

kaffenils: Hvor har du det i fra?

 

Jeg vil gjerne se det systemet som klarer å ha 5000 brukere simultant på en server uansett jeg

 

Forøvrig, tok en rask test her:

 

En count på en tabell med 600 000 rader 50 000 ganger tok 8 sekunder. Da hvis man har nok minne på en server vil MySQL legge hele databasen i minne, og da tar det ikke lang tid.

 

 

Men snakker vi systemer med 5000 SIMULTANE brukere så er det nok et cluster som er løsningen.

Som sagt, jeg tror ytelsesproblement med count ligger et annet sted. Nå vet jeg lite om MySQL, men det kan virke for meg som om det er problemer med låsing, og derav min kommentar om snapshot isolation level.

[Ueland]

Mysql har valget mellom å enten låse hele tabeller, eller kun rader som blir påvirket.

 

Låsing foregår kun ved oppdateringer av tabeller/rader.

[roac]

Mysql har valget mellom å enten låse hele tabeller, eller kun rader som blir påvirket.

 

Låsing foregår kun ved oppdateringer av tabeller/rader.

Jo da, det er greit nok. Men det jeg ville tippe skjer her er at count venter på at en oppdateringsoperasjon blir ferdig, derav låsingsproblematikk. Jeg forstår det dithen at f eks forumet her gjør hyppig bruk av count, og hvis den må vente på at en oppdatering blir ferdig, så kan det gjøre underverker med ytelsen.

 

Håper jeg forsto kommentaren din rett.