> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/on-premise/ru/on-premise/how-to-guide/troubleshooting/tracking-data-export.md).

# Экспорт данных отслеживания

По мере работы трекеров их данные отправляются и сохраняются в базе данных платформы Navixy, поэтому вы можете просматривать поездки в мониторинге и формировать отчёты о поездках. Однако могут возникнуть ситуации, когда необходимо выгрузить всю записанную информацию трекинга в виде геолокационных точек. Это обычно требуется для анализа данных в спорных случаях. В таком случае вы можете запросить такую информацию напрямую из базы данных.

{% hint style="info" %}
Этот метод позволяет получить данные более детально и «технически», чем вы видите в мониторинге. Но важно понимать, что для появления в базе данных данные должны фактически быть переданы трекером, и восстановить полностью отсутствующие в мониторинге поездки таким образом не получится.
{% endhint %}

Вам потребуется **прямой доступ к базе данных MySQL** чтобы вытащить данные трекинга, а это означает, что ваши клиенты не имеют прав на эту операцию, и только техники с доступом к серверу обладают необходимой авторизацией.

Данные трекинга хранятся в ***tracking*** базе данных. В зависимости от того, когда и как была развёрнута ваша инстанция платформы, возможны два принципиально разных способа организации структуры базы данных.

* **Структура с bucket'ами**. В этом случае данные трекинга разбиваются на несколько bucket'ов (по умолчанию 16).
* **Файловая структура**, где каждому трекеру соответствует отдельная таблица, названная по его IMEI.

Тип организации данных, который вы используете, легко проверить, просто открыв директорию хранения файлов базы данных — например, в Linux это по умолчанию `/var/lib/mysql/tracking` . Внутри вы найдёте либо разбиенные файлы с именами вида `bucket_****.ibd`, либо множество `ibd` и `frm` файлов, названных по IMEI устройств.

{% hint style="danger" %}
Нет обычного способа изменить базу данных с файловой структуры на структуру с bucket'ами или наоборот, так как это потребовало бы перестроения всей базы. После развёртывания база продолжает существовать в своей исходной структуре.
{% endhint %}

## Структура с bucket'ами

Это современный тип организации базы данных, где для оптимизации производительности данные хранятся не в отдельных таблицах для каждого трекера, а в так называемых bucket'ах. По умолчанию их 16, трекеры распределяются по ним случайным образом. У каждого трекера есть свой `storage_id`, по которому мы можем найти нужный bucket.

Для запроса данных вам нужен IMEI трекера (в этом примере мы используем условный IMEI 987654321012345) и внутренний идентификатор устройства, называемый `source_id`.

Узнайте `source_id` и `storage_id` с помощью этого запроса:

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

Получившийся `storage_id` начинается с номера bucket'а — от 1 до 16. Например, *storage\_id=**2**01000* означает *bucket\_**2*** и *storage\_id=**13**01000* означает *bucket\_**13***.

В следующем запросе нам понадобятся и номер bucket'а, и source\_id. Этим запросом мы запрашиваем данные трекинга за нужный период и выгружаем их в CSV-файл.

Обратите внимание:

* мы используем `source_id` и `bucket` номер которого был найден предыдущим запросом.
* `get_time` — это время записи данных устройством, оно указано в UTC+0, независимо от часового пояса учётной записи пользователя.
* У MySQL должны быть права на запись в папку, указанную в запросе.

Сам SQL-запрос выглядит следующим образом:

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

Для Windows путь выглядит примерно так:

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

## Файловая структура

Это более старый способ организации структуры базы данных, который тем не менее остаётся актуальным для многих инстанций Navixy с многолетней историей.

Чтобы запросить данные в этом случае, вам нужен только IMEI трекера (в этом примере мы используем условный IMEI 987654321012345).

Обратите внимание:

* `get_time` — это время записи данных устройством, оно указано в UTC+0, независимо от часового пояса учётной записи пользователя.
* У MySQL должны быть права на запись в папку, указанную в запросе.

SQL-запрос выглядит следующим образом:

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

Для Windows путь выглядит примерно так:

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

## Вывод данных

Указанный выше SQL-запрос сгенерирует CSV-файл, содержащий все точки трекинга, записанные для устройства.

Этот файл можно импортировать в Excel или использовать в любой внутренней разработке.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://navixy.com/docs/on-premise/ru/on-premise/how-to-guide/troubleshooting/tracking-data-export.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.