---

Hej

Jeg skal have lavet en ny server og det vigtigste er at den er hurtig til at
håndtere MySQL. På min nuværende server kan nogle fritekst forespørgelser
tage op til 5 sekunder og det er ikke fordi databasen er særlig stor (80 MB,
ca. 300.000 poster) så mit gæt er at CPU og RAM er for langsom.

Hvad kan anbefales af Bundort, CPU og RAM ?

OS er WindowsXP

Takker

/HK

---

On Sun, 15 Jun 2008 22:05:46 +0200, "Harald" <noname@nomail.dk> wrote:

>Hej
>
>Jeg skal have lavet en ny server og det vigtigste er at den er hurtig til at
>håndtere MySQL. På min nuværende server kan nogle fritekst forespørgelser
>tage op til 5 sekunder og det er ikke fordi databasen er særlig stor (80 MB,
>ca. 300.000 poster) så mit gæt er at CPU og RAM er for langsom.
>
>Hvad kan anbefales af Bundort, CPU og RAM ?
>
>OS er WindowsXP
>
Ikke at jeg ved det mindste om MySQL, men sådan generalt:
Har du overvejet at tune din MySQL, lave index ?
Harddiskhastighed ?
Seperat disk(system) til database / transactionslog /backup ?

/Hans

---

"Hans Kjaergaard" <hans.k2teknik@post5.tele.dk> skrev i en meddelelse
news:s5va54hs3ki31o9vmi4e9j1k69eflkrmv5@4ax.com...
> On Sun, 15 Jun 2008 22:05:46 +0200, "Harald" <noname@nomail.dk> wrote:
>
>>Hej
>>
>>Jeg skal have lavet en ny server og det vigtigste er at den er hurtig til
>>at
>>håndtere MySQL. På min nuværende server kan nogle fritekst forespørgelser
>>tage op til 5 sekunder og det er ikke fordi databasen er særlig stor (80
>>MB,
>>ca. 300.000 poster) så mit gæt er at CPU og RAM er for langsom.
>>
>>Hvad kan anbefales af Bundort, CPU og RAM ?
>>
>>OS er WindowsXP
>>
> Ikke at jeg ved det mindste om MySQL, men sådan generalt:
> Har du overvejet at tune din MySQL, lave index ?
> Harddiskhastighed ?
> Seperat disk(system) til database / transactionslog /backup ?

Der er lavet index, harddisken er en WD VelociRaptor. Raptor disken er lige
blevet sat i og test viser at den er ca. dobbelt så hurtig som den gamle der
sad i men alligevel har tiden på MySQL forespørgelser ikke ændret sig
overhovedet, så derfor tror jeg stadig mest på at det er MB, CPU og RAM der
er langsom.

Det skal siges at når der søges i MySQL basen på en enkelt tabel så tager
søgninger i de 300.000 poster ca. 0.2 sek., det er først når der foretages
fritekst søgninger over flere forskellige tabeller/index at tiden bliver
lidt lang.

/HK

---

> Der er lavet index, harddisken er en WD VelociRaptor. Raptor disken er
> lige blevet sat i og test viser at den er ca. dobbelt så hurtig som den
> gamle der sad i men alligevel har tiden på MySQL forespørgelser ikke
> ændret sig overhovedet, så derfor tror jeg stadig mest på at det er MB,
> CPU og RAM der er langsom.

Jeg tror det er dårlig database-kode-design. Det har gjort underværker da
jeg havde en sql-gut på her med samme problem.

---

"Nicolai" <spam2005@nifo.dk> skrev i en meddelelse
news:48558b0a$0$56778$edfadb0f@dtext02.news.tele.dk...
>> Der er lavet index, harddisken er en WD VelociRaptor. Raptor disken er
>> lige blevet sat i og test viser at den er ca. dobbelt så hurtig som den
>> gamle der sad i men alligevel har tiden på MySQL forespørgelser ikke
>> ændret sig overhovedet, så derfor tror jeg stadig mest på at det er MB,
>> CPU og RAM der er langsom.
>
> Jeg tror det er dårlig database-kode-design. Det har gjort underværker da
> jeg havde en sql-gut på her med samme problem.

database-kode-design er i orden.

/H

---

>> Jeg tror det er dårlig database-kode-design. Det har gjort underværker da
>> jeg havde en sql-gut på her med samme problem.
>
> database-kode-design er i orden.

Næppe ;)

---

"Nicolai" <spam2005@nifo.dk> skrev i en meddelelse
news:485602f5$0$56792$edfadb0f@dtext02.news.tele.dk...
>>> Jeg tror det er dårlig database-kode-design. Det har gjort underværker
>>> da jeg havde en sql-gut på her med samme problem.
>>
>> database-kode-design er i orden.
>
> Næppe ;)

Hvorfor tror du ike det, det er en meget simpel database og diverse tuning
guider og mange forslag fra folk der ved noget om den slags er blevet fulgt.
Men jeg modtager gerne nye forslag til forbedringer.

/HK

---

On Mon, 16 Jun 2008 09:33:02 +0200, "Harald" <noname@nomail.dk> wrote:

> Hvorfor tror du ike det, det er en meget simpel database og diverse tuning
> guider og mange forslag fra folk der ved noget om den slags er blevet fulgt.
> Men jeg modtager gerne nye forslag til forbedringer.

Dengang jeg lærte den slags, sagde min lærer, at hvis man havde brug
for at lave friteks-søgninger, så havde man ikke lavet sit database-
design ordentligt. Det vil jeg meget langt hen ad vejen give ham ret
i.

-A
--
Hvis du bruger et anti-spam program, der spammer os andre i hvert
eneste indlæg, ser jeg ikke dine indlæg. Jeg filtrerer dem bort.

---

"Asbjorn Hojmark" <Asbjorn@Hojmark.ORG> skrev i en meddelelse
news:c65d54151pl3cb9hlicpuh4ml9hhhmrq68@hojmark.net...
> On Mon, 16 Jun 2008 09:33:02 +0200, "Harald" <noname@nomail.dk> wrote:
>
>> Hvorfor tror du ike det, det er en meget simpel database og diverse
>> tuning
>> guider og mange forslag fra folk der ved noget om den slags er blevet
>> fulgt.
>> Men jeg modtager gerne nye forslag til forbedringer.
>
> Dengang jeg lærte den slags, sagde min lærer, at hvis man havde brug
> for at lave friteks-søgninger, så havde man ikke lavet sit database-
> design ordentligt. Det vil jeg meget langt hen ad vejen give ham ret

Det er en bog database hvor der bla. er et text felt hvor der kan stå masser
af tekst i og der skal kunne søges i hele teksten, der er også en titel
tekst hvor man skal kunne søge på de enkelte ord i titlen og det samme
gælder for forfatter navnet. Så jeg kan ikke forestille mig hvordan man
skulle kunne uden om fritekst søgning men nu ved jeg så heller ikke alt om
database design.

/HK

---

"Harald" <noname@nomail.dk> skrev i en meddelelse
news:4855761b$0$90269$14726298@news.sunsite.dk...
> Jeg skal have lavet en ny server og det vigtigste er at den er hurtig til
> at håndtere MySQL. På min nuværende server kan nogle fritekst
> forespørgelser tage op til 5 sekunder og det er ikke fordi databasen er
> særlig stor (80 MB, ca. 300.000 poster) så mit gæt er at CPU og RAM er for
> langsom.
>

Hvordan er dit CPU load i de 5 sekunder søgningen kører?

Er du sikker på at dit DB design er 100% optimalt for de søgninger du laver?
Hvis jeg var dig ville jeg bruge ekstra meget tid på databasedesign i stedet
for at smide penge efter hardware...i worst case så hjælper nyt hardware
ikke en dyt...

MVH
Thomas

---

"Thomas Eg Jørgensen" <thomas@killspam.notaplan.com> skrev i en meddelelse
news:48563f84$0$90268$14726298@news.sunsite.dk...
> "Harald" <noname@nomail.dk> skrev i en meddelelse
> news:4855761b$0$90269$14726298@news.sunsite.dk...
>> Jeg skal have lavet en ny server og det vigtigste er at den er hurtig til
>> at håndtere MySQL. På min nuværende server kan nogle fritekst
>> forespørgelser tage op til 5 sekunder og det er ikke fordi databasen er
>> særlig stor (80 MB, ca. 300.000 poster) så mit gæt er at CPU og RAM er
>> for langsom.
>>
>
> Hvordan er dit CPU load i de 5 sekunder søgningen kører?
>
> Er du sikker på at dit DB design er 100% optimalt for de søgninger du
> laver? Hvis jeg var dig ville jeg bruge ekstra meget tid på databasedesign
> i stedet for at smide penge efter hardware...i worst case så hjælper nyt
> hardware ikke en dyt...

CPU load er 100% i de 5 sekunder. Og jeg tror ikke designet kan gøres meget
bedre, det er en meget enkelt base og som tidligere nævnt er det kun når der
søges efter fritekst i flere tabeller på samme tid at der er problemer med
tiden.

/HK

---

"Harald" <noname@nomail.dk> wrote in message
news:48565396$0$90271$14726298@news.sunsite.dk...
> CPU load er 100% i de 5 sekunder.

Det er et godt bud at det vil gentage sig på nyt hardware fordi din søgning
ikke er optimeret.

> Og jeg tror ikke designet kan gøres meget bedre, det er en meget enkelt
> base og som tidligere nævnt er det kun når der søges efter fritekst i
> flere tabeller på samme tid at der er problemer med tiden.

Det er netop derfor dit design er "forkert". Hvis det var designet til at
være én tabel der blev lavet søgning i, ville resultatet fremkomme hurtigere
(teoretisk, men ofte også praktisk!)

mvh
///M

---

"///M" <nomail> skrev i en meddelelse
news:4858d07a$0$90267$14726298@news.sunsite.dk...
>
> "Harald" <noname@nomail.dk> wrote in message
> news:48565396$0$90271$14726298@news.sunsite.dk...
>> CPU load er 100% i de 5 sekunder.
>
> Det er et godt bud at det vil gentage sig på nyt hardware fordi din
> søgning ikke er optimeret.
>
>> Og jeg tror ikke designet kan gøres meget bedre, det er en meget enkelt
>> base og som tidligere nævnt er det kun når der søges efter fritekst i
>> flere tabeller på samme tid at der er problemer med tiden.
>
> Det er netop derfor dit design er "forkert". Hvis det var designet til at
> være én tabel der blev lavet søgning i, ville resultatet fremkomme
> hurtigere (teoretisk, men ofte også praktisk!)

Sådan lige kort:

Tabel1:
Titel : char
Forfatter : int

Tabel2:
id : int
Navn : char

Forfatter i Tabel1 henviser til id i Tabel2. At samle dette i en enkelt
tabel ville betyde at hvis man ville ændre forfatter navnet så skulle man
ind i alle de tusinder at poster i Tabel1 hvor navnet er brugt og ændre det,
i stedet for kun at skulle ændre det et enkelt sted i Tabel2.
Det ville være forkert design efter min mening.

/HK

---

Asbjorn Hojmark wrote:

> Dengang jeg lærte den slags, sagde min lærer, at hvis man havde brug for
> at lave friteks-søgninger, så havde man ikke lavet sit database- design
> ordentligt. Det vil jeg meget langt hen ad vejen give ham ret i.

K*log(N) < N gælder kun for tilpas store N. Hvis tabellen er lille, kan
det ikke nødvendigvis betale sig at indeksere på søgefelterne. Hvis OPs
database kun fylder 80 MB, burde det hele kunne være i memory (dermed
ikke sagt at det ikke kan betale sig at indeksere, og med 300k rækker i
tabellen burde der være en gevinst ved at indeksere, uanset om databasen
ligger i RAM eller på floppydiske).

--
Jesper Lund

---

Harald wrote:

> Hvorfor tror du ike det, det er en meget simpel database og diverse
> tuning guider og mange forslag fra folk der ved noget om den slags er
> blevet fulgt. Men jeg modtager gerne nye forslag til forbedringer.

Nu er det her ikke en DB gruppe, men generelt bør du have indeks på de
kolonner som du laver (hyppige) søgninger på. Uden indeks er arbejdet
proportionalt med antal rækker N, mens et indeks gør arbejdet
proportionalt med log(N). Det er groft sagt som forskellen mellem at søge
i en sorteret og usorteret tabel.

--
Jesper Lund

---

Harald wrote:

> SÃ¥dan lige kort:
>
> Tabel1:
> Titel : char
> Forfatter : int
>
> Tabel2:
> id : int
> Navn : char
>
> Forfatter i Tabel1 henviser til id i Tabel2. At samle dette i en enkelt
> tabel ville betyde at hvis man ville ændre forfatter navnet så skulle
> man ind i alle de tusinder at poster i Tabel1 hvor navnet er brugt og
> ændre det, i stedet for kun at skulle ændre det et enkelt sted i Tabel2.
> Det ville være forkert design efter min mening.

[vi er vist kommet OT for gruppen]

Og hvad er din søgning? Lad os se et SQL statement.

Jeg går ud fra at id er primary key i Tabel2 (dermed kan du søge på
forfatter id i log(n) tid), men "titel" kan ikke være primary key i
Tabel1 da to bøger har samme titel. Jeg formoder at primary key så er et
løbenummer, og at skal så overveje om der skal være indeks på titel.

Hvis du søger på forekomster af ord midt i titel, er du generelt nødt til
at løbe alle (300k?) rækker i gennem. Det vil ikke hjælpe noget at samle
tabel 1 og 2 (tværtimod vil det være imod god DB design).

--
Jesper Lund