Snelste windsnelheid laatste 6 uur.

[ZpAz]

Ik zit hier met het volgende probleem:

- We krijgen elke seconde 8000 metingen (1 per weerstation) binnen met tijd, stationnummer en windsnelheid. Dit slaan we zelf op in een database (mongodb). Dit is na 6 uur 172 800 000 entries in de database.

Nu willen we de snelste meting per station ophalen van de afgelopen 6 uur. Als het systeem een aantal uur draait dan is een sort / limit 1 niet meer te doen. Dit wordt gewoon te traag.

Nu dacht ik het geniale idee te hebben om wanneer de data binnen komt het per station te vergelijken met de vorige snelste waarde van dat station, als dat zo is, dan vervang je die en stop je de nieuwe snelste waarde in een losse collectie. Hierdoor bevat deze collectie (top_windspeeds) altijd de snelste 8000 waarde's.

Dit werkt, zolang de factor tijd niet meegerekend hoeft te worden. Een voorbeeld:

De eerste meting die ik binnen krijg voor station 3 is 10. Dit is nu de snelste, immers is het de eerste. Deze stop ik in een losse collectie. De volgende meting voor dit station is 11. Deze is sneller dan 10, 10 wordt verwijderd, 11 wordt er voor in de plaats gezet.

Nu komt het volgende uur elke keer een meting van rond de 9. Deze zijn allemaal langzamer dan 11 dus worden genegeerd en weggegooid. Nu komt het tweede uur een meting van 10.5 deze wordt ook genegeerd. Daarna komen de volgende 4 uur weer alleen metingen van rond de 9.

De waarde 11 welke in de DB staat is nu 6 uur oud. En is dus niet meer geldig (immers willen we de hoogste windsnelheid van de afgelopen 6 uur). De volgende snelste meting is die van 10.5 van 4 uur geleden, maar die is al vergeleken en weggegooid. Dus daar heb ik niets meer aan. Nieuwe metingen zijn bijvoorbeeld 8 en omdat de andere verlopen is wordt deze in de DB gestopt, terwijl die van 10.5 toch sneller was en binnen de tijd is.

---

Mijn vraag in het kort eigenlijk. Is het mogelijk om de snelste meting van de afgelopen 6 uur op te halen zonder alle metingen op te slaan?

Het idee wat ik had werkt wel als het om de snelste meting aller tijden gaat, maar dat is hier niet het geval.

[DennusB]

Je kunt toch bij die snelste meting ook gewoon opslaan wanneer die in de tabel werd gezet? Is dat >6 uur geleden dan doe je een delete op het record en stop je er weer een nieuwe in!

[Mike2k]

Hoe is je DB layout?

Kan je niet een key zetten op de windsnelheid?

[Verwijderd]

DennusB schreef op woensdag 16 november 2011 @ 11:48:
Je kunt toch bij die snelste meting ook gewoon opslaan wanneer die in de tabel werd gezet? Is dat >6 uur geleden dan doe je een delete op het record en stop je er weer een nieuwe in!

Volgens mij heeft TS te maken met een sliding window.

[ZpAz]

DennusB schreef op woensdag 16 november 2011 @ 11:48:
Je kunt toch bij die snelste meting ook gewoon opslaan wanneer die in de tabel werd gezet? Is dat >6 uur geleden dan doe je een delete op het record en stop je er weer een nieuwe in!

Klopt, dat dacht ik eerst ook. Maar wat als in uur 4 de twee na snelste binnenkomt, welke je matcht en verwijderd. Omdat het niet de snelste is, de komende 4 uur is alles langzamer.. die van 6 uur geleden wordt verwijderd. Dan is niet je huidige windsnelheid de snelste, maar die van 4 uur geleden. Welke je niet meer hebt.

[DennusB]

Verwijderd schreef op woensdag 16 november 2011 @ 11:48:
[...]

Volgens mij heeft TS te maken met een sliding window.

Ja sorry, dat zie ik nu ook inderdaad. Dan zou ik gewoon wel alle waardes opslaan, met een max levensduur per record van 6 uur. Is ie ouder dan 6 uur? Dan gooit ie het record weg. Zo blijft je tabel 'schoon' en snel!

[ZpAz]

Mike2k schreef op woensdag 16 november 2011 @ 11:48:
Hoe is je DB layout?

Kan je niet een key zetten op de windsnelheid?

We hebben een STN, WDSP (windspeed) en TIME (timestamp). Op Time zit een index. (ensureIndex).

[ZpAz]

DennusB schreef op woensdag 16 november 2011 @ 11:50:
[...]


Ja sorry, dat zie ik nu ook inderdaad. Dan zou ik gewoon wel alle waardes opslaan, met een max levensduur per record van 6 uur. Is ie ouder dan 6 uur? Dan gooit ie het record weg. Zo blijft je tabel 'schoon' en snel!

Als ik alle records van de laatste 6 uur opsla voor elk station dan zitten we op 172 miljoen rijen. Dat is niet meer bepaald snel als je de 50 snelste windsnelheden wilt opvragen.

[Verwijderd]

ZpAz schreef op woensdag 16 november 2011 @ 11:52:
[...]


Als ik alle records van de laatste 6 uur opsla voor elk station dan zitten we op 172 miljoen rijen. Dat is niet meer bepaald snel als je de 50 snelste windsnelheden wilt opvragen.

Dat zou wel mee moeten vallen hoor. Wat is "niet bepaald snel"?

[Mike2k]

Komen de metingen eigenlijk met een vaste interval of random ?

[DennusB]

ZpAz schreef op woensdag 16 november 2011 @ 11:52:
[...]


Als ik alle records van de laatste 6 uur opsla voor elk station dan zitten we op 172 miljoen rijen. Dat is niet meer bepaald snel als je de 50 snelste windsnelheden wilt opvragen.

Nah een beetje flinke database-server(s) met goede configuratie en goed tabel design moet dat makkelijk aankunnen!

[ZpAz]

We hebben 25 seconden de tijd. Maar dat redden we niet.

[ZpAz]

DennusB schreef op woensdag 16 november 2011 @ 11:53:
[...]


Nah een beetje flinke database-server(s) met goede configuratie en goed tabel design moet dat makkelijk aankunnen!

En wat is dan een goed tabel design. We hebben het hier over mongo. Daar heb je geen relaties enzo. Daarnaast is het ook nog eens één tabel, daaraan kan je weinig designen.

We hebben 25 seconden de tijd. Maar dat redden we niet.
edit: Het is een school opdracht, we hebben niet de resources om er een cluster aan servers heen te gooien.

Na een paar uurtjes draaien zitten we al tegen de 30GB aan data.

Komen de metingen eigenlijk met een vaste interval of random ?

Elke seconde per station.

[ Voor 13% gewijzigd door ZpAz op 16-11-2011 11:58 ]

[Verwijderd]

ZpAz schreef op woensdag 16 november 2011 @ 11:53:
We hebben 25 seconden de tijd. Maar dat redden we niet.

Dan zou ik optimaliseren.

Nog even terug naar het sliding window. Je zegt dat je de hoogste waarde in de afgelopen 6 uur wilt, maar is dat per uur of wat? Want dan kun je toch per (klok)uur de hoogste waarde opslaan en later steeds Min([x-5..x]) terugkijken?

[ZpAz]

Verwijderd schreef op woensdag 16 november 2011 @ 11:55:
[...]

Dan zou ik optimaliseren.

Dankje, zover was ik. Maar hoe

Nog even terug naar het sliding window. Je zegt dat je de hoogste waarde in de afgelopen 6 uur wilt, maar is dat per uur of wat? Want dan kun je toch per (klok)uur de hoogste waarde opslaan en later steeds Min([x-5..x]) terugkijken?

De hoogste windsnelheid binnen de afgelopen 6 uur.

[Mike2k]

ja...maar per das geen antwoord op de vraag van negertjezoen en mij...

wat is de interval van metingen? is die vast of niet ?

[nl03228]

Dit al geprobeerd:

http://www.mongodb.org/display/DOCS/Optimization

[ZpAz]

Mike2k schreef op woensdag 16 november 2011 @ 11:57:
ja...maar per das geen antwoord op de vraag van negertjezoen en mij...

wat is de interval van metingen? is die vast of niet ?

Sorry dan snap ik je vraag niet. Is je vraag: "komen alle metingen op zelfde tijdspannes ertussen binnen" dan ja. Elke seconde komt er een meting voor elke 8000 stations binnen. Tussen elke meting per station zit dus één seconde.

[ Voor 5% gewijzigd door ZpAz op 16-11-2011 12:01 ]

[mux]

Ik zou toch het probleem dan een beetje in je server zoeken. Zitten je samples in werkgeheugen of in een database on disk? Een sort uitvoeren op data in geheugen moet met honderden megasamples per seconde gaan, en sort is orde N log n. Je kunt kijken naar een ander sort-algoritme gezien je data een duidelijke structuur heeft (naar ik aanneem), of je data hiërarchisch sorteren.

[Verwijderd]

Omdat het voor een schoolproject gaat:

Snelste windsnelheid is volgens mij een pleonasme, juister zou zijn: 'Hoogste windsnelheid'

Ik zeur nogmaal niet over taal, maar ik wil je deze kleine tip niet onthouden aangezien je misschien wel een lagere score zou kunnen krijgen.

[ZpAz]

mux schreef op woensdag 16 november 2011 @ 12:02:
Ik zou toch het probleem dan een beetje in je server zoeken. Zitten je samples in werkgeheugen of in een database on disk? Een sort uitvoeren op data in geheugen moet met honderden megasamples per seconde gaan, en sort is orde N log n. Je kunt kijken naar een ander sort-algoritme gezien je data een duidelijke structuur heeft (naar ik aanneem), of je data hiërarchisch sorteren.

Het staat op een HDD. In het geheugen past niet. We hebben maar 4GB ram.

nl03228 schreef op woensdag 16 november 2011 @ 11:57:
Dit al geprobeerd:

http://www.mongodb.org/display/DOCS/Optimization

Al deze drie punten worden uitgevoerd.

Verwijderd schreef op woensdag 16 november 2011 @ 12:04:
Omdat het voor een schoolproject gaat:

Snelste windsnelheid is volgens mij een pleonasme, juister zou zijn: 'Hoogste windsnelheid'

Ik zeur nogmaal niet over taal, maar ik wil je deze kleine tip niet onthouden aangezien je misschien wel een lagere score zou kunnen krijgen.

Thanks

[ Voor 20% gewijzigd door ZpAz op 16-11-2011 12:06 ]

[mux]

ZpAz schreef op woensdag 16 november 2011 @ 12:05:
[...]


Het staat op een HDD. In het geheugen past niet. We hebben maar 4GB ram.

Dan laad je telkens een slice van je DB in geheugen, sorteert en gaat door naar de volgende slice. Daarna sorteer je de uitkomsten van iedere slice. Dat is een hiërarchische sort (of reverse bin sort).

[cariolive23]

Nu willen we de snelste meting per station ophalen van de afgelopen 6 uur.

In SQL zou je dat op deze manier doen:

SQL:

SELECT 
  MAX(snelheid), 
  station 
FROM tabel 
WHERE tijd >= (NOW() - INTERVAL '6 HOUR')
GROUP BY station;

Zoiets moet je in MongoDB toch ook kunnen doen?

http://www.mongodb.org/display/DOCS/Aggregation

[ZpAz]

cariolive23 schreef op woensdag 16 november 2011 @ 12:07:
[...]

In SQL zou je dat op deze manier doen:

SQL:

SELECT 
  MAX(snelheid), 
  station 
FROM tabel 
WHERE tijd >= (NOW() - INTERVAL '6 HOUR')
GROUP BY station;

Zoiets moet je in MongoDB toch ook kunnen doen?

http://www.mongodb.org/display/DOCS/Aggregation

Ja hoor, ware het niet dat het veel te traag is.

[Hercul3s]

Is het geen mogelijkheid om je RAM zover uit te breiden dat de hele 6u database daarin past en met de snelheidswinst onder de 25 secs komen?

[Verwijderd]

ZpAz schreef op woensdag 16 november 2011 @ 11:59:
[...]
Sorry dan snap ik je vraag niet. Is je vraag: "komen alle metingen op zelfde tijdspannes ertussen binnen" dan ja. Elke seconde komt er een meting voor elke 8000 stations binnen.

Nee dat bedoelen we niet, toch Mike2k?

Als je om 12:07:52 kijkt, wil je dan data van 6:07:52 tot nu, of van 6:00 tot 12:00. In dat eerste geval zul je moeten optimaliseren, in het tweede geval kun je per klokuur de hoogste waarde opslaan (dus van 6:00 tot 7:00, van 7:00 tot 8:00 etc), en later 6 uren terugkijken. Heel simpel.

[ZpAz]

Hercul3s schreef op woensdag 16 november 2011 @ 12:08:
Is het geen mogelijkheid om je RAM zover uit te breiden dat de hele 6u database daarin past en met de snelheidswinst onder de 25 secs komen?

Helaas niet. 6 uur aan data loopt in de vele GB's.

[GlowMouse]

Heb je de data ouder dan 6 uur nog nodig? Ik denk even aan MySQL/InnoDB, waar je makkelijk dit makkelijk mee kunt doen:

je tabel heeft 3 kolommen: tijd,station,snelheid, de eerste datetime, de laatste twee integers
Primary key (tijd,station)
Secondary key (station,snelheid)

- met bulk-inserts zijn 8000 inserts makkelijk te halen
- elke seconde de 8000 records die ouder zijn dan 6 uur overzetten naar een archieftabel of verwijderen ook
- de query SELECT station,MAX(snelheid) GROUP BY station is heel snel

[freelh]

Van elk uur de 50 beste tijden registreren en elke 6 uur die 6*50=300 tijden vergelijken?
-> verondersteld dat je de 50 beste tijden zoekt van de voorbije 6 uur.

Hoeveel te traag loop je nu?

[ZpAz]

GlowMouse schreef op woensdag 16 november 2011 @ 12:11:
Heb je de data ouder dan 6 uur nog nodig? Ik denk even aan MySQL/InnoDB, waar je makkelijk dit makkelijk mee kunt doen:

je tabel heeft 3 kolommen: tijd,station,snelheid, de eerste datetime, de laatste twee integers
Primary key (tijd,station)
Secondary key (station,snelheid)

- met bulk-inserts zijn 8000 inserts makkelijk te halen
- elke seconde de 8000 records die ouder zijn dan 6 uur overzetten naar een archieftabel of verwijderen ook
- de query SELECT station,MAX(snelheid) GROUP BY station is heel snel

Ook al hebben we nog geen 6 uur aan data. Dan is het ook al te langzaam. (+- 3 uur).

Verwijderd schreef op woensdag 16 november 2011 @ 12:09:
[...]

Nee dat bedoelen we niet, toch Mike2k?

Als je om 12:07:52 kijkt, wil je dan data van 6:07:52 tot nu, of van 6:00 tot 12:00. In dat eerste geval zul je moeten optimaliseren, in het tweede geval kun je per klokuur de hoogste waarde opslaan (dus van 6:00 tot 7:00, van 7:00 tot 8:00 etc), en later 6 uren terugkijken. Heel simpel.

Het eerste inderdaad.

[GlowMouse]

ZpAz schreef op woensdag 16 november 2011 @ 12:14:
[...]


Ook al hebben we nog geen 6 uur aan data. Dan is het ook al te langzaam. (+- 3 uur).

Oh, je had al met InnoDB en de door mij genoemde tabellay-out getest?

[Hercul3s]

Per minuut de hoogste windsnelheid eruit filteren, scheelt je een factor x60 aan data, mss dat het dan snel genoeg is?

Edit: Dit eventueel doorvoeren (per 2 minuten, per 4 minuten etc) totdat je binnen 25 secs de data kan berekenen.

Je verliest hier natuurlijk wel aan accuratesse, maar aan de andere kant blijf je binnen een zeer klein timeframe (1 tot 4 minuten).

[ Voor 51% gewijzigd door Hercul3s op 16-11-2011 12:16 . Reden: Toevoeging ]

[cariolive23]

ZpAz schreef op woensdag 16 november 2011 @ 12:08:
[...]


Ja hoor, ware het niet dat het veel te traag is.

En waar heb je dan de index op gemaakt? Voor een SQL database ligt de combinatie datumtijd-station-snelheid voor de hand, dan is er maar heel weinig data nodig om de query te verwerken: Per station is maar één snelheid relevant, de hoogste. En omdat indexen vaak zijn gesorteerd (BTREE), kan de database hier heel snel doorheen vliegen.

Ik werk ook op een database met miljarden records, maar dit soort queries gaat echt in milliseconden, niet eens in seconden. Ik heb wel véél meer RAM tot m'n beschikking, dat maakt ongetwijfeld verschil.

Heeft MongoDB niet een soort van EXPLAIN om te zien hoe de query wordt uitgevoerd en waar de pijnpunten zitten?

Ps. Ik ben een SQL dba, praat dus met deze kennis in m'n achterhoofd.

[Miyamoto]

Waarom is er voor MongoDB gekozen?
Hang je vast aan de keuze?
Wat doe je nog meer?
Is het puur de query tijd die je nu noemt? (gooi er eens een explain tegenaan)
Moet alles in de query gebeuren?

En net zo belangrijk: Wat is de achterliggende opdracht/informatie die je hebt gekregen? Over welk vak hebben we het? Wat hoor jij te weten?

[GlowMouse]

Eigenlijk valt er niets zinnigs te zeggen zonder dat je de precieze eisen vermeldt. Alleen de snelste van de laatste 6 uur ophalen, is helemaal niet zo moeilijk. Als dat het enige is wat je moet doen, dan kun je dat met een zelfgeschreven applicatie zonder enige optimalisatie nog wel doen, alles van de laatste 6 uur past met een beetje efficiënte opslag makkelijk in het geheugen.

cariolive23 schreef op woensdag 16 november 2011 @ 12:18:
[...]

En waar heb je dan de index op gemaakt? Voor een SQL database ligt de combinatie datumtijd-station-snelheid voor de hand, dan is er maar heel weinig data nodig om de query te verwerken: Per station is maar één snelheid relevant, de hoogste. En omdat indexen vaak zijn gesorteerd (BTREE), kan de database hier heel snel doorheen vliegen.

Met die index heb je alle data van de afgelopen 6 uur nodig om de query te verwerken.

[dotcode]

Aangenomen dat mongo database om kan gaan met data zoals elke normale database zijn de hoeveelheden data waar je over praat niet heel erg veel en is je probleem meer van welke index en welke query je zou moeten maken. De volgende query zou je willen optimaliseren, ik heb een extra top(50) toegevoegd omdat je alleen in de top 50 geintreseerd bent:

SELECT top(50)
MAX(snelheid),
station
FROM tabel
WHERE tijd >= (NOW() - INTERVAL '6 HOUR')
GROUP BY station;

Is snelheid een int of double type? Zo niet dan maak er een double van.

Op tijd/snelheid/station moet een index komen, het liefst in combinatie.

Nu zou je query gewoon moeten werken binnen een seconde.

Mocht de index niet helpen, ga voor een andere database, elke normale database kan dit soort dingen standaard.

[ Voor 7% gewijzigd door dotcode op 16-11-2011 12:26 ]

[Foeijonghaai]

Aannamen:
station, 16 bits (plek voor 16384 stations)
tijd, 32 bits (unix timestamp)
windsnelheid: 32 bits (float)

Dat is 80 bits per meting => 10 bytes.

Na 6 uur heb je 8000*6*3600=172.800.000 metingen.

Dat is 172800000*10 bytes => 1687500 kilobytes => 1648 megabytes => 1.6GB.

Dat lijkt me behapbaar om in memory te doen.

Als je data na 6 uur waardeloos is, is downtime ook niet zo erg (voor zover ik dat voor je kan bepalen) Eventueel dump je per kwartier/uur naar disk.

Of zie ik iets over het hoofd?

[ZpAz]

Miyamoto schreef op woensdag 16 november 2011 @ 12:21:
Waarom is er voor MongoDB gekozen?

Volgens de opdracht mocht je ineens geen "relationele database" meer gebruiken.

Hang je vast aan de keuze?

Te weinig tijd om er van af te stappen.

Wat doe je nog meer?

We krijgen de gegenereerde data in XML formaat. Zelf een Java servertje geschreven welke het in MongoDB stopt. Helaas draait zowel de generator als de database op dezelfde server, hier gaan dus ook al cycles aan verloren.

Is het puur de query tijd die je nu noemt? (gooi er eens een explain tegenaan)

Zal hier naar kijken.

Moet alles in de query gebeuren?

Als sommige code buiten de query sneller kan, dan is dat prima.

En net zo belangrijk: Wat is de achterliggende opdracht/informatie die je hebt gekregen? Over welk vak hebben we het? Wat hoor jij te weten?

Niet zo zeer één vak. Mensen die een "gemiddelde" kennis hebben van Java, PHP en Mysql worden "hierin gegooid".

[4VAlien]

Moet je wel een No-SQL database gebruiken zoals Mongo? Met de eerder geposte aannames dat een record uit 32 + 32 bits bestaat zou ik gewoon 8.000 (1 per station) flatfiles op een ext4/ntfs of vergelijkbaar filesystem zetten en dan daar doorheen racen met een simpel programmatje (gewoon van eind van de file teruglezen tot max 6uur). Zolang het in RAM past kun je het zelfs multithreaded doen en anders is je disk de bottleneck dus dan is 1 of 2 threads slimmer.

[ Voor 0% gewijzigd door 4VAlien op 16-11-2011 12:34 . Reden: records van 64 ipv 80bit met veel files :-) ]

[GlowMouse]

4VAlien schreef op woensdag 16 november 2011 @ 12:32:
Moet je wel een No-SQL database gebruiken zoals Mongo? Met de eerder geposte aannames dat een record uit 16 + 32 + 32 bits bestaat zou ik gewoon 8.000 (1 per station) flatfiles op een ext4/ntfs of vergelijkbaar filesystem zetten en dan daar doorheen racen met een simpel programmatje (gewoon van eind van de file teruglezen tot max 6uur). Zolang het in RAM past kun je het zelfs multithreaded doen en anders is je disk de bottleneck dus dan is 1 of 2 threads slimmer.

Getallen opslaan als string is hier heel onverstandig.

[cariolive23]

GlowMouse schreef op woensdag 16 november 2011 @ 12:21:

[...]

Met die index heb je alle data van de afgelopen 6 uur nodig om de query te verwerken.

Nee, je hebt een paar blokjes data nodig uit de gesorteerde index en hiermee kun je dan een indexscan doen op de daadwerkelijke data. Dus ook daar zijn maar een paar blokjes data nodig uit de tabel. Dit wordt door de DBMS geregeld, hoef jij niet voor te zorgen. Jij moet er alleen voor zorgen dat de DBMS de mogelijkheid krijgt om dit te doen, jij moet dus de juiste indexen aanmaken i.c.m. een passende query.

Ik doe niet anders, al gaat het hier altijd om data van de afgelopen 2 uur. De totale omvang zal vergelijkbaar zijn, enige miljarden records.

[ZpAz]

De windspeed wordt inderdaad als double opgeslagen. Stationsnummer is een int. Datum een timestamp.

[GlowMouse]

cariolive23 schreef op woensdag 16 november 2011 @ 12:34:
[...]

Nee, je hebt een paar blokjes data nodig uit de gesorteerde index en hiermee kun je dan een indexscan doen op de daadwerkelijke data. Dus ook daar zijn maar een paar blokjes data nodig uit de tabel. Dit wordt door de DBMS geregeld, hoef jij niet voor te zorgen. Jij moet er alleen voor zorgen dat de DBMS de mogelijkheid krijgt om dit te doen, jij moet dus de juiste indexen aanmaken i.c.m. een passende query.

Jouw index is de data. En de index is niet zo goed gesorteerd dat je maar een paar blokjes nodig hebt; datetime als eerste kolom neemt heel veel verschillende waarden aan waardoor de waarde als BTREE afneemt. Als PK is de combinatie (tijd,station) handig omdat het uniek is en inserts dan mooi achteraan je tabel gaan, maar de uitbreiding met windsnelheid levert niks op.

[-DarkShadow-]

Waarom geen index op de windsnelheid? Dan is de SORT LIMIT op windsnelheid toch razendsnel?

[ Voor 42% gewijzigd door -DarkShadow- op 16-11-2011 12:42 ]

[ZpAz]

-DarkShadow- schreef op woensdag 16 november 2011 @ 12:41:
Waarom geen index op de windsnelheid?

Hebben we nu. Data is aan het pompen. Dus ben benieuwd.

[4VAlien]

GlowMouse schreef op woensdag 16 november 2011 @ 12:34:
[...]

Getallen opslaan als string is hier heel onverstandig.

Ik heb 'string' uberhaupt niet genoemd. Ik zit puur te denken aan binary flatfiles per station. Data schrijven zou nog steeds prima met Java kunnen en voor de ultieme snelheid zou je het zoeken met een klein C programma'tje kunnen doen.

[GlowMouse]

4VAlien schreef op woensdag 16 november 2011 @ 12:42:
[...]


Ik heb 'string' uberhaupt niet genoemd. Ik zit puur te denken aan binary flatfiles per station. Data schrijven zou nog steeds prima met Java kunnen en voor de ultieme snelheid zou je het zoeken met een klein C programma'tje kunnen doen.

Bedacht ik me ook ja, maar dan nog zit je met je filesystem (filename, ctime, mtime, atime, permissies, blocksize) die voor enorm veel overhead zorgt. Je kunt alles ook gewoon in je java-app in het geheugen houden. Met 4 GB past dat makkelijk.

[ Voor 5% gewijzigd door GlowMouse op 16-11-2011 12:47 ]

[Verwijderd]

Windsnelheden veranderen niet snel. Voeg een veld 'piek' toe en zet die op 'true' voor lokale maxima de volgende meting lager is dan de huidige. Hoef je nog maar een fractie van je data te doorzoeken.

[ Voor 6% gewijzigd door Verwijderd op 16-11-2011 13:58 ]

[Foeijonghaai]

ZpAz schreef op woensdag 16 november 2011 @ 12:35:
De windspeed wordt inderdaad als double opgeslagen. Stationsnummer is een int. Datum een timestamp.

Een int wordt meestal opgeslagen met 4 bytes. Door er een short van te maken heb je al weer 2 bytes winst.

Je zou er voor kunnen kiezen om niet de tijd op te slaan: feitelijk heb je 21600 verschillende tijden, ze zijn opeenvolgend, met een seconde verschil. Je moet dan alleen nog de tijd op te slaan waaraan ze relatief zijn.
21600 past ook weer in 2 bytes.

Je kunt kiezen voor een circulaire buffer (zie Wikipedia: Circular buffer). Het opslaan van een nieuwe waarde is dan gelijk aan het 'verwijderen' van een oude waarde.

[GlowMouse]

Foeijonghaai schreef op woensdag 16 november 2011 @ 12:48:
[...]

Een int wordt meestal opgeslagen met 4 bytes. Door er een short van te maken heb je al weer 2 bytes winst.

Wind fluctueert zoveel dat het ook in 1 byte past met eenheid m/s.

[cariolive23]

GlowMouse schreef op woensdag 16 november 2011 @ 12:38:
[...]

Jouw index is de data. En de index is niet zo goed gesorteerd dat je maar een paar blokjes nodig hebt; datetime als eerste kolom neemt heel veel verschillende waarden aan waardoor de waarde als BTREE afneemt. Als PK is de combinatie (tijd,station) handig omdat het uniek is en inserts dan mooi achteraan je tabel gaan, maar de uitbreiding met windsnelheid levert niks op.

Goed punt, de datetime moet een aparte index zijn. Puur om er voor te zorgen dat je slechts X uur aan data opvraagt. EXPLAIN zou dit ook laten zien.

De sortering op station en snelheid (BTREE index) is er om er voor te zorgen dat je per station slechts 1 maximale snelheid hoeft op te vragen, dat zijn dus maximaal 8000 blokken met 8000 stations. Het is dan afhankelijk van de IO hoe snel je dit van disk kan opvragen.

Een DBMS kan prima met 2 indexen gelijktijdig werken, dat mag geen probleem zijn.

[Verwijderd]

8000 inserts per seconde is vrij veel.
je zou er voor kunnen kiezen om GEEN index te leggen op de tabel.
dan gaat inserten alvast maximaal snel.

Net voor het opvragen van de MAX windsnelheid leg je gauw een tijdelijke index op windsnelheid
die je daarna dus weer verwijderd.

Merk op: veel hangt dan natuurlijk af van de frequentie waarmee je de max windsnelheid moet raadplegen.

Op zich is dat dan gefixed in een paar seconden. (zeker <25 sec)

[ZpAz]

Verwijderd schreef op woensdag 16 november 2011 @ 12:56:
8000 inserts per seconde is vrij veel.
je zou er voor kunnen kiezen om GEEN index te leggen op de tabel.
dan gaat inserten alvast maximaal snel.

Net voor het opvragen van de MAX windsnelheid leg je gauw een tijdelijke index op windsnelheid
die je daarna dus weer verwijderd.

Merk op: veel hangt dan natuurlijk af van de frequentie waarmee je de max windsnelheid moet raadplegen.

Op zich is dat dan gefixed in een paar seconden. (zeker <25 sec)

Het invoegen van de data in de database is het probleem niet. De server zou ongeveer 3x meer data in kunnen voegen zonder te flippen. Het berekenen van de snelste snelheid is het probleem.

[ Voor 3% gewijzigd door ZpAz op 16-11-2011 13:00 ]

[HMS]

Klinkt als een opdracht van de Hanzehogeschool.

Mijn tip: gebruik een custom binary formaat voor het opslaan, en kijk naar Java NIO. Dan zou het niet zo'n probleem moeten zijn.

[Verwijderd]

je kan ook voor ieder meetstation de MAX windsnelheid apart opslaan samen met het tijdstip waarop dat gebeurt is. Op deze mannier hoef je enkel windsnelheden te registreren die kleiner zijn dan MAX.
Wanneer het tijdstip van MAX dan langer is geleden dan 6uur dan ga je uit al de opgeslagen "mindere" values de nieuwe MAX bepalen. Dit zou je alvast veel data kunnen besparen. Tenzij de windsnelheid gedurende 6 uren gestaag afneemt natuurlijk ...

[-DarkShadow-]

Verwijderd schreef op woensdag 16 november 2011 @ 12:56:
8000 inserts per seconde is vrij veel.
je zou er voor kunnen kiezen om GEEN index te leggen op de tabel.
dan gaat inserten alvast maximaal snel.

Net voor het opvragen van de MAX windsnelheid leg je gauw een tijdelijke index op windsnelheid
die je daarna dus weer verwijderd.

Merk op: veel hangt dan natuurlijk af van de frequentie waarmee je de max windsnelheid moet raadplegen.

Op zich is dat dan gefixed in een paar seconden. (zeker <25 sec)

Inserten is niet het probleem.

Daarnaast is inserten razensnel in MongoDB, iig een stuk sneller dan gigabytes aan informatie te indexeren.

[ Voor 91% gewijzigd door -DarkShadow- op 16-11-2011 13:03 ]

[ZpAz]

HMS schreef op woensdag 16 november 2011 @ 13:00:
Klinkt als een opdracht van de Hanzehogeschool.

Mijn tip: gebruik een custom binary formaat voor het opslaan, en kijk naar Java NIO. Dan zou het niet zo'n probleem moeten zijn.

Helemaal correct. Veel tijd om het aan te passen hebben we helaas niet meer. Dus afstappen van Mongo is eigenlijk geen optie meer.

[Waking_The_Dead]

Verwijderd schreef op woensdag 16 november 2011 @ 12:47:
Windsnelheden veranderen niet snel. Voeg een veld 'piek' toe en zet die op 'true' als de volgende meting lager is dan de huidige. Hoef je nog maar een fractie van je data te doorzoeken.

Dat gaat helemaal niet werken vrees ik....

Stel dat je volgende fictieve metingen binnen krijgt: 10 9 8 7 6 5 4 3 2 1 2 3 4 5 6 7 8 9 10 11

In dat geval zijn de eerste negen waardes allemaal piek waarden maar de hoogste waarde uit de reeks zit er niet tussen....

[Verwijderd]

als inserten niet het probleem is, dan is het opvragen van de max waarde ook geen probleem. bij iets of wat database zou dat dan maximaal 1 seconde mogen duren of er is iets grondig fout!
172 miljoen records is geen enkel probleem als je je index op snelheid hebt liggen.
ik ken jullie DB-systeempje niet, maar met SQLite heb ik dat hier zo gepiept.

[ZpAz]

Het lijkt er op dat de index op windspeed ipv time duidelijk heeft geholpen. Nu met een half uur aan data kost het nog minder dan een seconde om de data op te vragen. Ben benieuwd hoe dit zich over een aantal uur verhoud.

Dat is 6GB aan data blijkbaar, op de HDD. (er wordt nog wat meer opgeslagen naast windspeed enzo.)

[ Voor 18% gewijzigd door ZpAz op 16-11-2011 13:06 ]

[Rye]

Ik neem aan dat Bredek nog steeds docent is in dit thema? Toen ik dit thema vorig jaar deed hadden we ook projectbegeleiding elke week. Gewoon even een half uurtje waarin je vragen kon stellen en je ook vragen moest stellen als je aanwezig was.

Klinkt alsof je hier niet naar toe bent geweest en dat er niet overlegd wordt met andere projectgroepen.

Het is namelijk de bedoeling dat je de data niet in een reguliere database opslaat.... maar dat je zelf een oplossing maakt. Je moet je data binair opslaan. Aangezien alle data die je binnen krijgt dezelfde structuur heeft kan je de data die je op wilt slaan even groot maken (1byte voor wind, 2byte voor temp, etc).
Ooit gehoord van een Random Access File? Google hier maar eens op en ga dan je programma aanpassen.

Ik weet niet of je nog een meeting hebt met je 'buitenlandse klanten', als je dat wel hebt; duidelijkere eisen vragen! Afgelopen 6 uur is leuk, maar met welke interval?! Realtime? Nutteloos, inefficiënt en belastend voor de hardware. Misschien hoeft het pas om het uur zichtbaar te zijn of om het half uur?
Dan kan je namelijk per uur/halfuur opslaan wat de snelste windsnelheid was en dat moet het toch al een heeeeeel stuk makkelijk maken!

Vooral erg belangrijk overigens: zorg dat je website goed in elkaar steekt! URL's die niet werken moet je afvangen. Het moet inprincipe niet mogelijk zijn om een error tegen te komen op de site.

Als je nog vragen hebt, vraag Bredek en overleg met andere projectgroepen. Dit is een redelijk pittige opdracht, maar zeker wel te doen

[ZpAz]

Rye schreef op woensdag 16 november 2011 @ 13:06:
Ik neem aan dat Bredek nog steeds docent is in dit thema? Toen ik dit thema vorig jaar deed hadden we ook projectbegeleiding elke week. Gewoon even een half uurtje waarin je vragen kon stellen en je ook vragen moest stellen als je aanwezig was.

Bredek had aan een ander groepje geadviseerd om het in losse tekst bestanden op te slaan.. goed, tot zo ver zijn bijdrage. Of dit heb ik verkeerd verstaan van het groepje.

Klinkt alsof je hier niet naar toe bent geweest en dat er niet overlegd wordt met andere projectgroepen.

De meeste projectgroepen gebruiken trouwens MongoDB.

Ik weet niet of je nog een meeting hebt met je 'buitenlandse klanten', als je dat wel hebt; duidelijkere eisen vragen! Afgelopen 6 uur is leuk, maar met welke interval?! Realtime? Nutteloos, inefficiënt en belastend voor de hardware. Misschien hoeft het pas om het uur zichtbaar te zijn of om het half uur?
Dan kan je namelijk per uur/halfuur opslaan wat de snelste windsnelheid was en dat moet het toch al een heeeeeel stuk makkelijk maken!

Onze opdracht was realtime van de afgelopen 6 uur. Dus klik en uitvoeren. Als het om het uur oid was was het inderdaad al makkelijker geweest. Daarom kregen we ook de 25 seconden window, omdat het "wel even" kon duren.

[ Voor 51% gewijzigd door ZpAz op 16-11-2011 13:10 ]

[Opperhoof]

Ik heb hier niet zoveel verstand van, maar het lijkt erop dat het probleem nog niet is opgelost.
Ik dacht aan het volgende:
Je moet de inkomende data direct sorteren voordat het opgeslagen wordt van hoog naar laag. Daarna laat je iedere seconde de metingen van 6 uur en 1 seconden verwijderen. Dan hou je een aflopende tabel over met de hoogste waarde bovenaan.

[HMS]

Nog even een tip: Je hoeft de queries niet in realtime uit te voeren, als je de data preprocessed en de resultaten klaar zet mag dat ook. Maar vermeld wel duidelijk dat je dit doet! Zo omzeil je de limiet van 25 seconden.

[Verwijderd]

je kan de opmerkingen van iedereen die over een "native file oplossing" zit te zeuren negeren.
dit is immers wat een goed database systeem voor jou al efficient zou moeten regelen.
Je kan altijd het warm water heruitvinden, maar het zal je in dit geval alleen maar meer tijd en bugs opleveren.

[Verwijderd]

stel dat de windsnelheden eruit zien als: 17.123578 km/u
Sla het ding dan gewoon op als een int: 17123578 (dus x 10^6 )
Dat zal heel de troep ook weer gezellig sneller maken

[Soultaker]

Foeijonghaai gaf een goede suggestie om het met de database op te lossen. Als die het niet trekt, zul je toch echt naar een oplossing buiten de database om moeten zoeken.

Een mogelijkheid kun je een sliding window maximum bijhouden (bijvoorbeeld op deze manier) waarbij je de data nog steeds in Mongo opslaat (maar dus niet Mongo's indices gebruikt om te queryen).

Een alternatief is om de data niet in een Mongo database te stoppen, maar een tool als rrdtool te gebruiken. Die is specifiek bedoeld voor dit soort statistieken.

[ Voor 4% gewijzigd door Soultaker op 16-11-2011 13:18 ]

[dotcode]

Je kan ook out of de box denken en de structuur voor opslag omgooien. Namelijk je pk op windsnelheid en station id leggen en als column de datum van de laatste keer dat de combi windsnelheid station gemeten is. Dan heb je veel minder data (blijft constant op den duur) en kan je toch zeggen wat de hoogste snelheid was in een tijdframe t/m nu.

[Barleone]

Goed, misschien ben ik gek, maar wat betreft die 8000 inserts per seconde, kun je die niet gewoon verkleinen tot 1 insert (de hoogste waarde van die 8000)?

[ZpAz]

Barleone schreef op woensdag 16 november 2011 @ 13:20:
Goed, misschien ben ik gek, maar wat betreft die 8000 inserts per seconde, kun je die niet gewoon verkleinen tot 1 insert (de hoogste waarde van die 8000).

In mijn TS zal dat wel niet duidelijk zijn geweest. Maar dit werkt niet. Omdat het een moving timeframe is. Daarnaast geeft elk station 1 insert per seconde (welke er 8000 zijn). Dus er maar één van over houden werkt niet

[ Voor 13% gewijzigd door ZpAz op 16-11-2011 13:22 ]

[Barleone]

ZpAz schreef op woensdag 16 november 2011 @ 13:21:
[...]
In mijn TS zal dat wel niet duidelijk zijn geweest. Maar dit werkt niet. Omdat het een moving timeframe is. Daarnaast geeft elk station 1 insert per seconde (welke er 8000 zijn). Dus er maar één van over houden werkt niet

Wil je dan van elk willekeurig station de hoogste windsnelheid kunnen achterhalen?
Of is de vraag: Wat is de hoogste windsnelheid gemeten in (Neder)land van de afgelopen 6 uur?
Dan lijkt het mij volkomen logisch om 7999 resultaten / seconde weg te gooien die toch nooit in aanmerking komen.

Anders gezegd, dit komt neer op een UNIQUE timestamp dingetje.

[ Voor 4% gewijzigd door Barleone op 16-11-2011 13:29 ]

[ZpAz]

Barleone schreef op woensdag 16 november 2011 @ 13:27:
[...]

Wil je dan van elk willekeurig station de hoogste windsnelheid kunnen achterhalen?
Of is de vraag: Wat is de hoogste windsnelheid gemeten in (Neder)land van de afgelopen 6 uur?
Dan lijkt het mij volkomen logisch om 7999 resultaten / seconde weg te gooien die toch nooit in aanmerking komen.

Anders gezegd, dit komt neer op een UNIQUE timestamp dingetje.

Klopt, maar omdat het een moving timeframe is werkt dit niet. (Je kan wel alles ouder dan 6 uur weggooien, maar dan heb je al een berg aan data.)

[Barleone]

ZpAz schreef op woensdag 16 november 2011 @ 13:32:
[...]
Klopt, maar omdat het een moving timeframe is werkt dit niet. (Je kan wel alles ouder dan 6 uur weggooien, maar dan heb je al een berg aan data.)

Lees mijn posts nog maar een keer, je mist mijn punt volkomen.
@hieronder @TS Sorry, my bad. Het klonk ook te mooi om waar te wezen, haha.
Per station. Ja, dan moet je het inderdaad zoeken in de technische oplossingen.

[ Voor 32% gewijzigd door Barleone op 16-11-2011 13:43 ]

[Tealiciouss]

Barleone schreef op woensdag 16 november 2011 @ 13:36:
[...]

Lees mijn posts nog maar een keer, je mist mijn punt volkomen.
Filter de data bij binnenkomst!
8000 waarden per seconde, daarvan kan er toch echt maar 1 de snelste zijn.
En het timeframe van 8000 resultaten is 1 seconde, dus niks geen timeframe problemen

timestamp 0000001 > 17km/h de snelste, 7999 resultaten weggooien.
timestamp 0000002 > 17,1km/h de snelste, 7999 resultaten weggooien.

Lees de eerste post dan nog maar eens, hij wil de snelste tijd per station. Dan moeten er dus 8000 resultaten per seconde opgeslagen worden. Niet 1.

[Guillome]

Hoe vaak moet je de hoogste windsnelheid bekijken? Realtime? Of 1 keer per uur?
Als het realtime is, waarom cluster je het dan niet? Dus niet elke keer 6 uur aan data afzoeken, maar deel het op in blokken van zeg 5 minuten. Je slaat dan per blok de hoogste waarde op.

[ZpAz]

Barleone schreef op woensdag 16 november 2011 @ 13:36:
[...]

Lees mijn posts nog maar een keer, je mist mijn punt volkomen.
Filter de data bij binnenkomst!
8000 waarden per seconde, daarvan kan er toch echt maar 1 de snelste zijn.
En het timeframe van 8000 resultaten is 1 seconde, dus niks geen timeframe problemen

timestamp 0000001 > 17km/h de snelste, 7999 resultaten weggooien.
timestamp 0000002 > 17,1km/h de snelste, 7999 resultaten weggooien.

Ik denk dat mijn reactie niet duidelijk was. Het is per station. En elke seconde krijg ik voor elk station een nieuwe meting binnen (welke er 8000 zijn). Je moet dan voor elk station kijken dus of er voorgaand een sneller was. If so, dan negeren, anders overschrijven.

Wat werkt, totdat je 6 uur terug in de tijd wilt gaan. Want dan je snelste meting "verlopen" en kan alsnog je één na snelste meting (van 4 uur geleden) sneller zijn dan de metingen die je nu binnnen krijgt. Maar die heb je dan al weggegooid.

[redwing]

Hercul3s schreef op woensdag 16 november 2011 @ 12:15:
Per minuut de hoogste windsnelheid eruit filteren, scheelt je een factor x60 aan data, mss dat het dan snel genoeg is?

Edit: Dit eventueel doorvoeren (per 2 minuten, per 4 minuten etc) totdat je binnen 25 secs de data kan berekenen.

Je verliest hier natuurlijk wel aan accuratesse, maar aan de andere kant blijf je binnen een zeer klein timeframe (1 tot 4 minuten).

Als je dit als extra data in je tabel opslaat kun je ook de hoeveelheid data die je moet bekijken verminderen. Als je b.v. per minuut het max van die minuut apart opslaat hoef je nadat je huidige max 6 uur oud is alleen die waardes per minuut te controleren op de hoogste waarde en daarna in de waardes die bij die minuut zitten kijken wat de precieze tijd is (opsplitsing kun je nog verder optimaliseren als je wilt.

[Woy]

ZpAz schreef op woensdag 16 november 2011 @ 12:14:
[...]
Het eerste inderdaad.

Met welke resolutie moet de nauwkeurigheid zijn en wat voor vertraging zit er in de data die je binnenkrijgt ( Kan het zijn dat je data met een uur vertraging binnen krijgt ).

Je zou natuurlijk gewoon in geheugen de maximale waardes voor elke seconde bij kunnen houden. Je hoeft dan bij elke sample alleen maar te kijken of het de hoogste windsnelheid van die seconde is. Voor een window van 6 uur hoef je dan maar 60*60*6 = 21600 waardes bij te houden, en dat is makkelijk in je werkgeheugen te doen. Als je de resolutie nog lager legt ( Bijvoorbeeld per minuut ) is het helemaal makkelijk te overzien, ook voor langere periodes.

edit:
Ah ik zie dat je het per weerstation wil weten, dan nog zou je de resolutie kunnen verkleinen om zo de hoeveelheid data enorm te verkleinen.

[ Voor 8% gewijzigd door Woy op 16-11-2011 13:52 ]

[Barleone]

ZpAz schreef op woensdag 16 november 2011 @ 13:40:
[...]
Ik denk dat mijn reactie niet duidelijk was. Het is per station...

Ik heb daar overheen gelezen in je TS, my bad.
@Woy hierboven: dat per seconde is onmogelijk, omdat voor elk van de 8000 stations de waardes toonbaar moeten blijven. Ik ging daar zonet de fout mee in, vandaar mijn excuus ^^

Een kleine optimalisatie zou je kunnen halen uit een oplopende windsnelheid. Alle OUDERE waarden kun je dan per definitie weggooien. Bij afnemende wind, loopt je database echter weer vol tot de maximale 6 uur.

edit:

Zie Verwijderd in "Snelste windsnelheid laatste 6 uur." voor een verdergaand idee.

[ Voor 25% gewijzigd door Barleone op 16-11-2011 14:25 ]

[Verwijderd]

Waking_The_Dead schreef op woensdag 16 november 2011 @ 13:03:
[...]Stel dat je volgende fictieve metingen binnen krijgt: 10 9 8 7 6 5 4 3 2 1 2 3 4 5 6 7 8 9 10 11

In dat geval zijn de eerste negen waardes allemaal piek waarden maar de hoogste waarde uit de reeks zit er niet tussen....

Oops, te weinig koffie. Idee is goed maar je moet inderdaad iets meer doen om de pieken er uit te vissen.

Enige probleem dat je dan nog hebt, wat Rubizon ook opmerkt, is wanneer alle waarden binnen de timeslice lager zijn dan die op het begin en einde van de slice. Om dat op te lossen heb je alle waarden alsnog nodig. Maar je neemt dan gewoon de max van de hoogste piek / snelheid op begin slice / snelheid eind slice.

[leuk_he]

Het is zondermeer de vraag wat je met zo'n database moet als je er niet goed in kunt zoeken.

Oplossingen heb ik hier al voorbij zien komen:
-Tabel met grotere granulateit, b.v. 1 uur, of 5 minuten met de max waarden.
-Tabel met alle max waarden en tijdstippen. Die buffer je en sla je pas op als er een nieuwe max waarde in gaat, of een oude maxwaarde uit de sliding window schuift. (complex... en zinloos, want 6 uur is ook maar zomaar gekozen, 6 uur +/- 5 minuten maakt niet uit, als de huidinge utischieters maar meegenomen worden)


Ik zit me echt af te vragen of een index zal helpen. De index zou op waarde en tijd moeten lopen, per station, wat toevallig ook denk ik alle velden in de tabel zijn. Een full index scan is trager dan een full table scan... dus een index scan zou je niks besparen.

Wellicht dat partioneren van de data (sharding in mongodb als ik effe 20 seconden zoek) helpt in het snel kunnen terughalen.

Maar als je data zodanig is opgeslagen dat je die niet snel genoeg kunt ophalen dan is hij niet goed geimplementeerd. Kijk vooral naar de beschikbare hardware, dat die optimaal gebruikt wordt. Dan moet je echt PRECIES kijken hoe het is geimplementeeerd, of hoe je het kunt implementeren. Bij grote datasets is dat weer ouderwets belangrijk.

[Verwijderd]

leuk_he schreef op woensdag 16 november 2011 @ 13:58:-Tabel met alle max waarden en tijdstippen. Die buffer je en sla je pas op als er een nieuwe max waarde in gaat, of een oude maxwaarde uit de sliding window schuift. (complex... en zinloos, want 6 uur is ook maar zomaar gekozen, 6 uur +/- 5 minuten maakt niet uit, als de huidinge utischieters maar meegenomen worden

Het verwijderen of toevoegen van maxima heeft niets te maken met andere maxima^*). Je houdt alle lokale maxima bij. Vervolgens kijk je binnen de set lokale maxima in een bepaalde tijd, hier zes uur, wat het absolute maximum is. Vergelijk die met de snelheden op het begin en einde van die zes uur; is één van die twee hoger dan is dat uiteraard het absolute maximum.

*) je zou oudere lokale maxima die lager zijn dan een nieuwe lokaal maximum kunnen verwijderen wanneer je alleen het maximum over de afgelopen zes uur (dus altijd nu - zes uur) wilt hebben. Maar dat lijkt me inderdaad veel te complex voor de winst die je ermee haalt.

[ Voor 16% gewijzigd door Verwijderd op 16-11-2011 14:13 ]

[Verwijderd]

Misschien dat dit antwoord al voorbij was gekomen (niet heel het topic gelezen)...

Je kan toch bij een insert van een nieuwe waarde alle waarden uit het verleden die lager zijn verwijderen, per meetstation uiteraard? Dit is anders dan alleen de hoogste waarde bewaren! (Het sliding window mechanisme werkt namelijk nog gewoon).

Als we bijvoorbeeld de volgende reeks met waarden hebben zijn we geinsteresseerd in de dikgedrukte waarden.
9, 10, 8, 7, 6, 5, 9, 8, 5, 2, 4, 5

Alle niet dikgedrukte waarden mogen verwijderd worden gezien deze niet interessant zijn.

Wanneer de wind gedurende 6 uur lang consistent blijft dalen heb je nog dezelfde situatie als nu, gezien dit practisch nooit zal voorkomen zal dit het aantal records dat je hebt in de database enorm verminderen.

[Verwijderd]

Wanneer de wind gedurende 6 uur lang consistent blijft dalen heb je nog dezelfde situatie als nu, gezien dit practisch nooit zal voorkomen zal dit het aantal records dat je hebt in de database enorm verminderen.

in de praktijk is het best denkbaar dat wind over een periode van pakweg 6u gestaag afneemt.

[Verwijderd]

in de praktijk is het best denkbaar dat wind over een periode van pakweg 6u gestaag afneemt.

Wanneer je het als trend bekijkt wel, maar wanneer je 1x per seconde een meting binnen krijgt zullen hier pieken en dalen in zitten en zal er nog steeds behoorlijke data vermindering zijn.

[Aloys]

Wat is nu inmiddels de snelheid van die query nu je de pi op windsnelheid hebt staan? Ik kan alleen nog maar terugvinden dat dat 1 sec was bij een half uur ofzo?

[Jegorex]

Zet in de database een flag bij de hoogste snelheid van elk station. Op het moment dat de flag bij een tijd staat die meer dan 6 uur oud is ga je op zoek naar een nieuwe hoogste windsnelheid voor dat station.

[Aloys]

Jegorex schreef op woensdag 16 november 2011 @ 16:07:
Zet in de database een flag bij de hoogste snelheid van elk station. Op het moment dat de flag bij een tijd staat die meer dan 6 uur oud is ga je op zoek naar een nieuwe hoogste windsnelheid voor dat station.

Dat kost veel meer rekenwerk denk ik, want je moet bij elke insect checken of de nieuwe waarde hoger is. Daarnaast moet je elke keer dat een waarde verloopt alle waarden in het sliding window doorzoeken naar een nieuwe hoogste.

[mux]

Naarmate het topic vordert begin ik me af te vragen: wat wordt er precies gedaan dat realtime moet?

1. wil je realtime weten wat de hoogste windsnelheid van één meetstation is?
2. wil je realtime weten wat de hoogste windsnelheid overal is?

1 is niet moeilijk. Dat zijn heel weinig waarden, dat kun je gemakkelijk processen (zelfs vanaf disk)
2 vereist meer optimalisatie en is waar de rest van dit topic naartoe lijkt te wekren.

[ZpAz]

Aloys schreef op woensdag 16 november 2011 @ 15:38:
Wat is nu inmiddels de snelheid van die query nu je de pi op windsnelheid hebt staan? Ik kan alleen nog maar terugvinden dat dat 1 sec was bij een half uur ofzo?

Meer dan drie uur data, nog steeds +- een sec.

[Aloys]

Lijkt erop dat dat dus een goede oplossing is .

[Henk007]

32 bits float

Kan iemand mij uitleggen wat het nut is om windsnelheid vast te leggen met een nauwkeurigheid van 0,01 mm/s en met welke apparatuur je dat kan meten?

Iets met huiswerkopdracht en afstand tot de realiteit...

[ Voor 6% gewijzigd door Henk007 op 16-11-2011 17:31 ]

[ZpAz]

Henk007 schreef op woensdag 16 november 2011 @ 17:28:
Kan iemand mij uitleggen wat het nut is om windsnelheid vast te leggen met een nauwkeurigheid van 0,01 mm/s en met welke apparatuur je dat kan meten?

Iets met huiswerkopdracht en afstand tot de realiteit...

Ik heb nergens aangegeven dat het met een bepaalde nauwkeurigheid is, maar het is met één achter de komma. Bijvoorbeeld: 40,1

[Henk007]

Dus 12 bits heb je genoeg aan, scheelt alweer bijna een factor 3 in data
Kun je windsnelheden tot 409,6 km/h vastleggen

Gerekend in m/s is 9 bit per meting voldoende.

[ Voor 56% gewijzigd door Henk007 op 16-11-2011 17:38 ]

[HMS]

Henk007 schreef op woensdag 16 november 2011 @ 17:33:
Dus 12 bits heb je genoeg aan, scheelt alweer bijna een factor 3 in data
Kun je windsnelheden tot 409,6 km/h vastleggen

Gerekend in m/s is 9 bit per meting voldoende.

Ja, want elke taal heeft support voor 9 of 12 bits integers . Mijn aanname is ook dat dit in Java is gemaakt dus zit je sowieso vast aan 32 bits integers (of 64 natuurlijk).

[Rainmaker1987]

Kan je niet je data in stukken opslaan (zeg voor het gemak even 30min), dus per half uur een tabel. Sla vervolgens ook per half uur je hoogste windsnelheid op. Het enige wat je dan nog hoeft te doen is per weerstation 12 waarden (de tabellen van het afgelopen 5,5 uur) + 1 tabel (het stukje dat het compleet maakt tot de 6 uur) moet bekijken voor de maximale waarde. Het lijkt mij dat je op deze manier iig veel minder data hoeft te doorzoeken.

[CaptJackSparrow]

De hoofddatabase is, zou je kunnen zeggen, op tijd gesorteerd. Je zou parallel daaraan een tweede database kunnen bijhouden die op windsnelheid is gesorteerd met daarbij een tijdstip gekoppeld aan de metingen. Elke nieuwe meetwaarde wordt dan ingevoegd in de database tussen de daaropvolgende hogere en lagere waarden. Van de hoogste waarden gooi je in die tweede database steeds alle waarden weg die ouder zijn dan 6 uur zodat de hoogste waarde van de laatste zes uur altijd het eerste record in de database is.

[Beatboxx]

Kan je niet elke x seconden de snelste van de afgelopen x seconden nemen, die opslaan, en op het einde het snelste van al die dingen nemen? Als je elke 5 minuten een snelste waarde opschrijft, kan je makkelijk op het einde die tweede database/tabel pakken.

plan 2: Je noteert steeds alleen de snelste van de 8000 die je per seconde binnen krijgt. Dus je neemt van die 8000 steeds alleen de snelste(n) en die zet je in de database.

[Barleone]

@Beatboxx: helaas, plan 2 is al 2x gesuggereerd, maar de resultaten moeten per station opvraagbaar zijn.

---

Nieuw idee: Van 172,8 miljoen resultaten naar +/-14,5 miljoen.

1. Je vat elk half uur samen in 8000 hoogste resultaten. Dat kun je maar van 5,5 uren doen.
   Dus 11 x 8000 = 88.000 resultaten.
2. Het recentste halfuur is nog niet compleet, dus neem je gewoon alle resultaten.
   Dus 8000 x 1799sec = 14392000 resultaten
3. Het laatste halfuur wordt steeds korter uiteraard, dus neem je de resultaten die je nog nodig hebt.
   Dus 8000 x 1sec = 8000 resultaten

Samen zijn dit 14.488.000 resultaten. Uiteraard zijn de aantallen van het eerste/laatste halfuur verschillend, maar opgeteld zijn ze maar een half uur.

Uiteraard behoud je alle resultaten, alleen van die middelste 5,5 uur van het timeframe neem je de hoogste 88.000 scores die je even 'op-een-blaadje' of weet ik veel waar noteert.

---

edit:

Als je dit indeelt in kwartieren kom je zelfs op maar 738.4000 resultaten. Optimaliseer maar een eind weg zou ik zeggen, succes!

[ Voor 31% gewijzigd door Barleone op 16-11-2011 19:23 ]

[Henk007]

Opnieuw het wiel uitvinden is interessant, maar niet nodig als iemand anders het ooit heeft gedaan:
o.a. :
Sliding Window Maximum
Maximum in sliding window
Sliding Window Maximum

Efficiënter gaat het niet ( O(n) ). Als je hardware dit niet redt is het jammer maar helaas.

[ Voor 40% gewijzigd door Henk007 op 16-11-2011 20:59 ]