Håndtering af store mængder data

Tags:    mysql php

Hej udviklere,

Jeg sidder i øjeblikket og arbejder på et projekt, hvor jeg kommer til at skulle håndtere relativt store mængder data. Den (meget) grove forklaring er som følger:

Jeg har en kunde som skal bruge mit system (f.eks. en frisør). Denne frisør skal have mulighed for at tilføje flere personer til sin klinik. Hver person har en kalender i systemet hvor tidsbestillinger kan administreres. Hver enkel person i frisøren skal kunne angive hvornår denne person er på arbejde/hvornår denne person har mulighed for at modtage tider.

Jeg har overvejet 3 scenarier:

1. personens mulige tider ligger som åbne tidsbestillinger i kalenderen. Disse ændrer blot et flag når de bookes og tilføjes info i den tabel.
2. personen har en seperat tabel til angivelse af mulige arbejdstider for denne person
3. personen angive hvilke tidspunkter der som udgangspunkt er tilgængelige (f.eks. en normal arbejdsuge) og har derefter en tabel til at kunne angive hvilke dage der eventuelt er ændringer på


Jeg ved dog ikke hvilken af de 3 er den bedste løsning. Hvis jeg nu i stedet for én frisør har 5 frisører og de hver har 5 personer så vil det pludseligt være 25 personer der skal administreres tider for, og jeg vil jo nødig have at det skal gå ud over søgetiden i databasen på grund af størrelsen på tabeller.

Hvordan administrerer jeg data i et sådant system bedst muligt? I samme forbindelse - hvad vil være det klogeste med hensyn til hver enkelt persons kalender? En kalender-tabel med de bestilte tider vil sandsynligvis hurtigt fyldes op hvis hver af de 25 personer f.eks. har 200 bestillinger på en uge. Det giver ~200.000 rækker i en tabel på et år. Må ærligt indrømme at jeg ikke ved hvor store tabeller man snakker før det går ud over søgetiden eller hvordan jeg måske med MySQL kan optimere søgningen for ikke at ødelægge søgetiden?

Håber I forstår mine spørgsmål.

På forhånd mange tak for hjælpen :-)



8 svar postet i denne tråd vises herunder
4 indlæg har modtaget i alt 35 karma
Sorter efter stemmer Sorter efter dato
Selv med 1.000.000 rækker er MySQL ikke slem. Dog er InnoDB en nødvendighed, og så skal indeksering være sat på. F.eks. hvis dit system skal søge efter navn i en tabel med navne, så skal tabellen have sat indeks på kolonnen med navn.

For dit tidsbestilling, vil du meget sjældent skulle håndtere et års data. Så du kan altid minimere din datamængde ved kun at søge i de data der ligger inden for en tidsperiode - men husk, indeksering. :)



Antallet af rækker synes jeg ikke afskrækker. Korrekte indexes på dine tabeller bør gøre søgningen meget hurtig, selv med 500.000 rækker (hvis det også er kodet ordentligt).




Jeg kan heller ikke se noget galt i det, har også arbejdet med meget størrer data i en tabel. Hvis du er konsekvent med dine selects, så er det ikke noget problem. Så ikke noget med SELECT * FROM ordre. Har arbejdet med data der var noget størrer, uden de store problemer.

InnoDB er den type du sætter database / tabellen til, når du opretter den.



Som Dan nævner, er InnoDB en type du sætter databasen til. Men mere korrekt er det den engine som MySQL skal benytte til at behandle data. Der er typisk mulighed for InnoDB eller MyISAM.

http://en.wikipedia.org/wiki/InnoDB

http://en.wikipedia.org/wiki/MyISAM



Michael: kan du elaborere lidt på hvad InnoDB er og hvorfor det er en nødvendighed?

Nu skriver du også, at jeg jo ikke skal bruge et helt års data - det er korrekt. Vil sjældent skulle hente mere end én uge ad gangen. Men hvis jeg nu søger i databasen mellem to datoer (lad os sige 2 uger) hvor der findes 3-4.000 rækker. Samtidig begrænser jeg til én person så der måske er maks. 500 tilbage. Vil denne søgning således være lige hurtig uanset den samlede mængde data i databaesn, hvis indeksering vel at mærke er slået til?

Vil det samtidig i øvrigt været smartest af mig at anvende MySQL dato-format eller er det bedre med unix timestamp i en kolonne?



Jeg kan heller ikke se noget galt i det, har også arbejdet med meget størrer data i en tabel. Hvis du er konsekvent med dine selects, så er det ikke noget problem. Så ikke noget med SELECT * FROM ordre. Har arbejdet med data der var noget størrer, uden de store problemer.

InnoDB er den type du sætter database / tabellen til, når du opretter den.


Når du skriver mere konsekvent, mener du så blot f.eks. SELECT id,title FROM i stedet for at hive alt ud, eller?



Jeg kan heller ikke se noget galt i det, har også arbejdet med meget størrer data i en tabel. Hvis du er konsekvent med dine selects, så er det ikke noget problem. Så ikke noget med SELECT * FROM ordre. Har arbejdet med data der var noget størrer, uden de store problemer.

InnoDB er den type du sætter database / tabellen til, når du opretter den.


Når du skriver mere konsekvent, mener du så blot f.eks. SELECT id,title FROM i stedet for at hive alt ud, eller?

Ja det er det jeg mener. Du kan desuden gøre det, at du søger i et mindre udsnit af databasen. F.eks. via segmentering på datoer (som sandsynligvis også er den kolonne det er bedst, at indexere på).



Jeg kan heller ikke se noget galt i det, har også arbejdet med meget størrer data i en tabel. Hvis du er konsekvent med dine selects, så er det ikke noget problem. Så ikke noget med SELECT * FROM ordre. Har arbejdet med data der var noget størrer, uden de store problemer.

InnoDB er den type du sætter database / tabellen til, når du opretter den.


Når du skriver mere konsekvent, mener du så blot f.eks. SELECT id,title FROM i stedet for at hive alt ud, eller?

Ja det er det jeg mener. Du kan desuden gøre det, at du søger i et mindre udsnit af databasen. F.eks. via segmentering på datoer (som sandsynligvis også er den kolonne det er bedst, at indexere på).


Super, det vil jeg huske på. Forstår ikke helt hvad du mener med segmentering af datoer? Skal det i øvrigt samtidig forstås sådan, at en kolonne af typen dato er bedre at bruge end f.eks. have en integer med et unix timestamp?



t