[SweLogan]

Hej, jag har ett problem som jag inte vet redigt hur jag ska lösa än.

Problemet är
Jag har ca 200 000 000 poster i en tabell. Detta är då extremfallet!
Att hämta alla poster typ (SELECT * from Logg) det går redigt fort.
Problemet jag har är att det tar väldigt långtid att köra WHERE & ORDER BY samt GROUP BY i frågan.

Tabellen ser ut på följande:

ID | Grupp | Timestamp | Value

Frågan kan vara:
Grupp, TimeStamp, Count(Value) som Antal.
Hämta där Grupp = 1
Där Timestamp är mellan två datum
Grupera Timestamp på timmar
Sotera på timmar

Resultatet blir då:

Grupp | Timestamp | Antal
1 | 2011-01-01 00:00:00 | 500
1 | 2011-01-01 01:00:00 | 550
1 | 2011-01-01 02:00:00 | 499
1 | 2011-01-01 03:00:00 | 350
Fast för ett helt år.

Hur ska jag göra för att snabba upp sökningarna?

Hänger allt bara på prestandan på datorn?
Ifall det gör detta, vad för typ av prestanda krävs för att kunna gå igen 20000k poster på en tid som skulle vara rimligt för att visa statistiken på en hemsida?

[Silodon]

Vad har du för index i din tabell? Har du inga så kan det säkert snabba upp.

[coredev]

Du kan göra ett "jobb" som varje natt selekterar och aggregerar data till en annan tabell. Sedan blir det snabbt och lätta att hämta datat därifrån. Du kanske missar det som har hänt sedan senaste aggregeringen, men det är förhoppningsvis en felmarginal som din applikation kan leva med.

[Clarence]

Det finns ett bra antal sätt att lösa problemet.

T ex:
- Som redan nämnts att skapa ett bakgrundsjobb som redan grupperar på de vanliga filtrena som läggs på. Det man inte aggregerat kan man istället köra enligt nästa metod.
- Skapa en extra sample-data som tar ut en liten del av din data med bästa möjliga representation av din riktiga data.
- Lägga på någon extern indexerings-mjukvara. Av ditt exempel verkar det t ex som om SphinxSearch skulle klara av allt med gruppering och filtrering. Nu för tiden har de även liveuppdatering så det är mycket mindre arbete att få till en realtidslösning. Det finns även som tabellmotor till MySQL så du t o m slipper byta interface.
- Köra mapreduce eller liknande för att dela upp jobb över flera maskiner
- Lägga index över relevanta kolumner eller kanske t o m täckande index
- Se till att ha tillräckligt med ram och använda innodb och få en cpu-bunden (jämför med io-bunden som de flesta workloads blir vid den nivån)