/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Hurtig databasesystem?
Fra : Johan


Dato : 07-09-01 15:11

Hej

Jeg synes efterhånden mine MySQL server er begyndt at blive en smule for
sløv. Det drejer sig om ret tunge databaser med mange data i. Nogle der
kender gode databaseservere som jeg eventuelt kunne kigge på?

Håber der kommer lidt råd og gerne links

mvh

Johan



 
 
Peter Lykkegaard (07-09-2001)
Kommentar
Fra : Peter Lykkegaard


Dato : 07-09-01 15:23


"Johan" <tcr480@ofir.dk> wrote in message news:9nakh5$1m$1@sunsite.dk...
> Hej
>
> Jeg synes efterhånden mine MySQL server er begyndt at blive en smule for
> sløv. Det drejer sig om ret tunge databaser med mange data i. Nogle der
> kender gode databaseservere som jeg eventuelt kunne kigge på?
>
> Håber der kommer lidt råd og gerne links
>
Hardware?
Index?
dårligt designet SQL?

Database systemer er ikke hurtigere end de tre ovennævnte tillader
Man kan poste mange penge i avanceret raid/fler cpu etc, men hjælper ikke
meget hvis databasen bliver belastet af knap så optimalt design

Ikke at jeg siger at det gælder for dine systemer, men det er bare det man
almindeligvis ser

mvh/Peter Lykkegaard



Johan (07-09-2001)
Kommentar
Fra : Johan


Dato : 07-09-01 15:21

> Hardware?
Dual 1 GHZ P3, 1 GB RAM, 2 x 36 GB HDD i RAID 0

> Index?
> dårligt designet SQL?

Jamen, det er der skam, men hjælper intet så længe at databasen er rimelig
tung? Findes der ikke hurtigere systemer end MySQL?

> Database systemer er ikke hurtigere end de tre ovennævnte tillader
> Man kan poste mange penge i avanceret raid/fler cpu etc, men hjælper ikke
> meget hvis databasen bliver belastet af knap så optimalt design

Der er fin design på databasen og SQL sætningerne, og det går egentlig også
fint. Men det begynder at knibe ved de 100.000+ poster i tabellen, hvor den
skal finde bestemte. Og vil gerne speede denne tid lidt op. Det er sådanset
derfor.

> Ikke at jeg siger at det gælder for dine systemer, men det er bare det man
> almindeligvis ser

Det ved jeg, og har også optimeret så meget som jeg kan i SQL sætningerne og
databasedesignet, men er ikke tilfreds endnu

mvh

Johan



Peter Lykkegaard (07-09-2001)
Kommentar
Fra : Peter Lykkegaard


Dato : 07-09-01 16:12


"Johan" <tcr480@ofir.dk> wrote in message news:9nal4s$1t1$1@sunsite.dk...
> > Hardware?
> Dual 1 GHZ P3, 1 GB RAM, 2 x 36 GB HDD i RAID 0
>
> > Index?
> > dårligt designet SQL?
>
> Jamen, det er der skam, men hjælper intet så længe at databasen er rimelig
> tung? Findes der ikke hurtigere systemer end MySQL?
>
Både og
Jeg arbejder selv med MSSQL, men man kan med god samvittighed sige at den er
langsommere ned MySQL
Man kan også slippe godt fra at påstå at den er hurtigere - det kommer an på
mange ting

MSSQL har nogle rimelige værktøjer til at finde flaskehalse
Men undres en gang imellem hvor lidt der skal til

> Der er fin design på databasen og SQL sætningerne, og det går egentlig
også
> fint. Men det begynder at knibe ved de 100.000+ poster i tabellen, hvor
den
> skal finde bestemte. Og vil gerne speede denne tid lidt op. Det er
sådanset
> derfor.
>
Hvordan finder du bestemte?

Bruger du noget ala
Like '%xx%'

eller
<> 'xxx'

Begge resulterer i en lidt trist perfomance

Bruger du cursors eller midlertidige tabeller
Begge kan have indfyldese på din performance

Jeg har fx lige skrællet små 500 milli sekunder af en kompleks query med en
temporærer tabeller
Nu kører den på omkring de 100 ms - uden at røre ved index
Jeg har nu også fjernet lidt "nice to have" features fra den samtidig, så
den opfylder mine behov ("need to have"

mvh/Peter Lykkegaard



Johan (09-09-2001)
Kommentar
Fra : Johan


Dato : 09-09-01 13:04

> Hvordan finder du bestemte?
>
> Bruger du noget ala
> Like '%xx%'
>
> eller
> <> 'xxx'

nej kører ALTID sid = 'sid' så der falder den ikke

mvh

Johan



Peter Brodersen (07-09-2001)
Kommentar
Fra : Peter Brodersen


Dato : 07-09-01 18:01

On Fri, 7 Sep 2001 16:21:11 +0200, "Johan" <tcr480@ofir.dk> wrote:

>Det ved jeg, og har også optimeret så meget som jeg kan i SQL sætningerne og
>databasedesignet, men er ikke tilfreds endnu

Tør man udbede sig en EXPLAIN på nogle af de queries, der går sløvt?

--
- Peter Brodersen

Lars Petersen (09-09-2001)
Kommentar
Fra : Lars Petersen


Dato : 09-09-01 15:03

> Jeg synes efterhånden mine MySQL server er begyndt at blive en smule for
> sløv. Det drejer sig om ret tunge databaser med mange data i. Nogle der
> kender gode databaseservere som jeg eventuelt kunne kigge på?

www.postgresql.dk / www.postgresql.org <- PostgreSQL skulle være en af de
hurtigste derude :)

Den er nem at sætte op og den kører bare uden problemer!

--
-
Lars
http://coder.dk/sohofaq.php - Uofficiel WOL SOHO 77 FAQ
http://wshlman.moons.dk/ - Say goodbye to GameSpy - A Free Half Life
Manager!
When mailing me, remember there is no truth in my mail!




Niels Andersen (10-09-2001)
Kommentar
Fra : Niels Andersen


Dato : 10-09-01 09:39

"Lars Petersen" <lars@truth.ioflux.net> wrote in message
news:JEKm7.4704$9V5.297782@news000.worldonline.dk...
> www.postgresql.dk / www.postgresql.org <- PostgreSQL skulle være en af de
> hurtigste derude :)

Jeg har nu hørt gang på gang at MySQL er lidt hurtigere end PostgreSQL, mod
færre features.

--
Mvh.

Niels Andersen



Poul-Erik Andreasen (14-09-2001)
Kommentar
Fra : Poul-Erik Andreasen


Dato : 14-09-01 06:25

Niels Andersen wrote:
>
> "Lars Petersen" <lars@truth.ioflux.net> wrote in message
> news:JEKm7.4704$9V5.297782@news000.worldonline.dk...
> > www.postgresql.dk / www.postgresql.org <- PostgreSQL skulle være en af de
> > hurtigste derude :)
>
> Jeg har nu hørt gang på gang at MySQL er lidt hurtigere end PostgreSQL, mod
> færre features.

Det er sådan set også rigtigt så længe vi taler om små databaser og få
søgninger(hvilket har gjort MySQL til et hit på WWW). Men postgres
skalerer bedre. Om det gør Postgres til et valg i den aktuelle sag kan
jeg ikke afgøre
men der er en interessant artikel om det på :

http://www.phpbuilder.com/columns/tim20000705.php3?page=1

Artiklen er ikke helt ung og nogen af de ting han forudser er allerede
sket
f.eks Postgres har i den nyest version fået fjernet deres 8K
row-limitations

> --
> Mvh.
>
> Niels Andersen

--
-
Poul-Erik Andreasen
Hvis du mangler nogen til noget eller du kan noget for nogen.
http://linux-freelance.pea.dk

Nikolaj Hansen (21-09-2001)
Kommentar
Fra : Nikolaj Hansen


Dato : 21-09-01 21:32

In article <4%_m7.5947$9V5.328904@news000.worldonline.dk>, niels-
usenet@myplace.dk says...

> Jeg har nu hørt gang på gang at MySQL er lidt hurtigere end PostgreSQL, mod
> færre features.

Færre features? Jae, da jeg sidst rodede med MySql understøttede den
ikke engang row locking, men kun table locking. Så den overholder i
hvert fald ikke ACID standarden.

Så det der med at den ikke skalerer, ja jeg vil sige den ikke KAN
skalere videre end til webside server.

Men det er da en lille bitte smule bedre end Access..

Jeg anbefaler helt klart et rigtigt dbms som PostgressSql.

Heikki Tuuri (23-09-2001)
Kommentar
Fra : Heikki Tuuri


Dato : 23-09-01 19:10

Hi!

Nikolaj Hansen wrote in message ...
>In article <4%_m7.5947$9V5.328904@news000.worldonline.dk>, niels-
>usenet@myplace.dk says...
>
>> Jeg har nu hørt gang på gang at MySQL er lidt hurtigere end PostgreSQL,
mod
>> færre features.
>
>Færre features? Jae, da jeg sidst rodede med MySql understøttede den
>ikke engang row locking, men kun table locking. Så den overholder i
>hvert fald ikke ACID standarden.


The transactional table types BDB and InnoDB provide
ACID features in MySQL. InnoDB also has row level locking
and multiversioned concurrency control in style of Oracle.
InnoDB is about as fast (hurtig? :) ) as MyISAM.
See the benchmarks at http://www.innodb.com

>Så det der med at den ikke skalerer, ja jeg vil sige den ikke KAN
>skalere videre end til webside server.


Monty from MySQL AB said that people run MySQL with up to
1500 concurrent connections. It scales yes.

>Men det er da en lille bitte smule bedre end Access..
>
>Jeg anbefaler helt klart et rigtigt dbms som PostgressSql.

Regards,
Heikki Tuuri
Innobase Oy




Nikolaj Hansen (27-09-2001)
Kommentar
Fra : Nikolaj Hansen


Dato : 27-09-01 21:13

In article <fApr7.156$T85.23584@read2.inet.fi>,
Heikki.Tuuri@innobase.inet.fi says...
>
> Heikki Tuuri
> Innobase Oy

the world's fastest disk-based
    database engine brings transactions and row level locking to
MySQL

As you say you BRING transactions and row level locking to mysql.

All of the test on your page is single user single process tests. It it
obvious that mysql is faster at this. If you did it on a flat indexed
file as a single user you could probably get even more performance out
of a system.

"Monty from MySQL AB said that people run MySQL with up to
1500 concurrent connections. It scales yes."

None of your tests are run firing of statements for testing this
however..

http://www.innodb.com

I would like to see a comparison between for example oracle or DB2
compared to your db, when executing the perl script on your page from
say 50 concurrent shells. Is that something you have any tests on?

- Nico

Heikki Tuuri (28-09-2001)
Kommentar
Fra : Heikki Tuuri


Dato : 28-09-01 18:05

Hi!

>the world's fastest disk-based
> database engine brings transactions and row level locking to
>MySQL
>
>As you say you BRING transactions and row level locking to mysql.
>
>All of the test on your page is single user single process tests. It it
>obvious that mysql is faster at this. If you did it on a flat indexed
>file as a single user you could probably get even more performance out
>of a system.
>
>"Monty from MySQL AB said that people run MySQL with up to
>1500 concurrent connections. It scales yes."
>
>None of your tests are run firing of statements for testing this
>however..
>
>http://www.innodb.com
>
>I would like to see a comparison between for example oracle or DB2
>compared to your db, when executing the perl script on your page from
>say 50 concurrent shells. Is that something you have any tests on?


Yes, the tests actually were on the the benchmark page
http://www.innodb.com/bench.html

I measured the following scaling numbers on the 2-CPU Xeon 450 MHz, 512 MB
RAM computer running the Linux kernel 2.4.

Run on MySQL/InnoDB-3.23.39:

number of concurrent client threads
1 2 5 10 20 50 100
--------------------------------------------------------
insert speed
rows / sec 4300 5000 6100 6250 7400

select speed
rows /sec 1750 3030 3330 3330 3290 3150 2380

Thus we see that there are no significant scalability problems with respect
to the number of concurrent client threads. These tests were CPU-bound, and
in the insert test 'top' showed the DB server using 2/3 of CPU time, the
Perl processes 1/3. In the select test the DB server used 1/3 of CPU time
and the Perl processes 2/3.


Note that since these tests run with almost 100 % CPU utilization
and there is no scaling problem, then also the results measured
with just a single user are descriptive of multi-user performance. If
InnoDB wins in a single user test, it also wins in a multi-user
test.

You can see some scalability degradation at 100 users.
I know how to fix it, but have been waiting for evidence from
a real-world application that it occurs also under realistic
workloads.

>- Nico

Regards,

Heikki
Innobase Oy




Nikolaj Hansen (28-09-2001)
Kommentar
Fra : Nikolaj Hansen


Dato : 28-09-01 21:12

In article <K42t7.269$ys5.19387@read2.inet.fi>,
Heikki.Tuuri@innobase.inet.fi says...

>Note that since these tests run with almost 100 % CPU utilization
>and there is no scaling problem, then also the results measured
>with just a single user are descriptive of multi-user performance. If
>InnoDB wins in a single user test, it also wins in a multi-user
>test.

No it does not.. The systems on which you test are all relatively small
servers. Have you considered the possibility of san sollutions on a
multi (16-32 processor) sun machine for instance? Perhaps even routed
over different network interfaces. I can guarantee you that more
concurrent connections yield signifigantly better performance. This has
to do with concurrent reader threads internally in the database. I have
worked as a Oracle DBA for quite a while and have tested this for a
fact. I do not question the fact, that mySql is faster than other
databases on the platforms on which you test. Few use those sizes of
machines in a production enviroment today though.. Actually i think it
would be impossible to run your test on an oracle db with the memory
with which you run the first test. The dbms would probably not even be
able to maintain its own system tables.

Test details: the computer was a 2-CPU Xeon 450 MHz with 512 MB
physical memory and Linux kernel 2.4. Both databases were configured
with a 24 MB buffer pool (called shared cache in PostgreSQL) and
a 4 MB log buffer.

>yu can see some scalability degradation at 100 users.
>I know how to fix it, but have been waiting for evidence from
>a real-world application that it occurs also under realistic
>workloads.

I think it is safe to say that no database scales on a linear base..

Heikki Tuuri (29-09-2001)
Kommentar
Fra : Heikki Tuuri


Dato : 29-09-01 08:59

Hi!

Nikolaj Hansen wrote in message ...
>In article <K42t7.269$ys5.19387@read2.inet.fi>,
>Heikki.Tuuri@innobase.inet.fi says...
>
>>Note that since these tests run with almost 100 % CPU utilization
>>and there is no scaling problem, then also the results measured
>>with just a single user are descriptive of multi-user performance. If
>>InnoDB wins in a single user test, it also wins in a multi-user
>>test.
>
>No it does not.. The systems on which you test are all relatively small
>servers. Have you considered the possibility of san sollutions on a
>multi (16-32 processor) sun machine for instance? Perhaps even routed


One MySQL/InnoDB user runs on a 4-way Sun and is able to handle
an average load of 800 inserts or updates per second, and a peak
load of 2000 inserts/updates per second.

>over different network interfaces. I can guarantee you that more
>concurrent connections yield signifigantly better performance. This has
>to do with concurrent reader threads internally in the database. I have


Then the operation is network-latency bound or disk-bound.
If it were CPU-bound that would not be possible.

>worked as a Oracle DBA for quite a while and have tested this for a
>fact. I do not question the fact, that mySql is faster than other
>databases on the platforms on which you test. Few use those sizes of
>machines in a production enviroment today though.. Actually i think it
>would be impossible to run your test on an oracle db with the memory
>with which you run the first test. The dbms would probably not even be
>able to maintain its own system tables.
>
>Test details: the computer was a 2-CPU Xeon 450 MHz with 512 MB
>physical memory and Linux kernel 2.4. Both databases were configured
>with a 24 MB buffer pool (called shared cache in PostgreSQL) and
>a 4 MB log buffer.


Well, the tables in the test were so small that
24 MB was enough. In production environments some
users of MySQL/InnoDB have 50 GB data.

>>yu can see some scalability degradation at 100 users.
>>I know how to fix it, but have been waiting for evidence from
>>a real-world application that it occurs also under realistic
>>workloads.
>
>I think it is safe to say that no database scales on a linear base..

The scaling in this context means that more threads
do not introduce extra CPU overhead. The CPUs in the
computer run at 100 % in test, but the number of threads
is varied.

Regards,

Heikki
http://www.innodb.com




Nikolaj Hansen (30-09-2001)
Kommentar
Fra : Nikolaj Hansen


Dato : 30-09-01 11:13

If you are currently running enterprise sized systems I really think it
would be more relevant to present test data for that kind of systems on
your homepage then.

And you CAN say the name Oracle on your homepage without being sued
You are in Findland not the US.

I think it could be fun to see a benchmark between your InnoDB and
Oracle on a enterprise scaled system.

And more importantly:

Performance is not all when working with dbms systems. How do you fare
in areas such as:

- Hot backups.
- Multi language support.
- All the other tools needed on a daily basis.

It is possible to use several different network interfaces for cpu bound
tasks. I belive that is the main improvement in oracle 9i the part about
parallel servers not only being a high avalability thing, but also real
load balancing, where you look at several database servers as one logic
server. If the process in question can't be threaded it will still
execute on one of the nodes yes. (I have not seen this running for a
fact though..) Any one care to comment here with their experiences?

That said, I downloaded the latest version of your db for testing, and
there has been signifigant improvements to the db since i worked with it
the last time (then it did NOT scale very well). I am quite impressed
with its performance.

And as always: Opensource have a distinct advantage when competing on a
price / quality comparison with the "big boys" on the market.

Heikki Tuuri (30-09-2001)
Kommentar
Fra : Heikki Tuuri


Dato : 30-09-01 16:34

Hi!

Nikolaj Hansen wrote in message ...
>If you are currently running enterprise sized systems I really think it
>would be more relevant to present test data for that kind of systems on
>your homepage then.


Yes, I will add "success" stories in near future :).
MySQL usually runs in web environments where the load
on the database is really big compared to traditional
business and accounting applications.

>And you CAN say the name Oracle on your homepage without being sued
>You are in Findland not the US.


Well, I obey license conditions regardless of the country :).

>I think it could be fun to see a benchmark between your InnoDB and
>Oracle on a enterprise scaled system.


My friend who is an Oracle Certified Professional said that
Oracle probably would not be able to handle the loads I have
quoted, for example up to 2000 inserts or updates per second.

>And more importantly:
>
>Performance is not all when working with dbms systems. How do you fare
>in areas such as:
>
>- Hot backups.


I will write a program for that. It will probably be non-free software.

>- Multi language support.


MySQL supports national languages of some 20 geographic areas.

>- All the other tools needed on a daily basis.


MySQL has a wealth of front-end tools. I will add more InnoDB
tools as I have time.

>It is possible to use several different network interfaces for cpu bound
>tasks. I belive that is the main improvement in oracle 9i the part about
>parallel servers not only being a high avalability thing, but also real
>load balancing, where you look at several database servers as one logic
>server. If the process in question can't be threaded it will still
>execute on one of the nodes yes. (I have not seen this running for a
>fact though..) Any one care to comment here with their experiences?


During past years people have said that Oracle Parallel Server
is mainly suitable to implement high availability. There are big
performance and administrational problems in distributed databases.
It is a trade-off between communication overhead and CPU power.

MySQL has one-way replication which is widely used to achieve
high availability, and load balancing if part of the load is pure
read queries.

>That said, I downloaded the latest version of your db for testing, and
>there has been signifigant improvements to the db since i worked with it
>the last time (then it did NOT scale very well). I am quite impressed
>with its performance.


Thanks :). If you run the InnoDB monitor:

mysql> create table innodb_monitor (a int) type = innodb;

and can spot some performance bottleneck, I will look into fixing it.

>And as always: Opensource have a distinct advantage when competing on a
>price / quality comparison with the "big boys" on the market.

People who write open source and closed source programs are largely
the same. There is a difference in marketing and distribution.

Regards,

Heikki
http://www.innodb.com




Peter Lykkegaard (10-09-2001)
Kommentar
Fra : Peter Lykkegaard


Dato : 10-09-01 13:17


"Johan" <tcr480@ofir.dk> wrote in message news:9nakh5$1m$1@sunsite.dk...
> Hej
>
> Jeg synes efterhånden mine MySQL server er begyndt at blive en smule for
> sløv. Det drejer sig om ret tunge databaser med mange data i. Nogle der
> kender gode databaseservere som jeg eventuelt kunne kigge på?
>
> Håber der kommer lidt råd og gerne links
>
Prøv at kikke den her igennem
Den gælder godt nok for MSSQL
Men mon ikke flere af tipsene er generelle?
http://www.swynk.com/friends/mcgehee/developers_tuning_tutorial.asp

mvh/Peter Lykkegaard



Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408928
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste