Avatar billede webcreator Nybegynder
17. maj 2005 - 09:55 Der er 20 kommentarer og
2 løsninger

500 Millioner post - kan MySQL klare det ?

Hej Eksperter.

Jeg har en tabel i min database, som hver måned vil blive belastet med 35-40 millioner poster. Om året bliver det ungefair 500 millioner.

Vil det blive en meget langsommelig proces, at finde 40 millioner poster ud af de 500 millioner, gruppere dem på DateTime feltet (på minuttet), og returnere de ca. 45000 poster som kommer ud af dette?

Hvordan vil belastningen ligeledes se ud, hvis man ikke gruppere på minuttet i DateTime feltet, og returnerer alle 40 millioner poster?

Endelig vil jeg gerne vide, om jeg kan forvente, at databasen kan indeholde så store datamængder - hvis det antages, at alle felterne fyldes helt op (her tænker jeg specielt på Text-feltet).

Hvordan vil plads-forbruget ligeledes se ud, hvis vi dropper Text-feltet?

Jeg ved at det må være svære spørgsmål at give nøjagtige svar på. Jeg søger imidlertid også kun nogle grovestimater - dog så præcise som muligt.

Min tabel :

CREATE TABLE MNTRresultater
(
  loebenumber    int        UNSIGNED    NOT NULL,
  tid        int        UNSIGNED    NOT NULL,
  tidspunkt    DateTime            NOT NULL,
  artikel    text                NOT NULL,

  PRIMARY KEY (loebenummer, tidspunkt),
  FOREIGN KEY (loebenummer) REFERENCES MNTRloebenumre (loebenummer)
    ON DELETE RESTRICT ON UPDATE CASCADE
) TYPE = InnoDB;
Avatar billede jpvj Nybegynder
17. maj 2005 - 10:14 #1
Hvis du skal finde posterne, vil jeg sørge for at have et index på det/de felter du søger på (din WHERE clause).

Hvis du kun søger på tidspunkt, skal du altså oprette et index på dette felt.

Jeg vil ikke udtale mig om performance/størrelser, da jeg ikke har erfaring med mySQL i de størrelser.

Jeg ved dog at mySQL anvendes på meget store installationer.
Avatar billede webcreator Nybegynder
18. maj 2005 - 11:29 #2
Hej Jpvj.
Mange tak for din besvarelse. Jeg kigger lige på muligheden for at lave INDEX på mit DateTime felt.

Jeg hører gerne fra nogen, der kender til evt. performance issues ved disse datamængder.
Avatar billede jpvj Nybegynder
18. maj 2005 - 11:55 #3
Principielt set, er der ingen problemer i dette.

Et DBMS system kører (meget simplificeret) en binær søgning, dvs.

log2(500.000.000) = 29 binære søgninger.

I praksis tager DBMS systemet hensyn til blokstørrelsen på harddisken, så ovenstående fungerer lidt anderledes (det vil blive noget i stil med

logx(500.000.000) = antal søgninger på x elementer.

Det du nok skal være mere opmærksom på, er antallet af IO's til dit disksystem. Sørg for at køre en server med et RAID 1+0 (se evt. her http://www.ofb.net/~jheiss/raid10/) for optimal performance og sikkerhed.

Du kan i øvrigt kontakte mySQL AB i Sverige - de har en konsulent afdeling, der vil kunne give dig meget kvalificeret hjælp til at designe din løsning. Se kontakt informtioner her: http://www.mysql.com/

Held og lykke med projetet.
Avatar billede arne_v Ekspert
18. maj 2005 - 22:10 #4
Prøv og klik på nogle af linksene her:
  http://www.mysql.com/customers/
Avatar billede arne_v Ekspert
18. maj 2005 - 22:14 #5
F.eks. http://mysqluc.com/presentations/mysql05/benzinger_michael.pdf

ialt 3.5 TB data

en tabel på 85 GB med 705 millioner rækker
Avatar billede webcreator Nybegynder
19. maj 2005 - 11:03 #6
Hold da op - det var anseelige mængder data. Synes ellers jeg har læst, at MySQL kun supporter datamængder på op til 4 GB. Men det kan der så ikke være hold i.
Avatar billede webcreator Nybegynder
19. maj 2005 - 11:04 #7
Tak i øvrigt for udregningerne. Jeg tror dog at du har fået et nul for meget med på lommeregneren. Det bliver kun ca. 17 :)
Avatar billede arne_v Ekspert
19. maj 2005 - 11:16 #8
4 GB er ikke en MySQL limit men en limit som fil systemet kan give, hvis du vil
have en tabel >4GB så skal den ligge på et fil system som supporterer filer
>4 GB
Avatar billede imago-dei Nybegynder
19. maj 2005 - 11:21 #9
Er begrænsningen på 4 GB ikke kun i at du ikke kan have en enkelt f.eks. LONGBLOB større end 4 GB?

Tekst felter i mySql fylder op til 65 KB. Så hvis du har 500 mio. af slagsen og alle er fyldt op fylder det ret meget. (ca. 32,5 TB)
Avatar billede webcreator Nybegynder
19. maj 2005 - 11:25 #10
Hm, sådan en index-fætter - skal det blot laves første gang jeg skaber min tabel, eller fx en gang om måneden? Og hvis jeg har mit DateTime felt, er koden så blot :

CREATE INDEX indexer ON myTable (tidspunkt);
Avatar billede webcreator Nybegynder
19. maj 2005 - 11:26 #11
.. og skal jeg i øvrigt ændre mine alm. SQL-queries når jeg har lavet et index? Eller finder databasen selv ud af det hele ?
Avatar billede arne_v Ekspert
19. maj 2005 - 11:29 #12
bare en gang når du har create tabelenne

så vedligeholder mysql indexet

ingen ændringer til queries
Avatar billede webcreator Nybegynder
19. maj 2005 - 11:36 #13
- og kan det i øvrigt passe, at tidskompleksiteten for søgning når, en index'er er oprettet, er O(log n) ?
Avatar billede webcreator Nybegynder
19. maj 2005 - 11:38 #14
Arne > Ok, det lyder godt. Var mit Create statement i øvigt korrekt? Jeg fandt nogle informationer om at oprette et index på varchar, text og lignende felter men ikke om DateTime
Avatar billede arne_v Ekspert
19. maj 2005 - 11:41 #15
ja

create index er ligeglad med felttypen (forudsat at det er en felt type som kan
bruges til index)
Avatar billede webcreator Nybegynder
19. maj 2005 - 11:47 #16
Ok, perfekt :)
Har du styr på tidskompleksiteter? Jeg har fundet to muligheder på nettet :
- T(n) = O(n*log2n)
- T(n) = O(log n).
Avatar billede webcreator Nybegynder
19. maj 2005 - 12:03 #17
Arne > Du må forresten også gerne smide et svar ved lejlighed :)
Avatar billede arne_v Ekspert
19. maj 2005 - 12:06 #18
selve søgningen bør være O(log(n))
Avatar billede arne_v Ekspert
19. maj 2005 - 12:06 #19
svar
Avatar billede webcreator Nybegynder
19. maj 2005 - 12:11 #20
Ok. Mange tak for al den finde hjælp. Jeg afsætter lige lidt flere points og deler imellem jer :)
Avatar billede arne_v Ekspert
19. maj 2005 - 12:38 #21
med hensyn til table size så læs
  http://dev.mysql.com/doc/mysql/en/table-size.html
Avatar billede webcreator Nybegynder
19. maj 2005 - 12:42 #22
Herligt - mere læsestof. Mange tak :)
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester