---

Hejsa...

Hvordan håndterer man egentlig, sådan helt generelt, bedst den
situation, hvor en database er under fortasat opbygning (direkte
indtastning af een post ad gangen), men samtidig med opbygningen også
skal kunne betjene brugerne og besvare forespørgsler bedst muligt.?

I det konkrete tilfælde drejer det sig om en MySql database der vil
slutte på ca. 420.000 poster og som pt. er ca. halvvejs. Databasen er
oprettet og indexeret med henblik på de søgemuligheder der skal tilbydes
slutbrugerne. Og det funker også rimeligt godt i praksis.

Men indtasterne oplever stigende ventetider i forbindelse med nye
indtastninger (=ca. 1.500 poster dagligt). Jeg formoder, at dette
skyldes, at det efterhånden tager længere og længere tid at indexere
databasen efter hver indtastning - jo større den bliver.

Er dette korrekt opfattet.?

Og i så fald, hvad gør man for at undgå det.?

Bør man i virkeligheden gemme nye indtastninger midlertidigt i en
tmp.tabel, og så overføre dem til den rigtige tabel i klumper af en vis
størrelse.?

Forudsætninger iøvrigt:
Windows Vista, Apache 2.2.11, PHP 5.1.30, MySql 5.1.30,

---

Arne Feldborg skrev:
> Hejsa...
>
> Hvordan håndterer man egentlig, sådan helt generelt, bedst den
> situation, hvor en database er under fortasat opbygning (direkte
> indtastning af een post ad gangen), men samtidig med opbygningen også
> skal kunne betjene brugerne og besvare forespørgsler bedst muligt.?
>
> I det konkrete tilfælde drejer det sig om en MySql database der vil
> slutte på ca. 420.000 poster og som pt. er ca. halvvejs. Databasen er
> oprettet og indexeret med henblik på de søgemuligheder der skal tilbydes
> slutbrugerne. Og det funker også rimeligt godt i praksis.
>
> Men indtasterne oplever stigende ventetider i forbindelse med nye
> indtastninger (=ca. 1.500 poster dagligt). Jeg formoder, at dette
> skyldes, at det efterhånden tager længere og længere tid at indexere
> databasen efter hver indtastning - jo større den bliver.
>
> Er dette korrekt opfattet.?
>
> Og i så fald, hvad gør man for at undgå det.?
>
> Bør man i virkeligheden gemme nye indtastninger midlertidigt i en
> tmp.tabel, og så overføre dem til den rigtige tabel i klumper af en vis
> størrelse.?

Det er naturligvis en mulighed, men for mig lyder det nu mere som et
problem med databasedesign/indeksering (men det plejer I jo at have styr
på) eller mere sandsynligt at serveren er underdimensioneret/uegnet
(Vista er jo forslugen)
Har du prøvet at overvåge CPU-belastningen på serveren?

Jeg har haft en væsentlig større database kørende, hvor der løbende blev
hældt data ind (, samtidig med 4-5 brugeropslag pr. sekund. Helt uden
problemer på en 80386 med Linux.

Her opstod der i løbet af dagen (basen blev tømt hver nat) store
performanceproblemer, indtil basen var tilstrækkeligt indekseret.

---

Gert Krabsen <fjernkrabsen@fjernkrabsenfjern.dk> skrev Fri, 15 May 2009
08:25:39 +0200

>Det er naturligvis en mulighed, men for mig lyder det nu mere som et
>problem med databasedesign/indeksering (men det plejer I jo at have styr
>på) eller mere sandsynligt at serveren er underdimensioneret/uegnet
>(Vista er jo forslugen)
>Har du prøvet at overvåge CPU-belastningen på serveren?
>
Det er nu ikke der problemet ligger. Resten af systemet incl.
udsortering og visning af data kører jo fint nok, og det samme med de
øvrige ting på den samme server (og isoleret set er det jo ikke nogen
stor databse vi her snakker om).

Problemet er for mig at se, at der pga. den måde data bliver udlistet
på, og de sorteringsmuligheder brugeren har, er blevet tilføjet et par
ekstra felter og et par ekstra indexer udover hvad man normalt ville
gøre i en lignede situation.

Og disse indexer skal jo også opdateres for hver ny indtastning og det
kan mærkes, især når der er flere indtastere igang samtidig.

Det er da også kendetegnende, at søgetiden *ikke* er steget efterhånden
som databasen er vokset - hvorimod den tid det tager at gemme nye
indtastninger har været jævnt sigende.

Da indtastningen jo strækker sig over en begrænset periode (vi er som
nævnt ca. halvfærdig nu) vil det ikke genere mig at skulle lave een
eller anden midlertidig løsning for at give indtasterne bedre vilkår her
og nu.

Spørgsmålet er bare, hvad der er mest smart at gøre. De samme eller
lignende problemer må jo også være kendte i rigtig store systemer.?

---

Arne Feldborg skrev:
> Gert Krabsen <fjernkrabsen@fjernkrabsenfjern.dk> skrev Fri, 15 May 2009
> 08:25:39 +0200
>
>> Det er naturligvis en mulighed, men for mig lyder det nu mere som et
>> problem med databasedesign/indeksering (men det plejer I jo at have styr
>> på) eller mere sandsynligt at serveren er underdimensioneret/uegnet
>> Har du prøvet at overvåge CPU-belastningen på serveren?
>>
> Det er nu ikke der problemet ligger. Resten af systemet incl.
> udsortering og visning af data kører jo fint nok, og det samme med de
> øvrige ting på den samme server (og isoleret set er det jo ikke nogen
> stor databse vi her snakker om).
>
> Problemet er for mig at se, at der pga. den måde data bliver udlistet
> på, og de sorteringsmuligheder brugeren har, er blevet tilføjet et par
> ekstra felter og et par ekstra indexer udover hvad man normalt ville
> gøre i en lignede situation.
>
> Og disse indexer skal jo også opdateres for hver ny indtastning og det
> kan mærkes, især når der er flere indtastere igang samtidig.

Hvor mange indexer snakker vi om?

> Det er da også kendetegnende, at søgetiden *ikke* er steget efterhånden
> som databasen er vokset - hvorimod den tid det tager at gemme nye
> indtastninger har været jævnt sigende.

Kan I mærke forskel på, om der er een eller tre indtastere igang? Det
burde være ligegyldigt, for selve sql-kaldet er jo intet i sammenligning
med den tid, indtasteren bruger på at udfylde formularen.

Eller er det sådan, at opdateringsrutinerne bruger tabeller, som
slutbruger ikke anvender (f.eks. til kontrol af det indtastede) og netop
_disse_ tabeller mangler indekser?
Eller bruger sql-kald med komplicerede sub-queryes eller joins?

Eller skyldes det, at i gemmer grafik (indscannet billede) i tabellerne?
- så kan jeg godt forestille mig, at opdateringen bliver tung - og
tungere end udsøgningen.
Især hvis der ved et uheld er sat index på grafik-feltet (hvis man kan
det)..

---

Gert Krabsen <fjernkrabsen@fjernkrabsenfjern.dk> skrev Fri, 15 May 2009
19:41:13 +0200

>Hvor mange indexer snakker vi om?
>
Set i en større perspektiv er det ikke noget at skrive hjem om. Den
aktuelle tabel fylder pt. 25 MegaByte og indexet knapt 20 MB fordelt på
8 indexer (text) plus Primary (id).

Men det er den eneste grund jeg kan se til, at indtasterne oplever
stigende ventetider på indlægning af data efterhånden som databasen
vokser.

Jeg er godt klar over, at færre felter og færre og mere intelligent
udtænkte indexer måske kunne løse en del af problemet. Men jeg er
egentlig mere interesseret i, at høre hvordan man mest hensigtsmæssigt
omgår problemet. Strengt taget er der jo ingen grund til, at disse
indexer bliver opdateret flere gange i minuttet,

Da en del af indexerne omfatter varchar på op til 150 tegn kunne man
måske hente noget ved at begrænse størelsen af index. Men jeg kan ikke
helt genemskue, om det er en god ide.

>Eller er det sådan, at opdateringsrutinerne bruger tabeller, som
>slutbruger ikke anvender (f.eks. til kontrol af det indtastede) og netop
>_disse_ tabeller mangler indekser?
>
Nej, der indtastes direkte i brugstabellen. Indtasteren har tildelt en
pulje på eks. 100 poster og linierne er i forvejen indsat. Så det er
altså en "update" ikke en "insert".

>Eller bruger sql-kald med komplicerede sub-queryes eller joins?
>
Nej, det kan jeg slet ikke finde ud af at lave.

Og som nævnt er problemet der når der skal gemmes data, ikke når der
bare bladres igennem posterne.

Eneste fix-faxerier er, at alle indtastninger af sikkerhedsgrunde bliver
log-ført i en simpel tekstfil, men det er ikke dér problemet er.

>Eller skyldes det, at i gemmer grafik (indscannet billede) i tabellerne?
>- så kan jeg godt forestille mig, at opdateringen bliver tung - og
>tungere end udsøgningen.
>
Nej, det er kun filnavne der er i databasen. Billederne ligger slet ikke
på den samme server, (men det har nu helt andre årsager, nemlig et
spørgsmål om båndbredde).

---

Arne Feldborg wrote:

> Nej, der indtastes direkte i brugstabellen. Indtasteren har tildelt en
> pulje på eks. 100 poster og linierne er i forvejen indsat. Så det er
> altså en "update" ikke en "insert".

Hvis det er en stadigt stigende svartid, så lugter det lidt af, at dit
update statement ikke bruger indexes.

--
Med venlig hilsen
Stig Johansen

---

Arne Feldborg wrote:
> Hvordan håndterer man egentlig, sådan helt generelt, bedst den
> situation, hvor en database er under fortasat opbygning (direkte
> indtastning af een post ad gangen), men samtidig med opbygningen også
> skal kunne betjene brugerne og besvare forespørgsler bedst muligt.?
>
> I det konkrete tilfælde drejer det sig om en MySql database der vil
> slutte på ca. 420.000 poster og som pt. er ca. halvvejs. Databasen er
> oprettet og indexeret med henblik på de søgemuligheder der skal tilbydes
> slutbrugerne. Og det funker også rimeligt godt i praksis.
>
> Men indtasterne oplever stigende ventetider i forbindelse med nye
> indtastninger (=ca. 1.500 poster dagligt). Jeg formoder, at dette
> skyldes, at det efterhånden tager længere og længere tid at indexere
> databasen efter hver indtastning - jo større den bliver.
>
> Er dette korrekt opfattet.?

Hvis serveren har memory nok til at cacje indexene, så nej.


> Bør man i virkeligheden gemme nye indtastninger midlertidigt i en
> tmp.tabel, og så overføre dem til den rigtige tabel i klumper af en vis
> størrelse.?

Medmindre der er grund til at brugerne skal se opdateringer i real
time så lyder det som en ganske fornuftig tilgang.

Ikke p.g.a. performance men for at sikre brugerne konsistente
søge resultater.

Arne