[MySQL] CSV files wegschrijven

[0fbe]

Beste Forummmers,

Ik ben bezig met een applicatie waar ik database technisch mijn bedenkingen bij heb.

Het volgende:
Een applicatie die *.csv files die uit temperatuur loggers komen moet deze in een MySQL database wegschrijven. Het is een tracking systeem voor slecht conserveerbare goederen. Per zending zullen er maximaal 4 loggers mee gaan (deze kunnen op verschillende tijden gestart worden)

Een csv bevat gemiddeld 5000 records (20.000 records per zending dus!) Deze records bestaan uit een datum+tijd en temperatuur. Hieraan moet een het ID van de zending worden toegevoegd zodat de gegevens opzoekbaar zijn in de database en een Logger ID omdat er meerdere metingen van een moment zijn. (deze kunnen ook van verschillende zendingen komen).

De database wordt dus binnen de een korte tijd enorm. En ik heb geen ervaring met deze enorme aantallen van gegevens. In het kort zal MySQL dus moeten filteren op zending ID en dan joinen op de datum+tijd, alleen dit over 20.000 records. Elke dag een aantal keer.

Deze temperatuur gegevens worden daarna weergegeven in grafieken en opnieuw terug in csv's (alleen dan met 1x datum en tijd en 4x temperatuur gejoined dus). Mijn vraag is dus of dit gaat werken en of ik nog iets er aan kan optimaliseren. (Ik zou iets kunnen indexen maar welke? geen van de getallen zijn uniek)

En toen was ik de titel vergeten af te maken

[ Voor 6% gewijzigd door 0fbe op 10-02-2007 16:50 ]

[Megamind]

Als je alle records geinsert hebt een index maken en dan zal het zaakje wel snel blijven gaan

[0fbe]

Megamind schreef op zaterdag 10 februari 2007 @ 16:42:
Als je alle records geinsert hebt een index maken en dan zal het zaakje wel snel blijven gaan

Een index waarop? een appart ID toevoegen voor elke meetwaarde? In dezelfde tabel kunnen namelijk 2 en meer dezelfde: data, temperaturen, zending ID's, logger ID's voorkomen.

[Megamind]

Zowiezo heb je een ID kolom nodig, anders wordt je data onhandelbaar, probeer eens wat en doe dan EXPLAIN, deze kan je wel wat vertellen om je database te optimatlizeren

[0fbe]

Allereerst bedankt voor je moeite.

Je zegt dat me data anders onhandelbaar wordt, maar dit begrijp ik niet helemaal. Het enige wat gebeurd met de data is de volgende: Ik selecteer me zend id, join de data/tijden (die over maximaal 4 records hetzelfde zijn) Ik krijg dus een tabel met daarin:

code:

 datum/tijd | temp1 | temp2 | temp3 | temp4

Deze word uitgelezen door een grafiek library die doormiddel hiervan een grafiekje plot. (en controleerd of de max of min niet onverschreden is maar dit is een redelijk simpele mysql opdracht)

Ik zal eens een aantal waarden in de database laten stoppen en EXPLAIN gebruiken.

[ Voor 7% gewijzigd door 0fbe op 10-02-2007 19:14 ]

[Verwijderd]

Megamind schreef op zaterdag 10 februari 2007 @ 18:29:
Zowiezo heb je een ID kolom nodig, anders wordt je data onhandelbaar

Dat heeft 'ie niet nodig. Hij heeft een zender ID en een timestamp per record, en dat is uniek. Dan is 't onzin om nog een synthetische ID kolom toe te voegen.

[0fbe]

Verwijderd schreef op zaterdag 10 februari 2007 @ 23:18:
[...]
Dat heeft 'ie niet nodig. Hij heeft een zender ID en een timestamp per record, en dat is uniek. Dan is 't onzin om nog een synthetische ID kolom toe te voegen.

Mijn timestamp is niet uniek, de combinatie loggerID en timestamp echter wel:
Elke logger verzameld ongeveer 5000 records over de tempertuur over 4 dagen (elke minuut een reading) deze slaat hij dmv software op in een csv. Per zending zijn er maximaal 4 loggers. Elke logger heeft een eigen ID. In de database worden dus die 5000 records opgeslagen (Tijd, Waarde) hieraan word een temperatuur logID toegevoegd om de waardes uniek te maken (anders heb je tot 4 dezelfde waardes in je tabel zitten) een een zendingID om het zoeken te versimpelen.

[Creepy]

Wat is dan je probleem? Denk je een probleem te krijgen omdat je 20.000 records per zending kan krijgen? Kijk gewoon eens naar de queries die je wilt gaan gebruiken en bepaal aan de hand hiervan de indexen op je tabel. Een database is prima geschikt om veel records in op te slaan. Als het echt te groot begint te worden dan kan je altijd nog oude records naar een tweede tabel verplaatsen.

Dat je denkt nu al een probleem te hebben vind ik nogal voorbarig

[0fbe]

Creepy schreef op zondag 11 februari 2007 @ 11:14:
Wat is dan je probleem? Denk je een probleem te krijgen omdat je 20.000 records per zending kan krijgen? Kijk gewoon eens naar de queries die je wilt gaan gebruiken en bepaal aan de hand hiervan de indexen op je tabel. Een database is prima geschikt om veel records in op te slaan. Als het echt te groot begint te worden dan kan je altijd nog oude records naar een tweede tabel verplaatsen.

Dat je denkt nu al een probleem te hebben vind ik nogal voorbarig

Mijn vraag was waarop ik zou kunnen optimaliseren. Elk jaar zal er een nieuwe tabel gemaakt worden maar dit betekend nog wel dat er in het slechste geval zo'n 7,5 miljoen records in een database kunnen zitten. Geen van de kollommen waarop ik een query uitvoer bevat totaal unieke waardes, combinaties zijn echter wel uniek. Er wordt bijna altijd een where clausule uitgevoerd op de zending ID, ik zou hier dus een Index op kunnen zetten. Probleem is dat je dan nog 20.000 records met hetzelfde zending ID over houd.

[ Voor 3% gewijzigd door 0fbe op 11-02-2007 13:41 ]

[Pete]

Hoe nauwkeurig zijn de loggers? Als het bijv. maar op 1 graad nauwkeurig is zul je vaak meerdere dezelfde waarden achter elkaar hebben. Dit zou je dan als 1 record kunnen opslaan met begintijd-eindtijd-temperaturen-(aantal metingen in tijdsbestek)

[0fbe]

phsmit schreef op maandag 12 februari 2007 @ 13:58:
Hoe nauwkeurig zijn de loggers? Als het bijv. maar op 1 graad nauwkeurig is zul je vaak meerdere dezelfde waarden achter elkaar hebben. Dit zou je dan als 1 record kunnen opslaan met begintijd-eindtijd-temperaturen-(aantal metingen in tijdsbestek)

Op tiende graad nauwkeurig, als ik een van me logs bekijk komt het door jouw beschreven scenario niet voor.

[Voutloos]

timcooijmans schreef op zondag 11 februari 2007 @ 13:39:
Probleem is dat je dan nog 20.000 records met hetzelfde zending ID over houd.

Waarom moet dit een probleem zijn? Je hebt redelijk wat rijen, maar wel vrij kort en fixed length. Ik zou er zelf niet echt wakker van liggen.