Часові бази даних для оборонної телеметрії: запис, зберігання, запити

Сучасна бронемашина видає сотні показань сенсорів за секунду – оберти двигуна, тиск оливи, температура коробки передач, навантаження підвіски, витрата пального, напруга акумулятора, GPS-позиція та якість зв'язку на кожній прикріпленій до неї радіостанції. Парк із 200 машин виробляє десятки мільйонів точок даних за хвилину. Військовий корабель із повним моніторингом механізмів виробляє ще більше. Зберігати цю телеметрію в реляційній базі даних ніколи не було життєздатним у масштабі; шаблони запису, форми запитів і вимоги до зберігання докорінно відрізняються від транзакційних навантажень. Часові бази даних (TSDB) існують саме для розв'язання цієї проблеми, а інженерні рішення, ухвалені під час розгортання однієї з них – проєктування схеми, параметри пакетування, політика проріджування, кардинальність тегів – визначають, чи зможе система підтримувати операційний темп, чи завалиться під навантаженням за дні після розгортання. Ця стаття охоплює повний життєвий цикл: від запису сенсорної мережі через рівні зберігання до шаблонів запитів для оборонної аналітики.

Чому існують часові бази даних

Часова база даних – це механізм зберігання, створений спеціально для даних з інтенсивним додаванням та впорядкуванням за часовою міткою, де запити майже завжди передбачають часовий діапазон, а основна цінність даних полягає в їхньому часовому зв'язку – як метрика змінюється з часом, а не як окреме показання співвідноситься з іншою сутністю.

Основна технічна відмінність від реляційних баз даних – компонування сховища. TSDB використовують стовпцеве зберігання з автоматичним розбиттям за часом (званим шардами, чанками чи бакетами залежно від продукту). Усі показання для даної метрики в межах часового вікна зберігаються фізично суміжно на диску. Це означає, що запит агрегації за часовим діапазоном – «дай мені середню температуру двигуна для платформи P за останні 24 години» – читає суцільний блок диска, а не розкидані сторінки купи. На частоті 10 000 записів сенсорів за секунду TSDB може підтримувати це навантаження з затримкою запису в одиниці мілісекунд на серійному сховищі NVMe. Реляційна база даних насичила б свою підсистему вводу/виводу за тієї самої швидкості запису, бо кожне вставлення мусить оновлювати кілька індексів.

Стиснення – інша критична перевага. Показання сенсорів із рухомою комою із сусідніх часових міток часто майже ідентичні – температура змінюється на частки градуса між відліками. TSDB використовують дельта-кодування, XOR-стиснення (для подвійних чисел IEEE 754) та кодування довжин серій, щоб досягти коефіцієнтів стиснення 10:1 або кращих для типових потоків телеметрії. Сирий потік телеметрії, що зайняв би 1 ТБ у реляційній базі даних, зберігається в 80–120 ГБ у TSDB.

Проєктування схеми: вимірювання, теги та поля

Рішення щодо схеми, ухвалені перед першим записом, найважче скасувати. Погано спроєктований набір тегів спричиняє вибух кардинальності рядів – стан, за якого кількість окремих часових рядів у базі даних зростає необмежено, споживаючи пам'ять індексу та погіршуючи всі запити. Це найпоширеніший режим виробничого збою для розгортань TSDB, і його цілком можна уникнути за правильного проєктування.

Вимірювання

Вимірювання (зване в деяких продуктах родиною метрик) – це логічна група пов'язаних полів, які завжди записуються разом на одній часовій мітці. Розумні межі вимірювань для телеметрії оборонних платформ включають: engine_telemetry (оберти, тиск оливи, температура охолоджувача, швидкість витрати пального), nav_position (широта, довгота, висота, курс, швидкість відносно землі), power_systems (напруга акумулятора, вихід генератора, струм навантаження на шину) та radio_link_quality (сила сигналу, рівень шуму, частота помилок пакетів, кількість повторних передач). Поля в межах одного вимірювання спільно використовують часову мітку та зберігаються разом, тож групування за каденцією запису та операційною спорідненістю дає найефективніше компонування.

Теги проти полів

Теги – це індексовані метадані, що ідентифікують ряд. Кожна унікальна комбінація значень тегів створює окремий ряд в індексі. Поля – це числові значення, записані на кожній часовій мітці – вони не індексуються, а лише зберігаються. Правило проєктування таке: якщо вам потрібно фільтрувати чи групувати за виміром у предикаті запиту, він має бути тегом. Якщо вам потрібно лише прочитати значення, воно має бути полем.

Для телеметрії військових платформ доречні теги: platform_id (стабільний короткий ідентифікатор, наприклад «VH-041»), platform_type (наприклад «M1A2», «BTR-4», «Mi-8»), unit_id (ідентифікатор батальйону чи ескадрильї), sensor_class (наприклад «engine», «nav», «comms») та base чи grid_zone для грубого контексту розташування. Вони низької кардинальності: парк із 500 машин із 20 призначеннями підрозділів і 5 типами платформ виробляє щонайбільше 50 000 окремих рядів – цілком у комфортному робочому діапазоні будь-якої виробничої TSDB.

Що НЕ має бути тегами: сирі координати GPS, UUID подій, вільнотекстові коди несправностей чи будь-яке інше поле з кардинальністю, пропорційною кількості точок даних. Розміщення сирої широти як тега створює один новий ряд для кожної точки даних – індекс зростає без меж, а продуктивність запитів погіршується за години. Ідентифікатори високої кардинальності належать до полів чи до окремого реляційного сховища метаданих, що з'єднується з рядами TSDB за стабільними тегами низької кардинальності.

Високочастотний запис: пакетування, буферизація та записи у нерегулярному порядку

Оборонні сенсори – особливо на платформах машин чи БПЛА – не пишуть до TSDB напряму. Крайовий збирач працює на платформі чи на шлюзі, що агрегує дані з секції машини, буферизує показання локально та скидає пакети до TSDB через тактичну мережу. Архітектура запису має три параметри, що визначають, чи зможе вона поглинути сталі навантаження запису без втрати даних чи насичення мережі.

Розмір пакета. Запис однієї точки за раз дає один мережевий цикл на кожне показання сенсора – цілком неприйнятно на високих швидкостях. Розміри пакетів у 1 000–5 000 точок на запит зменшують мережеві накладні витрати на три порядки величини. Компроміс – затримка запису: з пакетом у 1 000 точок та сенсором на 100 Гц дані затримуються до 10 секунд перед скиданням пакета. Для операційного моніторингу, де затримка 10–30 секунд прийнятна, великі пакети оптимальні. Для майже реального оповіщення доречніші менші пакети з інтервалом скидання за часом (наприклад, скидати кожні 2 секунди незалежно від заповненості пакета).

Буферизація з випереджальним журналюванням. Тактичні радіоканали зазнають обривів. Коли зв'язок відсутній, крайовий збирач мусить буферизувати ненадіслані дані локально – на постійне сховище, а не лише в пам'ять, щоб дані пережили перезапуск процесу чи цикл живлення. Розмір буфера слід обчислювати з максимальної очікуваної тривалості обриву зв'язку, помноженої на пікову швидкість запису: 10-хвилинний обрив із потоком сенсора 5 000 точок за секунду потребує буферної ємності на 3 мільйони точок, приблизно 150 МБ за типової ширини полів із рухомою комою. Збирачі, що використовують лише буфери в пам'яті, втрачатимуть дані при кожному перериванні зв'язку.

Прийом записів у нерегулярному порядку. Коли буферизовані дані надходять після відновлення зв'язку, вони несуть часові мітки з минулого. TSDB значно різняться у своїй толерантності до записів у нерегулярному порядку: одні відхиляють записи з мітками, старшими за налаштовуване вікно; інші приймають будь-який історичний запис, але ціною продуктивності. Вікно прийому слід налаштувати відповідно до максимального очікуваного обриву зв'язку для типу платформи. Для платформ машин на тактичному радіо типово 300–600 секунд. Для платформ із супутниковою ретрансляцією, де обрив зв'язку під час прогалини проходу може тривати 90 хвилин, вікно має бути 5 400 секунд або більше.

Політики зберігання та проріджування

Сиру телеметрію в повній роздільності дорого зберігати довгостроково, і вона рідко потрібна поза коротким операційним вікном. Трирівнева політика зберігання покриває практично всі вимоги оборонної телеметрії без зайвих витрат на сховище.

Рівень 1 – Сирий. Дані повної роздільності (10–100 Гц залежно від типу сенсора) зберігаються 7–30 днів. Це вікно підтримує моніторинг у реальному часі, негайний аналіз після інциденту та перегляд порогових сповіщень. Для парку з 500 платформ із 50 сенсорами на платформу, що пишуть на 10 Гц, сховище повної роздільності споживає приблизно 2–4 ТБ на день за стисненого зберігання TSDB – керовано для 30-денного зберігання на серійному обладнанні NAS.

Рівень 2 – 1-хвилинні агрегати. Обчислюються безперервним запитом чи завданням проріджування: середнє, мінімум, максимум і кількість для кожного поля за кожне 1-хвилинне вікно. Зберігаються 6–12 місяців. Ця роздільність підтримує аналіз трендів, конструювання ознак для передбачувального обслуговування та виявлення аномалій у масштабі парку. Сховище в 1-хвилинній роздільності приблизно у 600× менше за сирий рівень.

Рівень 3 – погодинні агрегати. Зберігаються 3–7 років для довгострокового аналізу стану парку, планування життєвого циклу та перегляду програми забезпечення. У цій роздільності 7-річна історія для парку з 500 платформ займає значно менше за 100 ГБ – тривіально недорого відносно операційної цінності історичного запису.

Завдання проріджування мають плануватися з навмисним зміщенням від межі вікна. Завдання, заплановане на виконання точно на межі хвилини, часто читатиме неповне вікно – останні кілька секунд даних можуть ще не скинутися з конвеєра запису. Зміщення в 30 секунд гарантує, що вікно завершене перед агрегацією. Ця деталь усуває цілий клас тонких крайових артефактів, які з'являються як аномальні провали чи сплески через регулярні інтервали в проріджених даних.

Шаблони запитів для аналітики оборонної телеметрії

П'ять шаблонів запитів формують більшість операційного та аналітичного використання оборонної телеметричної TSDB. Виробниче розгортання має опрацьовувати усі п'ять із виключно індексованим виконанням – без повного сканування рядів – за обсягів даних, очікуваних після 6–12 місяців накопичення.

Запити останнього значення. «Яка поточна температура двигуна машини VH-041?» Це найчастіший запит в операційній інформаційній панелі моніторингу. TSDB, оптимізовані для цього шаблону, підтримують індекс останнього значення на кожен ряд, тож запит повертається за сталий час незалежно від того, скільки історичних даних існує. Без цієї оптимізації запити останнього значення вироджуються у зворотне за часом сканування сирого ряду – прийнятне за низької кардинальності, неприйнятне в масштабі парку.

Агрегації за часовим діапазоном. «Якою була середня швидкість споживання пального для всіх платформ M1A2 в Unit-7 за останні 72 години?» Це основний аналітичний запит: фільтр тегів, що вибирає відповідні ряди, сканування часового діапазону та функція агрегації, застосована як за виміром часу, так і за відфільтрованими рядами. Час виконання має вимірюватися десятками мілісекунд за обсягів даних 12 місяців для коректно індексованої схеми; сотні мілісекунд указують на проблему кардинальності.

Виявлення перетину порогу. «Коли температура оливи коробки передач на будь-якій машині парку вперше перевищила 120°C за останні 30 днів?» Цей запит потребує сканування часового діапазону з предикатом на значення поля. Деякі TSDB виконують це ефективно за допомогою стовпцевих метаданих min/max, що відсікають чанки без значень, що перевищують поріг; інші потребують повного сканування поля. Розуміння того, яку стратегію виконання використовує обраний продукт, критичне для визначення бюджетів затримки системи оповіщення.

Порівняння кількох рядів. «Покажи мені споживання пального для всіх машин типу BTR-4 за останній тиждень, згрупованих за підрозділом.» Це запит порівняння парку, який використовують планувальники обслуговування для виявлення платформ-винятків. Він потребує, щоб індекс тегів ефективно перелічив усі ряди, що відповідають фільтру platform_type, а потім агрегує кожен. Результат – один часовий ряд на підрозділ – невелика кількість вихідних рядів незалежно від розміру парку, якщо схема тегів коректна.

Похідні запити. «Яка швидкість зміни амплітуди вібрації на лівому двигуні VH-041 за останні 6 годин?» Швидкість зміни – основна ознака для виявлення механічних аномалій – раптове зростання похідної ряду вібрації чи температури часто передує відмові компонента на години чи дні. Це подається напряму у конвеєр черги повідомлень, що доставляє події аномалій до центру операцій з обслуговування. Більшість TSDB підтримують обчислення похідної як нативну функцію; ті, що не підтримують, потребують обчислення на рівні застосунку над результатом щільного запиту за часовим діапазоном, що життєздатно, але додає затримку.

Інтеграція з ширшою платформою даних

TSDB не працює ізольовано. У платформі оборонних даних вона є одним компонентом конвеєра, що також включає крайові збирачі, черги повідомлень для маршрутизації подій у реальному часі, озеро даних для довгострокового багатоформатного зберігання та фронтенди аналітики й моніторингу. Контракт інтеграції між TSDB та цими компонентами має бути визначений явно.

Для подальших споживачів, що потребують телеметрії майже в реальному часі – систем оповіщення, операційних інформаційних панелей, рушіїв злиття – рекомендований шаблон полягає в тому, щоб крайовий збирач публікував кожен пакет як до TSDB (для збереження та історичних запитів), так і до теми черги повідомлень (для маршрутизації подій з низькою затримкою до споживачів). Це відокремлює TSDB від шляху доставки в реальному часі: споживачі отримують події за секунди після захоплення сенсором, без опитування TSDB, а TSDB обслуговує лише історичні та агрегаційні запити, для яких оптимізовано її компонування сховища.

Для інтеграції з оборонним озером даних доречним джерелом є проріджені рівні TSDB: експортуйте 1-хвилинні агрегатні знімки як Parquet чи CSV за графіком та розміщуйте їх у зоні поглинання озера. Експорт сирих даних із TSDB до озера зайвий, якщо крайовий збирач уже пише сирі дані до обох призначень – але TSDB залишається авторитетним джерелом для запитів за часовим діапазоном над свіжими даними, бо її формат зберігання на порядки швидший для цього шаблону, ніж стовпцеві файли озера на основі об'єктного сховища.