---

Hej

Vi kom til at tænke over nogle begrænsninger i MySQL måske endda SQL
generelt.

Vi skal lave et statistik system som skal kunne håndtere mange unikke
sidevisninger og samtidigt give mulighed for statestik helt ned på time
niveau.

Det vi havde planlagt at gøre var at indsætte en række i en tabel for hver
sidevisning der bliver udført.

Problemet er så bare at har man 1000 sidevisninger pr dag i en måned
(30.000) løber det meget hurtigt op til det max. en int datatype kan have
som er 2,4 milliard.

Det vi logger er ip | host | page | browser | referer | date_time og et par
andre få detajler.

Vores test viser så at 3000 rækker fylder cirka en MB. dvs en måneds data
vil fylde 10MB men har man omvendt så 10000 sidevisninger pr dag så begynder
det at blive en stor DB og snart render man ind i sit max id i tabellen.

Nogen forslag til hvad man gør? laver arkiv tabeller? laver opsumerings
tabeller? eller alternativ struktureringer.

PÅ forhånd tak

Rudi

---

"Rudi W." <rudi@balusta.dk> wrote in message
news:bramto$dha$1@news.cybercity.dk...
> Hej
>
> Vi kom til at tænke over nogle begrænsninger i MySQL måske endda SQL
> generelt.

Jamen dog.


> Det vi havde planlagt at gøre var at indsætte en række i en tabel for hver
> sidevisning der bliver udført.

Det har jeg gjort uden problemer på en del sites.


> Problemet er så bare at har man 1000 sidevisninger pr dag i en måned
> (30.000) løber det meget hurtigt op til det max. en int datatype kan have
> som er 2,4 milliard.

Har du forsøgt at regne det ud i f.eks. år før du rammer loftet?


> Vores test viser så at 3000 rækker fylder cirka en MB. dvs en måneds data
> vil fylde 10MB men har man omvendt så 10000 sidevisninger pr dag så
begynder
> det at blive en stor DB og snart render man ind i sit max id i tabellen.

Det kommer til at fylde en del. Er pladsen et reelt problem?

Mht. SELECT-hastighed kan man jo smide nogle indexes på og rotere data så
man kun har en periodes data per tabel.

Mvh
Jimmy

---

"Jimmy" <nyhedsgruppe2@get2net.danmark> skrev:
>
> "Rudi W." <rudi@balusta.dk> wrote in message
> news:bramto$dha$1@news.cybercity.dk...
> > Hej
> >
> > Vi kom til at tænke over nogle begrænsninger i MySQL måske endda SQL
> > generelt.
>
> Jamen dog.

Ja fint skal det være.

> > Det vi havde planlagt at gøre var at indsætte en række i en tabel for
hver
> > sidevisning der bliver udført.
>
> Det har jeg gjort uden problemer på en del sites.
>
>
> > Problemet er så bare at har man 1000 sidevisninger pr dag i en måned
> > (30.000) løber det meget hurtigt op til det max. en int datatype kan
have
> > som er 2,4 milliard.
>
> Har du forsøgt at regne det ud i f.eks. år før du rammer loftet?

Jeg har desværre regnet. Problemet er at vi har mange forskellige
hjemmesider som har mange hits som vi vil lagre i samme tabel helst.

> > Vores test viser så at 3000 rækker fylder cirka en MB. dvs en måneds
data
> > vil fylde 10MB men har man omvendt så 10000 sidevisninger pr dag så
> begynder
> > det at blive en stor DB og snart render man ind i sit max id i tabellen.
>
> Det kommer til at fylde en del. Er pladsen et reelt problem?

Nææ pladsen kan man vel købe sig til men det kan hurtigt blive udsandsynligt
meget data. Jeg holder meget af et unikt ID til hver række og hvis største
INT er 2,4 milliard så kan der vel max smides det antal rækker ind i hver
tabel.

> Mht. SELECT-hastighed kan man jo smide nogle indexes på og rotere data så
> man kun har en periodes data per tabel.

Løsningen må måske være en kombination af at rotere data og lave
opsumeringstabeller.

/Rudi

---

"Rudi W." <rudi@balusta.dk> wrote in message
news:braop7$gik$1@news.cybercity.dk...
> "Jimmy" <nyhedsgruppe2@get2net.danmark> skrev:
> >
> > "Rudi W." <rudi@balusta.dk> wrote in message
> > news:bramto$dha$1@news.cybercity.dk...
> > > Hej
> > >
> > > Problemet er så bare at har man 1000 sidevisninger pr dag i en måned
> > > (30.000) løber det meget hurtigt op til det max. en int datatype kan
> have
> > > som er 2,4 milliard.
> >
> > Har du forsøgt at regne det ud i f.eks. år før du rammer loftet?
>
> Jeg har desværre regnet. Problemet er at vi har mange forskellige
> hjemmesider som har mange hits som vi vil lagre i samme tabel helst.

Hvilket tal kom du frem til?
Og hvorfor finder du dette tal så lavt, at du blev nervøs?


> Jeg holder meget af et unikt ID til hver række og hvis største
> INT er 2,4 milliard så kan der vel max smides det antal rækker ind i hver
> tabel.

Det er korrekt.

Mvh
Jimmy

---

Rudi W. escribió / skrev

> N‘‘ pladsen kan man vel k›be sig til men det kan hurtigt
blive
> udsandsynligt meget data. Jeg holder meget af et unikt ID
til hver
> r‘kke og hvis st›rste INT er 2,4 milliard s† kan der vel
max smides
> det antal r‘kker ind i hver tabel.

Som Mads ganske rigtigt påpeger, løber du nok ind i
pladsproblemer før du når op på de 2,4 milliarder poster.
Hvis ikke, kan du jo blot tilføje endnu en numerisk
primærnøjle og vupti så har du (2,4*2,4)milliarder poster at
lege med og det lyder som en hel del

Under alle omstændigheder vil en database med så store
mængder data højst sandsynligt være for langsom til at være
praktisk, så jeg ville nok finde på noge med at lave
periodiske opsumeringer og brænde date ned på eventuelt en
DVD skive, hvis det er sådan at du forventer at kunne skulle
bruge specifike data ved lejlighed.
Med venlig hilsen
Lars Hoffmann

---

On Thu, 11 Dec 2003 22:49:07 +0100, "Rudi W." <rudi@balusta.dk> wrote:

>Nææ pladsen kan man vel købe sig til men det kan hurtigt blive udsandsynligt
>meget data. Jeg holder meget af et unikt ID til hver række og hvis største
>INT er 2,4 milliard så kan der vel max smides det antal rækker ind i hver
>tabel.

Lige præcis hvad det angår: Så må du jo bare bruge BIGINT i stedet for
tilfældigvis at bruge INT?

--
- Peter Brodersen

Ugens sprogtip: jamen (og ikke jammen)

---

Rudi W. wrote:
> Nææ pladsen kan man vel købe sig til men det kan hurtigt blive
> udsandsynligt meget data. Jeg holder meget af et unikt ID til hver
> række og hvis største INT er 2,4 milliard så kan der vel max smides
> det antal rækker ind i hver tabel.

Du kan lave feltet til en BIGINT?

http://www.mysql.com/doc/en/Numeric_types.html

--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

Kim Emax wrote:
> Du kan lave feltet til en BIGINT?

hmm... må hellere kigge hele tråden igennem inden jeg poster næste gang

--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

On Thu, 11 Dec 2003 22:17:03 +0100, "Rudi W." <rudi@balusta.dk> wrote:

>Vi skal lave et statistik system som skal kunne håndtere mange unikke
>sidevisninger og samtidigt give mulighed for statestik helt ned på time
>niveau.
>
>Det vi havde planlagt at gøre var at indsætte en række i en tabel for hver
>sidevisning der bliver udført.
>
>Problemet er så bare at har man 1000 sidevisninger pr dag i en måned
>(30.000) løber det meget hurtigt op til det max. en int datatype kan have
>som er 2,4 milliard.

Meget hurtigt og meget hurtigt .... 30.000 poster på en måned, det giver
80.000 måneder inden du når de 2,4 mia. - det er 6666 år - det vil jeg
nu ikke ligefrem kalde hurtigt

>Det vi logger er ip | host | page | browser | referer | date_time og et par
>andre få detajler.
>
>Vores test viser så at 3000 rækker fylder cirka en MB. dvs en måneds data
>vil fylde 10MB men har man omvendt så 10000 sidevisninger pr dag så begynder
>det at blive en stor DB og snart render man ind i sit max id i tabellen.

Ud fra hukommelsen så er maks-størrelsen for en tabel i mysql (på linux
i hvert fald) også maks-størrelsen for en fil i linux - dvs. 2 eller 4
gb - ca. Det er ca. 200 måneder får maksstørrelsen er nået, hvis det er
2 gb - det er 17 år.

>Nogen forslag til hvad man gør? laver arkiv tabeller? laver opsumerings
>tabeller? eller alternativ struktureringer.

Med det antal poster du snakker om - ikke noget.

(Jaja, jeg har ikke videre erfaring med store datamængder, men jeg kunne
bare ikke lade være med at regne en smule på de tal du opgav her


--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
http://www.gartneriet.dk
Kig også ind på http://hjoerringnyplanteskole.dk/

---

I dk.edb.database, skrev Mads Lie Jensen:
> Ud fra hukommelsen så er maks-størrelsen for en tabel i mysql (på linux
> i hvert fald) også maks-størrelsen for en fil i linux - dvs. 2 eller 4
> gb - ca. Det er ca. 200 måneder får maksstørrelsen er nået, hvis det er
> 2 gb - det er 17 år.

Denne begrænsning er ikke aktuel på nyere linux systemer.
(Læs: Installeret indenfor de sidste par år)

--
../Jesper Krogh, jesper@krogh.cc
Jabber ID: jesper@jabbernet.dk
Tøm din hjerne for Linuxviden på http://www.linuxwiki.dk

---

On Thu, 11 Dec 2003 22:17:03 +0100, Rudi W. wrote:

> Problemet er så bare at har man 1000 sidevisninger pr dag i en måned
> (30.000) løber det meget hurtigt op til det max. en int datatype kan have
> som er 2,4 milliard.

I MySQL kan du gøre en INT "unsigned", hvorved dens kapacitet fordobles.
Og I MySQL 4.0 findes BIGINT (som er ved at være de facto og snart
sikkert også formelt en standard-type), der kan have ustyrligt store
værdier.

Du insisterer på, at hvert request skal have eget ID. Det er nok i
virkeligheden fornuftigt nok, idet diverse HTTP-features såsom
pipelining gør, at der kan være uhyre lille tidsmæssig forskel på to
requests. Og på MySQL har man endda kun adgang til datatyper med
sekundopløsning, så vidt jeg kan se.

> Nogen forslag til hvad man gør? laver arkiv tabeller? laver opsumerings
> tabeller? eller alternativ struktureringer.

Jeg ville klø på. Og så begynde at indføre cron-jobs, der sletter
gamle rækker (efterfulgt af en OPTIMIZE-kørsel), hvis/når performance
bliver et problem. - Eller smider dem ud i en rå tekstfil som en slags
backup.

--
Greetings from Troels Arvin, Copenhagen, Denmark