Opslag van voertuiglocaties, wat is de beste oplossing

[AW_Bos]

Ik zit met een interessant vraagstuk, en ik ben benieuwd of andere Tweakers iets soortgelijks hebben gebouwd.

Het gaat om een systeem wat ik aan het ontwikkelen ben die voertuiglocaties vanuit GPS (treinen om precies te zijn) op een GoogleMaps kaartje gaat tonen. De data krijg ik met een tijdsinterval van 10 sec. uit een ZMQ-datastroom van mijn provider ^*1, en met NodeJS wil ik deze dus aan de lopend band ophalen.
Mijn voorkeur gaat zelf uit naar NodeJS omdat dit goede performance zou moeten hebben/

Op een klein detail na is dit al gelukt. Echter zit ik ook met de opslag. Ik wil van elke trein zijn route opslaan zodat er op de map een mooie poly-line gevormd kan worden, en dat je kan zien welke route de trein gereden heeft.

Ook wil ik natuurlijk de actuele posities tonen. Ik kan natuurlijk ook elke 10 seconden een bestand schrijven en die door PHP laten parsen, maar is dat niet intensief voor een server als deze constant een bestand overschrijft? Of is het zinvoller om de actuele posities dan uit de database te filteren?

Elke 10 seconden worden er tussen de 300 - 500 treinen gelogd, dus er is sprake van een hoop schrijfacties als ik MySQL ga gebruiken.

Dus wat is jullie advies voor een goede performance? Ik wil natuurlijk niet dat mijn server (zo'n cheap OVH-bakkie als ik eerlijk mag zijn^*2 ) op een gegeven moment behoorlijk staat te hikken en te stoten.

Misschien dat een andere Tweaker iets soortgelijks gemaakt heeft, en wat kan uitwijden over zijn set-up en zijn performance. Anderzijds is een advies zeker welkom, zodat ik straks de goede weg insla.

_{*1) Het NDOV-loket
*2) Een TransIP Blade VPS met big-ass snelheid lijkt mij wel toffer. Maar tja, het blijven de kosten, hé}

[ Voor 3% gewijzigd door AW_Bos op 16-01-2018 13:38 ]

[emnich]

Ik zou eerst eens bedenken óf je wel elke 10s wil opslaan. Als een trein met 140km/u rijdt, is ie slechts 40m verder. Daarbij weet je ook al wel globaal de route die de trein neemt want hij zal niet vaak van het spoor raken.was vergeten het weer met 10(s) te vermenigvuldigen

En waarom zou je van een trein die 5m op een station staat 30 records op slaan?

Als je dit soort zaken al filtert bij het binnenkomen dan scheelt dat weer schrijfacties.

Dat gezegd hebbende, 500 records per 10 sec lijkt me nu niet echt een heel groot probleem.

[ Voor 6% gewijzigd door emnich op 16-01-2018 13:53 ]

[Rmg]

Ik zou het eerst eens proberen te draaien op een mysql/postgres/whatever database. Zoveel is het niet. Daarnaast zijn er nog een hele hoop tune opties. Flushen iets uitstellen, table in memory en die elke 10 seconden wegschrijven, etc etc.

140 kilometer per uur is trouwens 39 meter per seconde, je bent dan dus 400 meter verder

[Verwijderd]

emnich schreef op dinsdag 16 januari 2018 @ 13:47:
Ik zou eerst eens bedenken óf je wel elke 10s wil opslaan. Als een trein met 140km/u rijdt, is ie slechts 40m verder. Daarbij weet je ook al wel globaal de route die de trein neemt want hij zal niet vaak van het spoor raken.

En waarom zou je van een trein die 5m op een station staat 30 records op slaan?

Als je dit soort zaken al filtert bij het binnenkomen dan scheelt dat weer schrijfacties.

Dat gezegd hebbende, 500 records per 10 sec lijkt me nu niet echt een heel groot probleem.

40m in 10 seconden? Ik hoop dat ik nooit in jou trein hoef te zitten

Maak daar maar bijna 400 van

[emnich]

@Rmg en @Verwijderd yep stom, gefixt.

@AW_Bos Ga het eerst eens maken en ga dan kijken waar de eventuele bottleneck zit. Het belangrijkste is denk ik om je historie op een gegeven moment af te voeren. Maar ook daarbij, kijk eerst of er wel echt performance problemen zijn.

[AW_Bos]

emnich schreef op dinsdag 16 januari 2018 @ 13:57:
@Rmg en @Verwijderd yep stom, gefixt.

@AW_Bos Ga het eerst eens maken en ga dan kijken waar de eventuele bottleneck zit. Het belangrijkste is denk ik om je historie op een gegeven moment af te voeren. Maar ook daarbij, kijk eerst of er wel echt performance problemen zijn.

Dat wil ik zeker gaan doen, maar ik was vooral benieuwd wat anderen kiezen. Ik wil liever niet een verkeerde weg inslaan om tot de conclusie te komen dat ik weer opnieuw moet beginnen.

Verder log ik het liefst elke trein, ook al staat deze stil. Zo kan je eventueel nog andere statistieken eruit halen, zoals vertragingen of iets dergelijks. De bedoeling is om alles voor 3 dagen op te slaan op ritnummer.

Verder krijg ik dus elke 10 seconden een XML-feed over de ZMQ met alle posities.

[ Voor 4% gewijzigd door AW_Bos op 16-01-2018 14:02 ]

[alex3305]

In plaats van MySQL zou je een spatial database kunnen gebruiken zoals PostgreSQL met PostGIS. Die kan ook wat sneller een mooie LineString berekenen, aangezien er spatial indexes aanwezig zijn. Tevens kun je het aantal schrijfacties beperkt houden door met PHP PDO in transacties te werken - eventueel in combinatie met een stored procedure.

Die paar duizend resultaten per dag zouden peanuts moeten zijn voor een redelijk standaard PostGIS setup. Je zou daarvoor eventueel GeoServer kunnen plaatsen om het te visualiseren of je zou het zelf kunnen doen. Daarnaast zou ik wel elke dag of week de database truncaten om performance problemen te voorkomen. Dit zou je in PostgreSQL kunnen doen door middel van een mooie Materialized View bovenop de tabel(len).

[emnich]

AW_Bos schreef op dinsdag 16 januari 2018 @ 14:01:
[...]

Dat wil ik zeker gaan doen, maar ik was vooral benieuwd wat anderen kiezen. Ik wil liever niet een verkeerde weg inslaan om tot de conclusie te komen dat ik weer opnieuw moet beginnen.

Verder log ik het liefst elke trein, ook al staat deze stil. Zo kan je eventueel nog andere statistieken eruit halen, zoals vertragingen of iets dergelijks. De bedoeling is om alles voor 3 dagen op te slaan op ritnummer.

Verder krijg ik dus elke 10 seconden een XML-feed over de ZMQ met alle posities.

Als je maar 3 dagen bewaart dat kan je gewoon bij MySQL blijven (als je je daar het prettigst bij voelt). Een paar tips:

Maak er één query van en niet 500 aparte (dus INSERT INTO table VALUES (1,2),(3,4)
Als dat niet goed genoeg is kan je ook nog kijken naar LOAD DATA IN FILE maar bovenstaande moet voldoende zijn.

Voor je 'live' data kan je gebruik maken van een MEMORY table maar wederom het zijn niet zo veel records dus een simpele VPS moet dat best aan kunnen.

[AW_Bos]

Hm.. een memory-table. Dat is toch iets waar ik me in moet verdiepen.
Maar ik ben al blij te horen dat de performance wel mee zou moeten vallen.

[The Eagle]

Zelf weinig ervaring mee, maar dit klinkt als een mooie voor een timeseries database. Check OpenTSDB even, draait bovenop Hbase (en daarmee bovenop HDFS). Evt memcached voorzetten.

[emnich]

AW_Bos schreef op dinsdag 16 januari 2018 @ 14:14:
Hm.. een memory-table. Dat is toch iets waar ik me in moet verdiepen.
Maar ik ben al blij te horen dat de performance wel mee zou moeten vallen.

Een memory table is niets anders dan dat MySQL het in memory houdt en niet naar de disk schrijft. Hierdoor is het dus veel sneller maar ben je ook je gegevens kwijt na een reboot. Je kan dat dus als een soort cache gebruiken. Uiteindelijk zal je het echter wel naar een disk moeten pompen.

Zoals anderen hier ook al aangeven zijn er ook andere tools voor die wat specifieker aansluiten op je case maar gezien de vraagstelling denk ik dat MySQL prima voldoet.

[AW_Bos]

Met MySQL heb ik op dit moment ook het meeste ervaring mee. Ik dnek zelf ook wel dat dit prima moet performancen. Tuurlijk ga ik op den duur kijken of het nog beter kan natuurlijk, maar ergens moet het begin zijn.

[ Voor 30% gewijzigd door AW_Bos op 16-01-2018 14:49 ]

[Verwijderd]

Als het echt losse trajecten/ritten zijn kun je ook nog overwegen om de gegevens van een traject, als die voltooid is, vanuit de real-time GPS-tabel over te hevelen naar een tabel waar je het complete traject als polygoon opslaat. Dan kun je daarna de real-time tabel weer opschonen.

[steveman]

Bestaat dit al niet?
http://treinenradar.nl/

[Sandor_Clegane]

Postgres is goed met GPS locaties, je hebt het Point datatype voor LAT-LON. Eventueel kun je ook nog PostGIS installeren, draait openstreetmap ook op.

[Verwijderd]

PS - MySQL ondersteunt spatial data ook al een tijdje

[Verwijderd]

steveman schreef op dinsdag 16 januari 2018 @ 16:25:
Bestaat dit al niet?
http://treinenradar.nl/

Dat is ongeveer hetzelfde als in de Casemod sectie zeggen dat er al casemods bestaan...

Ontopic: aangezien je al ervaring hebt met MySQL lijkt me dat de meest voor de hand liggende keuze. (zou performance wise ook prima moeten werken)
Echter als dit project hobbymatig is zou ik juist een optie pakken zoals The Eagle aangeeft, leer je weer eens wat nieuws!

[epic007]

Reken het eens uit, wat wil je opslaan? Het lijkt me dat je tabel de volgende velden heeft..

TreinId (32bit int), TimeStamp(32bit), Latitude(64bit double), Longitude(64bit double)

32+32+64+64 = 192 / 8 = 24 bytes per regel

24 * 500 = 12000 bytes per bericht (elke 10sec)

Of krijg je meerdere posities per trein per bericht??

12000 / 10 = 1200 bytes per seconde

Per megabyte (1024*1024 bytes) kan je dus ongeveer 873 posities opslaan.

Per GB heb je ongeveer 10 dagen aan data..

Dit kan prima met MySQL, ik zou alleen je INSERT queries zo bouwen dat je per keer maar een X aantal posities opslaat. Dus niet één SQL query per positie maar ook niet alle posities in een keer naar MySQL sturen.

Het mooiste is dit op te delen in threads met verschillende verantwoordelijkheden:

1. Uitlezen data van socket
2. Parsen van de XML data naar een in een interne datastructuur
3. Batchgewijs opslaan van de data richting MySQL (of iets anders)

Ik weet alleen niet of NodeJS dit kan..

[Morrar]

Weleens naar Kafka gekeken? Je zou die treinen iedere 10 seconden op een tipic kunnen zetten.

Je website kan de actuele locaties dan van het topic plukken zodra er nieuwe data verschijnen.

Je database (bv PostgreSQL) kan hetzelfde topic volgen, maar dan om de data op re slaan in een tabel. Die tabel kun je dan bevragen voor de route lijntjes, maar dat hoeft ws niet iedere 10 sec; wellicht eenmalig bij het laden van de site?

Met Kafka kun je e.e.a. mooi onafhankelijk van elkaar maken en eventueel ook redundancy inbouwen. Als je nog fancy dingen in wilt bouwen qua processing of machine learning kun je nog Spark streaming of Flink overwegen.

Maar goed, gewoon wat ideetjes :-)