Kan MySQL klare en Table på 1.000 Gigabyte ?

jeg må desværre skuffe jer.....jeg ville ikke behandle så store mængderdata i MySQL....
Jeg kan anbefale POSTsgrSQL, da det også er brugt til store dataservere med mange query´s på samme tid(Yahoo og LYCOS bruger bla. POSTsgrSQL)

//themaster

Tja.. Ifølge MySQL's manual kan det kun (endda tvivlsomt) lade sig gøre på alpha-platforme:
http://www.mysql.com/documentation/mysql/bychapter/manual_Introduction.html#Table_size

Hvorvidt det rent faktisk kan fungere godt nok, og om det i det hele taget kan anbefales, kan jeg ikke svare på. :)

Hmm.. Læste lige lidt mere af manualen. Det behøver så ikke nødvendigvis at være alpha. Men alligevel..

Hvor stor en table ville i turde lade MySql klare før i valgte at skifte til noget andet?

og hvad ville i skifte til hvis det nu ikke må koste M$ priser

Jeg har ikke som sådan nogen erfaring med store databaser.. Jeg vil tro at det højeste jeg har haft, var et par hundrede MB, da jeg brugte den som logserver for en Counter-Strike server. Fungerede fint. En anelse langsommere end de små (xxx kb) tabeller jeg er vant til, men stadig acceptabelt.
Min "mentale" grænse for hvor meget data jeg vil lade MySQL håndtere, ligger nok på 1 GB. Måske 2. Hvad jeg så ellers vil bruge, er et godt spørgsmål. Måske POSTsgrSQL, som themaster nævnte. Aner det ikke :)

Umiddelbart ville jeg da forsøge mig med en mySQL ... det skulle da ik tage mange timer at sætte den op og sætte den til at køre data fra den ene server til den anden ...

- og så kunne det jo være op til en test. Linux folk sværger jo til at mySQL er så meget bedre end alt MS nogensinde kunne finde på at lave. Jeg ville da gerne høre resultatet af testen :)

MsSql er bedre til de fleste ting, men hvis jeg skulle købe licenser til vores 52 quad processor database servere sååå... $$$$ hehehe :-)

Vi vil faktisk helst bruge MySql og vi er igang med at teste, men vores test servere har ikke så store diske som prod serverne, og vi har ikke 10.000 brugere der ka sidde og sende rigtige requests (som de jo gør på prod)

Nej, men et stresstest-tool burde kunne sætte godt gang i det. Men har den med bare 1 bruger en responstid der nærmer sig 1 sekund så skal der ik meget matematik til at finde ud af den ik kan klare det :)

hvordan ved man at Yahoo og Lycos bruger POSTsgrSQL?

olmish >> har læst en artikel i et tysk tidskrift om store dataservere, der var der et eksempel på dataservere over 50 gb og de brugte LYCOS og Yahoo som eksempler

Skal vi lige slå fast at MS SQLServer og Oracle sagtens kan klare
1000 SELECT i sekundet.

Det er kun et spørgsmål om hvorvidt I vil betale for den rette
hardware.

Der er TPC-C resultater for de to på ca. 800000 transaktioner i minuttet
(det er over 10000 opdateringer i minuttet).

Men pris-skiltet lyder altså på ca. 5 millioner dollar.

For 1000 SELECT/sekund = 60000 SELECT/minut og 1 TB data skal I vel have
for ca. 50000 dollar (1-2 Xeon CPU, 2-4 GB RAM, RAID, 2 x 15 SCSI diske
72 GB U320 15000 RPM, software).

Eller noget i den stil. Jeg er ikke ekspert i DB konfiguration.

Jeg er sikker på at der er masser af leverandører der gerne vil give jer
et tilbud.

Oracle og SQLServer kan klare opgaven.

Nemt endda.

Samme gælder iøvrigt DB2 og Sybase.

Kan MySQL klare opgaven ?

Principielt ja.

MySQL kan klare så stor en tabel.

MySQL performer normalt glimrende, så på samme hardware vil jeg formode
at den performer lige så godt som de andre.

Men:
  - hvor nemt er det at tilføje nye diske ?
  - hvor nemt er det ar lave backup ?
  - hvor nemt er det at recovere fra en fejl ?

Jeg ville ikke vælge MySQL til den opgave.

Her er Arnes tommelfinger regel for database valg:

hvis du kan printe hele databasen på papir og sætte i et ringbind {
  vælg MS Access eller lignende
} ellers hvis data kan være på en disk {
  vælg MySQL eller lignende
} ellers hvis du kan tælle dine diske på to hænder {
  vælg MS SQLServer eller Sybase
} ellers {
  vælg Oracle eller DB2
}

Og det er lidt fjollet fordi ofte er der andre forhold end
lige præcis database størrelsen der er afgørende.

Måske skulle man overveje at arkivere nogen af de gamle indlæg ? :-) Det er vel ikke alle 155 gb der er i brug hele tiden.

Auch! 5 mill kr! hehe.

Arkiveringen er også den løsning vi har valgt, men det ændrer stadig ikke på at selve arkivet vil vokse til extrem størrelse.

Vi har lige testet en MsSql løsning med 2 DB servere 1 master og 1 slave, samt en 20GB gæstebogs tabel. Et opslag tog mellem 10 og 20 sek da der var 200 brugere online - what a bummer :-(

Gad vide om microsoft ikke vil lave en deal... De giver os en flok gratis MsSql licencer, og vi lover ikke at svine bill gates til :-)

Det afgørende ved den slags database løsninger er næsten altid diskene.

Hurtige diske og mange diske er essentielt. Du får aldrig god database
performance på en 240 GB IDE disk 7200 RPM.

Så er det naturligvis også vigtigt at databasen er designet rigtigt
(index) og at serveren er konfigureret rigtigt (cache).

Harddiske er ret hurtige, der er et RAID 5 med en flok rigtigt dyre 15K/RPM SCSI diske i.

Cache virker fint fordi den performer fint nok de forste 20 minutter, men så falder det også drastisk.

RAID 5 giver ikke optimal performnace. Det kræver RAID 0+1.

Det lyder lidt mærkeligt at den kører fint i 20 minutter og så
falder performance.

Det antyder en fejl/uhensigtsmæssighed i MySQL.

det ser nærmere ud som om cache er fyldt - der er kun 2GB ram i maskinerne.

Det tror jeg ikke er forklaringen.

Hvis det er database cache der er afgørende så vil man forvente
faldende svartider indtil cachen er fyldt op og derefter konstante
svartider. Ved konstant jævnt fordelt load.

Var I CPU bound eller IO bound ?

Hvor stor en connection pool brugte i ?

Uha, nu kommer jeg ud på dybt vand. Der skal jeg lige ha fat i udviklerne. Jeg er kun en stakkels inkompetent chef der ka lidt ASP :-)