meget stor mysql-tabel og rapportering

Start med at se på partition i dit bord, hvis du ikke allerede har gjort det:

Hvordan 'konsoliderer' du dine data? Måske er den metode, du bruger, ikke optimal. En god tilgang (giv mig besked, hvis det faktisk er det, du gør) er at oprette en tabel, der indeholder aggregerede data. Indstil det derefter på denne måde:

Først lægger du til side, hvordan dataene bliver dumpet ind i din hovedtabel...

Opret et job (cron eller hvad du måtte have ved hånden eller allerede konfigureret), der kører med et specificeret interval, i forhold til hvordan dataene indlæses i hovedtabellen (lad os kalde det MAIN , Bevæger sig fremad). Hvis din HOVED-tabel bliver indlæst hver time, så synkroniser den. En halv time? Det betyder ikke noget. Du kan tjekke hastigheden alligevel, eller hvis det er tæt på spidsbelastningstider, dine rapporter kører, så planlæg i nærheden af det
Indekser din tabel korrekt for konsoliderede data. Lad os kalde det AGG fremad.
Opret en lagret procedure, der indlæser data fra MAIN til AGG, som grundlæggende er en AGG LOAD FOR INTERVAL-? . Selvfølgelig er du den eneste her, der ved, hvordan eller hvornår dataene bliver indsat i MAIN, så du vil også være den, der ved, hvad aggregeringsintentionen er. Det er også muligt at blive ved med at køre den aggregerede lagrede procedure, hvis aggregeringsintentionen ikke er fuldført (f.eks. er det for en hel dag.. så det er en akkumulerende kørsel, indtil den er indstillet)
Brug STAGING tabeller. For mig er de de bedste .
Opret en lagret procedure, der gentjekker dataene, så eventuelle opdateringer eller yderligere indsættelse af poster kan afspejles i AGG-tabellen ved at køre denne procedure. Inkluder parametre for området, der skal opdateres. Hvis det er dagligt, så har du en DAILY AGG LOAD og DAILY AGG RELOAD procedure. Inkluder et AGG CHECK INTERVAL og AGG CHECK DAILY procedure, som vil hjælpe dig med at sove godt om natten. Åh og for ikke at nævne en AGG DATA HOLE CHECK eller en MISSING AGG DATA CHECK og anvende forretningsregler, der implementerer kontrol for en påkrævet minimumsmængde af data, som du kan hente fra den aggregerede tabel eller fra hovedtabellen eller iscenesættelsestabellen (helst)
Ændre selvfølgelig aldrig AGG bord. Genindlæs det altid kun.
Hvordan hjælper dette? Behøver du så ikke kun at få dine rapporter til at forespørge på AGG tabel, som er mindre og hurtigere (da sammenlægningen allerede er udført)? Måske kommer ydeevneproblemet ind med intervalbelastningen, men hvis du strukturerer din tabel, dens indekser og vedligeholdelse korrekt, burde det være det værd.
Hvor kommer partitionering ind? Arkivering. Når en vis tid er gået (diskuter, hvad der er acceptabelt med dit hold/chef/topmand), kan du arkivere de gamle data fra MAIN . Jeg oplevede at skulle opbevare 1 års data i produktionsdatabasen. Det føltes lidt som et træk, men fordi det var kundens anmodning, havde virksomheden intet andet valg end at give mig den diskplads, jeg havde brug for (gnider hænder), og dreng, jeg legede med det, indtil jeg fik noget anstændigt til at køre. Jeg må nævne, at min erfaring var med Microsoft SQL Server 2005, og lagrede procedurer og SSIS gjorde det sjovt.

Dette er alt, hvis du ikke allerede ved det, og for andre, der måske vil overveje muligheder. Jeg siger ikke, at du ikke vidste noget af ovenstående allerede; Jeg fortæller bare, hvad jeg har været i stand til før -- i betragtning af at jeg ikke havde flere oplysninger at arbejde med fra dit indlæg, bortset fra at du har en konsolideringsproces, som du har prøvet.