Exportation des données de suivi
Au fur et à mesure que les appareils de suivi fonctionnent, leurs données sont envoyées et stockées dans la base de données de la plateforme Navixy, afin que vous puissiez consulter les trajets dans le module de surveillance et générer des rapports de trajet. Toutefois, il peut exister des situations où vous devez extraire toutes les informations d’enregistrement du suivi sous forme de points de géolocalisation. Cela est généralement nécessaire pour analyser les données dans des situations controversées. Dans ce cas, vous pouvez demander ces informations directement à la base de données.
Vous aurez besoin d’un accès direct à la base de données MySQL pour extraire les données de suivi, ce qui signifie que vos clients ne disposent pas des droits pour cette opération, et seuls les techniciens ayant accès au serveur possèdent l’autorisation nécessaire.
Les données de suivi sont stockées dans la base de données tracking Selon la date et la méthode de déploiement de votre instance de plateforme, deux façons fondamentalement différentes d’organiser la structure de la base de données sont possibles.
Structure par buckets. Dans ce cas, les données de suivi sont partitionnées en plusieurs buckets (16 par défaut).
Structure fichier par fichier, où chaque traceur correspond à une table séparée nommée d’après son IMEI.
Le type d’organisation des données que vous utilisez est facile à vérifier en ouvrant simplement le répertoire de stockage des fichiers de la base de données - par exemple, sous Linux ceci est /var/lib/mysql/tracking par défaut. À l’intérieur, vous trouverez soit des fichiers partitionnés nommés comme bucket_****.ibd, soit plusieurs fichiers ibd et fichiers frm nommés d’après l’IMEI des appareils.
Il n’existe pas de méthode conventionnelle pour changer la base de données de fichier-par-fichier en buckets ou inversement, car cela impliquerait de reconstruire l’ensemble de la base de données. Une fois déployée, la base de données conserve sa structure initiale.
Structure par buckets
Il s’agit d’un type contemporain d’organisation de base de données où, pour optimiser les performances, les données ne sont pas stockées dans des tables individuelles pour chaque traceur, mais dans les soi‑disant buckets. Par défaut, il y en a 16, les traceurs y sont placés de manière aléatoire. Chaque traceur possède son propre storage_id, selon lequel nous pouvons retrouver le bucket requis.
Pour demander les données, vous avez besoin de l’IMEI du traceur (dans cet exemple, nous utilisons l’IMEI fictif 987654321012345), et de l’identifiant interne de l’appareil nommé source_id.
Découvrez source_id et storage_id en utilisant cette requête :
SELECT storage_id, source_id FROM google.sources WHERE source_imei='987654321012345'; Le storage_id résultat commence par le numéro du bucket - de 1 à 16. Par exemple, storage_id=201000 signifie bucket_2 et storage_id=1301000 signifie bucket_13.
Dans la requête suivante, nous avons besoin à la fois du numéro du bucket et du source_id. Avec cette requête nous sollicitons les données de suivi pour la période requise et les exportons dans un fichier CSV.
Veuillez noter :
nous utilisons le
source_idetbucketnuméro trouvé avec la requête précédente.get_timeest le moment d’enregistrement des données par l’appareil, il est spécifié en UTC+0, indépendamment du fuseau horaire du compte utilisateur.MySQL doit disposer des permissions d’écriture dans le dossier spécifié dans la requête.
La requête SQL elle‑même est la suivante :
SELECT 'Id','TrackID','Server time','Tracker time','Longitude','Latitude','Speed','Altitude','Satellites','Status','Heading','Event ID','Duration','Mileage','Inputs','Outputs','Address'
UNION ALL
SELECT id, track_id, actual_time, get_time, lng, lat, speed, alt, satellites, status, heading, event_id, duration, mileage, input_status, output_status, address
FROM tracking.bucket_2 where source_id=12345 and get_time between '2024-07-20 20:11:00' and '2024-07-20 20:13:00'
INTO OUTFILE "/var/lib/mysql-files/987654321012345.csv"
FIELDS TERMINATED BY ','
ENCLOSED BY '"' LINES
TERMINATED BY '\n';Pour Windows, le chemin ressemble à :
INTO OUTFILE "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv"Structure fichier par fichier
Ceci est une ancienne manière d’organiser la structure de la base de données, qui reste toutefois pertinente pour de nombreuses instances Navixy ayant plusieurs années d’historique.
Pour demander les données dans ce cas, vous n’avez besoin que de l’IMEI du traceur (dans cet exemple, nous utilisons l’IMEI fictif 987654321012345).
Veuillez noter :
get_timeest le moment d’enregistrement des données par l’appareil, il est spécifié en UTC+0, indépendamment du fuseau horaire du compte utilisateur.MySQL doit disposer des permissions d’écriture dans le dossier spécifié dans la requête.
La requête SQL est la suivante :
SELECT 'Id','TrackID','Server time','Tracker time','Longitude','Latitude','Speed','Altitude','Satellites','Status','Heading','Event ID','Duration','Mileage','Inputs','Outputs','Address'
UNION ALL
SELECT id, track_id, actual_time, get_time, point_y, point_x, speed, altitude, satellites, status, heading, event_id, duration, mileage, input_status, output_status, address
FROM tracking.987654321012345 where get_time between '2024-07-20 20:11:00' and '2024-07-20 20:13:00'
INTO OUTFILE "/var/lib/mysql-files/987654321012345.csv"
FIELDS TERMINATED BY ','
ENCLOSED BY '"' LINES
TERMINATED BY '\n';Pour Windows, le chemin ressemble à :
INTO OUTFILE "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv"Export des données
La requête SQL ci‑dessus générera un fichier CSV contenant tous les points de suivi enregistrés pour l’appareil.
Ce fichier peut être importé dans Excel ou utilisé dans tout développement interne.
Mis à jour
Ce contenu vous a-t-il été utile ?