[SQL] compressie methoden?

[Verwijderd]

Ik heb een aantal tabellen in een SQL database.
Deze hebben de volgende structuur
DateTime, Integer [, Integer [,Integer]]
of
DateTime, Float [, Float] etc...

etc. jullie begrijpen me wel, een datum met een aantal log values, int of float. De tabellen worden onder andere gebruikt voor logging van het aantal ingelogde gebruikers en de temperatuur

Nu begin ik langzamerhand aan de performance te merken dat de data na enkele maanden te zwaar/veel wordt.

Ik zoek nu een methode om deze data te compressen door de resolutie te verkleinen. Dit wil ik echter doen ZONDER de piekwaardes kwijt te raken. Het is ook de bedoeling dat dit een degelijke oplossing wordt die een aantal jaren kan blijven draaien.

de vraag hier dus:
Zijn er algoritmes / regels / methodes om je data zo te verkleinen? ik denk richting rrd en mrtg. Hoe doen zij het?
Alle tips/hulp zijn welkom.

[drm]

_{topictitel even veranderd.}
<!-- oude titel: '[datalogging] Methode om Time/Value data te archiveren' -->
Denk dat je zo meer kans maakt

[Verwijderd]

drm: Mooi zo, 't is ook niet echt een alledaagse vraag, wist er even geen raad mee

[cameodski]

Als het datamodel klopt en je hebt de juiste indexen dan zou er eigenlijk niet zomaar een performance probleem mogen ontstaan.
Eventueel zou je ook nog eens aan datawarehousing kunnen denken.

[Verwijderd]

cameodski:

Het probleem ligt niet zozeer bij het indexeren en bij het performance verlies, maar eerder bij het feit dat het nutteloos is om van 11 maanden geleden op een resolutie van 1 sample per 5 minuten te kunnen zeggen hoe warm en vochtig het was oid. Dit kan best met een resolutie van 1 sample per uur

[Verwijderd]

Ehm, een VIEW leggen op die tabel waarbij alleen de waarden van de laatste maand/week/dag oid instaan en daar op queriën?

[cameodski]

Verwijderd schreef op 04 november 2002 @ 15:33:
cameodski:

Het probleem ligt niet zozeer bij het indexeren en bij het performance verlies, maar eerder bij het feit dat het nutteloos is om van 11 maanden geleden op een resolutie van 1 sample per 5 minuten te kunnen zeggen hoe warm en vochtig het was oid. Dit kan best met een resolutie van 1 sample per uur

Volgens mij had je het toch echt over performance problemen. Dus vandaar.

Ik denk dat het in dit geval het beste is om een aparte tabel te hebben waarin 'oude' data staat. En waar dan minder samples in zitten opgeslagen.

[Crazy D]

Een aparte tabel vind ik nooit zo heel netjes, en maakt het query'en soms ook lastiger. Wat je zou kunnen doen is een background job maken die eens in de zoveel tijd de gegevens samenvoegd/totalizeerd/wat je maar wilt. Dan hou je bv de huidige + vorige maand in z'n geheel, en voor de oudere gegevens sla je enkel een gemiddelde of zo op (per uur), en de rest deleten.

Nutteloos:

Verwijderd schreef op 04 november 2002 @ 11:57:
De tabellen worden onder andere gebruikt voor logging van het aantal ingelogde gebruikers en de temperatuur

Ben je aan het bijhouden met welke temperatuur je site de meeste hits krijgt ?

[cameodski]

Crazy_D schreef op 04 november 2002 @ 16:51:
Een aparte tabel vind ik nooit zo heel netjes, en maakt het query'en soms ook lastiger. Wat je zou kunnen doen is een background job maken die eens in de zoveel tijd de gegevens samenvoegd/totalizeerd/wat je maar wilt. Dan hou je bv de huidige + vorige maand in z'n geheel, en voor de oudere gegevens sla je enkel een gemiddelde of zo op (per uur), en de rest deleten.

Of dat niet zo netjes is, is nog maar de vraag. Er is hier sprake van samples per uur of per 5 minuten. Waarschijnlijk worden er dus ook hele andere rapportages van gemaakt.

Nutteloos:

[...]

Ben je aan het bijhouden met welke temperatuur je site de meeste hits krijgt ?

Misschien gaat het hier wel over waarnemingen die gebruikers invoeren. Maar ik moet toegeven dat het aantal ingelogde gebruikers waarschijnlijk erg weinig met de temperatuur te maken heeft, dus is het wel vreemd dat dit in één tabel gezet wordt.

[Verwijderd]

Onduidelijkheden aan mijn kant --> de situatie:
we hebben 1 server ruimte, en 8 modem kasten. In alle ruimtes, alsmede in enkele loodsen hangen 1 of 2 temperatuur + vochtigheidsmeters. Daar lees ik de logbestanden van uit, en die "pleur" ik in de DB.

Het aantal ingelogde gebruikers gaat over een 7-tal citrix servers, en heeft (helaas voor de goede ideeen) niets met de temp te maken. Het wordt alleen door hetzelfde programma gerapporteerd (een ASP.NET webapp met gdi+ om te plotten)

ontopic:
Dat idee met een background job lijkt me wel wat. Ik heb daarvoor het idee om een DTS package te gebruiken (heb er al enkelen lopen die goed draaien).

Het probleem is alleen nog dat als ik het gemiddelde pak, dan mis ik de piekwaardes (die wel degelijk interessant zijn)

Misschien kan ik het beste één tabel maken met de gemiddelde waardes, en een andere tabel met "events" ofzo. Dan kan je toch in je rapportage nog terughalen dat er iets gebeurde (temp te hoog bij de serverruimte / citrix server uitgevallen, 100 users pissig)

[cameodski]

Verwijderd schreef op 05 november 2002 @ 08:43:
ontopic:
Dat idee met een background job lijkt me wel wat. Ik heb daarvoor het idee om een DTS package te gebruiken (heb er al enkelen lopen die goed draaien).

DTS package? Dat is meer bedoeld voor het importeren en exporteren van data en is ook wat anders dan een job. Een job kan ervoor zorgen dat een DTS package uitgevoerd wordt, maar kan ook een stored procedure aanroepen en dat is in deze situatie toch wel makkelijker denk ik.

Verwijderd schreef op 05 november 2002 @ 08:43:
Het probleem is alleen nog dat als ik het gemiddelde pak, dan mis ik de piekwaardes (die wel degelijk interessant zijn)

Dat was de reden dat ik over een aparte tabel begon. Je gaat voor de historie toch net iets andere dingen opslaan en waarschijnlijk ook wel net iets andere rapportages draaien, dus dan kan het handig zijn om het in aparte tabellen te zetten.

[Crazy D]

Verwijderd schreef op 05 november 2002 @ 08:43:
Het probleem is alleen nog dat als ik het gemiddelde pak, dan mis ik de piekwaardes (die wel degelijk interessant zijn)

Misschien kan ik het beste één tabel maken met de gemiddelde waardes, en een andere tabel met "events" ofzo. Dan kan je toch in je rapportage nog terughalen dat er iets gebeurde (temp te hoog bij de serverruimte / citrix server uitgevallen, 100 users pissig)

Hoe belangrijk is het dat ze kunnen zien dat 7 maanden geleden, om 10 over 3, toen er 100 gebruikers gelijktijdig waren ingelogt, de temperatuur x-graden hoger was dan "normaal" ? Ik kan me er sowieso weinig van voorstellen, ik denk dat je dat heel goed met de mensen die die info gebruiken, moet overleggen. Ik kan me voorstellen dat het niet zo heel relevant is om tot op de (paar) minuut(en) het temp verloop te kunnen zien, maar dat je wel pieken wilt weten. Dan zou je een min, max, en avg waarde kunnen opslaan.

Als ze eigenlijk wel ook van maanden geleden een gedetailleerd verloop moeten hebben, misschien is dan de detailgegevens overzetten naar een aparte tabel zo gek toch nog niet, aangezien graven in het verleden dan toch een aparte rapportage is (die met een view ook weer prima samen te voegen is met de live gegevens). (maar dan vraag ik me weer af hoeveel trager het is als je de gegevens wel in de huidige tabel laat staan).

[Verwijderd]

Crazy_D:

Het aantal ingelogde gebruikers gaat over een 7-tal citrix servers, en heeft (helaas voor de goede ideeen) niets met de temp te maken. Het wordt alleen door hetzelfde programma gerapporteerd (een ASP.NET webapp met gdi+ om te plotten)

Wat wel belangrijk is, is de maxima terughalen. Onder andere voor verantwoording van nieuwe investeringen

[Verwijderd]

cameodski schreef op 05 november 2002 @ 10:11:
[...]

DTS package? Dat is meer bedoeld voor het importeren en exporteren van data en is ook wat anders dan een job. Een job kan ervoor zorgen dat een DTS package uitgevoerd wordt, maar kan ook een stored procedure aanroepen en dat is in deze situatie toch wel makkelijker denk ik.

DTS is misschien een beetje onhandig. Ik had in gedachte dat ik een dts zou gebruiken voor de "transformatie" van de originele tabel naar de gecomprimeerde (en de tabel met de piekwaardes)

cameodski schreef op 05 november 2002 @ 10:11:
[...]

Dat was de reden dat ik over een aparte tabel begon. Je gaat voor de historie toch net iets andere dingen opslaan en waarschijnlijk ook wel net iets andere rapportages draaien, dus dan kan het handig zijn om het in aparte tabellen te zetten.

Inderdaad. Ik ga dan ook die kant op.
Het idee (for future reference, niets is irritanter dan iemand die zijn topic sluit met "opgelost."):
van elke 12 waardes van de tabel neem ik het gemiddelde
als één waarde in deze set een bepaalde extreme heeft (een steiging of daling van meer dan 45 graden ten opzichte van de vorige 3) heeft, dan komt hij in aanmerking als event. Een event kan voor de rapportage handig zijn, zeker als die verklaard kunnen worden, wat in samenwerking met de servicedesk wordt geregistreerd. Denk hierbij aan het uitvallen van een server (voor de totale gebruikerstelling) of het weigeren van de airco bij een steiging van de temperatuur.

Tevens sla ik in de events tabel de piek en dalwaardes op.

wederom, alle suggesties / verbeteringen van dit idee zijn welkom _{(mits topic gelezen)}