zeer grote mysql-tabel en rapportage

Begin door te kijken in partition uw tafel aan als u dat nog niet heeft gedaan:

Hoe 'consolideert' u uw gegevens? Misschien is de methode die je gebruikt niet optimaal. Een goede benadering (laat me weten of dit is wat je doet) is om een tabel te maken die geaggregeerde gegevens bevat. Stel het dan op deze manier in:

Eerst opzij zetten hoe de gegevens in uw hoofdtabel worden gedumpt...

Maak een taak (cron of wat je ook maar handig of al geconfigureerd hebt) die met een gespecificeerd interval wordt uitgevoerd, in verhouding tot hoe de gegevens in de hoofdtabel worden geladen (laten we het MAIN noemen) , vooruit gaan). Als uw MAIN-tabel elk uur wordt geladen, synchroniseert u deze. Half uur? Maakt niet uit. U kunt de snelheid toch controleren, of als het bijna daluren is dat uw rapporten worden uitgevoerd, dan plannen in de buurt van die tijd
Indexeer uw tabel op de juiste manier voor geconsolideerde gegevens. Laten we het AGG noemen vooruitgaan.
Maak een opgeslagen procedure die gegevens laadt van MAIN naar AGG, wat in feite een AGG LOAD FOR INTERVAL-? is . Natuurlijk bent u de enige hier die weet hoe of wanneer de gegevens in MAIN worden ingevoegd, dus u zult ook degene zijn die weet wat de aggregatie-intentie is. Het is ook mogelijk om de geaggregeerde opgeslagen procedure te blijven uitvoeren als de aggregatie-intentie niet is voltooid (zeg dat het voor een hele dag is.. dus het is een cumulatieve run totdat dat is ingesteld)
Gebruik STAGING tafels. Voor mij zijn ze de beste .
Maak een opgeslagen procedure die de gegevens opnieuw controleert, zodat eventuele updates of aanvullende invoegingen van records in de AGG-tabel kunnen worden weergegeven door deze procedure uit te voeren. Neem parameters op voor het bereik dat moet worden bijgewerkt. Als het dagelijks is, heb je een DAILY AGG LOAD en DAILY AGG RELOAD procedure. Voeg een AGG CHECK INTERVAL toe en AGG CHECK DAILY procedure die u zal helpen om 's nachts goed te slapen. Oh en niet te vergeten een AGG DATA HOLE CHECK of een MISSING AGG DATA CHECK en bedrijfsregels toepassen die het controleren van een vereiste minimale hoeveelheid gegevens implementeren die u uit de geaggregeerde tabel of uit de hoofdtabel of verzameltabel kunt halen (bij voorkeur)
Wijzig natuurlijk nooit de AGG tafel. Laad het altijd alleen opnieuw.
Hoe helpt dit? Zou u dan niet alleen uw rapporten de AGG . hoeven te laten doorzoeken tabel, die kleiner en sneller is (omdat de aggregatie al is gedaan)? Misschien komt het prestatieprobleem met het laden van de interval, maar als je je tabel, de indexen en het onderhoud goed structureert, zou het de moeite waard moeten zijn.
Waar komt partitionering om de hoek kijken? Archiveren. Zodra een bepaalde tijd is verstreken (bespreek wat acceptabel is met je team/baas/topman) kun je de oude gegevens archiveren vanuit MAIN . Ik heb ervaren dat ik gegevens van 1 jaar in de productiedatabase moet bewaren. Dat voelde een beetje als een belemmering, maar omdat het een verzoek van de klant was, had het bedrijf geen andere keuze dan me de schijfruimte te geven die ik nodig had (wrijft in mijn handen) en jongen, ik speelde ermee totdat ik iets fatsoenlijks kreeg. Ik moet zeggen dat mijn ervaring was met Microsoft SQL Server 2005, en opgeslagen procedures en SSIS maakten het leuk.

Dit is alles als je het nog niet weet, en voor anderen die misschien opties willen overwegen. Ik zeg niet dat je niets van bovenstaande al wist; Ik zeg alleen wat ik eerder heb kunnen doen -- gezien het feit dat ik niet meer informatie had om mee te werken uit je post, behalve dat je een consolidatieproces hebt dat je hebt geprobeerd..