Exportación de datos de seguimiento

A medida que los dispositivos de seguimiento operan, sus datos se envían y almacenan en la base de datos de la plataforma Navixy, por lo que puede ver los viajes en la monitorización y generar informes de viajes. Sin embargo, pueden darse situaciones en las que necesite volcar toda la información de seguimiento registrada como puntos de geolocalización. Esto suele ser necesario para analizar los datos en situaciones controvertidas. En ese caso, puede solicitar dicha información directamente desde la base de datos.

Este método le permite obtener los datos de una manera más detallada y “técnica” de lo que ve en la monitorización. Pero es importante entender que, para aparecer en la base de datos, los datos deben haber sido realmente transmitidos por un dispositivo de seguimiento, y no será posible restaurar viajes que falten por completo en la monitorización de este modo.

Necesitará acceso directo a la base de datos MySQL para extraer los datos de seguimiento, lo que significa que sus clientes no tienen derechos para esta operación, y solo los técnicos con acceso al servidor tienen la autorización necesaria.

Los datos de seguimiento se almacenan en la base de datos tracking . Dependiendo de cuándo y cómo se desplegó su instancia de la plataforma, son posibles dos formas fundamentalmente diferentes de organizar la estructura de la base de datos.

• Estructura por buckets. En este caso, los datos de seguimiento se particionan en varios buckets (16 por defecto).

• Estructura por archivo, donde a cada rastreador le corresponde una tabla separada nombrada por su IMEI.

El tipo de organización de datos que está usando es fácil de comprobar simplemente abriendo el directorio de almacenamiento de los archivos de la base de datos: por ejemplo, en Linux esto es /var/lib/mysql/tracking por defecto. En su interior encontrará bien archivos particionados nombrados como bucket_****.ibd, o múltiples ibd y frm archivos nombrados según el IMEI de los dispositivos.

No existe una forma convencional de cambiar la base de datos de file-by-file a buckets o viceversa, ya que esto implicaría reconstruir toda la base de datos. Una vez desplegada, la base de datos continúa existiendo en su estructura inicial.

Estructura por buckets

Este es un tipo contemporáneo de organización de la base de datos donde, para la optimización del rendimiento, los datos no se almacenan en tablas individuales por cada rastreador, sino en los llamados buckets. Por defecto hay 16 de ellos; los rastreadores se colocan en ellos de forma aleatoria. Cada rastreador tiene su propio storage_id, según el cual podemos encontrar el bucket requerido.

Para solicitar los datos, necesita el IMEI del rastreador (en este ejemplo usamos el IMEI ficticio 987654321012345), y el identificador interno del dispositivo llamado source_id.

Averigüe source_id y storage_id utilizando esta consulta:

SELECT storage_id, source_id FROM google.sources WHERE source_imei='987654321012345'; 

El resultado storage_id comienza con el número de bucket, de 1 a 16. Por ejemplo, storage_id=201000 significa bucket_2 y storage_id=1301000 significa bucket_13.

En la siguiente consulta necesitamos tanto el número de bucket como el source_id. Con esta consulta solicitamos los datos de seguimiento para el período requerido y los volcamos a un archivo CSV.

Tenga en cuenta:

• estamos usando el source_id y número de bucket encontrado con la consulta anterior.

• get_time es la hora de registro de los datos por el dispositivo; se especifica en UTC+0, independientemente de la zona horaria de la cuenta de usuario.

• MySQL debe tener permisos para escribir en la carpeta especificada en la consulta.

La propia consulta SQL es la siguiente:

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';

Para Windows la ruta es así:

INTO OUTFILE "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv"

Estructura por archivo

Esta es una forma más antigua de organizar la estructura de la base de datos, que sin embargo sigue siendo relevante para muchas instancias de Navixy con varios años de historia.

Para solicitar los datos en este caso, solo necesita el IMEI del rastreador (en este ejemplo usamos el IMEI ficticio 987654321012345).

Tenga en cuenta:

• get_time es la hora de registro de los datos por el dispositivo; se especifica en UTC+0, independientemente de la zona horaria de la cuenta de usuario.

• MySQL debe tener permisos para escribir en la carpeta especificada en la consulta.

La consulta SQL es la siguiente:

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';

Para Windows la ruta es así:

INTO OUTFILE "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv"

Exportación de datos

La consulta SQL anterior generará un archivo CSV que contiene todos los puntos de seguimiento registrados para el dispositivo.

Este archivo puede importarse en Excel o utilizarse en cualquier desarrollo interno.