Influxdata спонсировала этот пост.
Мы создали телеметрический трубопровод, который обрабатывает более 5400 точек данных в секунду с ответами на 10 миллисекунд. Методы, которые мы обнаружили при обработке данных симулятора полета со скоростью 60 кадров в секунду (кадры в секунду), применяются к любой высокочастотной системе телеметрии, от датчиков Интернета вещей (IoT) до мониторинга приложений.
Вот как мы получили наши запросы от 30 секунд до 10 мс, и почему эти методы работают для любой высокочастотной телеметрии.
Проблема с текущими значениями
Все пишут этот запрос, чтобы получить последнюю ценность телеметрии:
Выберите * из Flight_data, где время> = own () — интервал ‘1 минута’ порядок по времени DECS 1 123 SELECT * FREED_DATAWHERE TIME> = NOW () — интервал ‘1 минута на ограничение срока.
Это сканирует последние данные, сортирует все, затем выбрасывает все, кроме одного ряда. На высоких частотах этот паттерн полностью разрушается. Мы генерировали более 90 полей по 60 обновлениям в секунду от Microsoft Flight Simulator 2024 через FSUIPC, утилиту, которая служит посредником для связи между симулятором и внешними приложениями или управлением для оборудования. Наши панели мониторинга занимали 30 секунд или более, чтобы обновить.
Прекратите запросы, начните кэшировать
Influxdb 3 Enterprise, база данных временных рядов со встроенным уплотнением и функциями кэширования, предлагает что-то, что называется последним значением кэша (LVC). Вместо того, чтобы искать тысячи точек данных каждый раз, он сохраняет самое последнее значение для каждой метрики, готовой в памяти.
Вот как мы его настроили:
Выберите * из последнего_Каша (‘flight_data’, ‘flightsim_flight_data_lvc’) 1 select * from_cache (‘flight_data’, ‘fellysim_flight_data_lvc’)
Настройка:
Influxdb3 Создание последнего_Кэша \-database flightsim \-table flight_data \-aircraft aircraft_tailnumber \- Influxdb3 Создание последнего_Кэша \-database flightsim \-table flight_data \-aircraft_tailnumber \-value-columns, speed_true_airspeed, flight_heading_magnetic, flight_latitude, flight_longitude \-count 1 \—ttl 10s \ felly_latitud
Время запроса упало с 30+ секунд до менее 10 мс. Обновление мониторинга на 5 кадров в секунду и чувствуйте себя довольно мгновенно, если вы следят за пилотом на отдельном экране.
ВСЕХ ВСЕХ
Написание отдельных точек телеметрии на высокой частоте создает тысячи сетевых круглых поездок. Исправление довольно простое:
// Конфигурация пакетирования MaxBatchSize: 100 MaxBatchagems: 100 миллисекунд 123 // ConfigurationMaxBatchSize: 100MaxBatchagems: 100 миллисекунд
Буферные точки и промыть, когда вы нажимаете на любой предел. Это фиксирует около шести полных снимков телеметрии на одну базу данных.
Измеренная производительность:
- Задержка записи: 1,3 мс в строке.
- Устойчивые тысячи метрик в секунду.
- Нулевая потеря данных в течение 24-часовых тестов.
Агрессивное уплотнение
Высокочастотная телеметрия создает сотни небольших файлов. Мы настроили эти переменные среды в Enterprise Influxdb 3, чтобы использовать его функцию сплочения:
# Оптимизация уплотнения plupuxdb3_gen1_duration = 5m plupuxdb3_enterprise_compaction_gen2_duration = 5m plupuxdb3_enterprise_compaction_max_num_files_per_plan = 100 # в режиме реального времени доступа к данным plupuxdb3_wal_flush InfluxDB3_WAL_MAX_WRITE_BUFFER_SIZE = 200000 12345678 # Оптимизация COMPACTIONINFLUXDB3_GEN1_DURATION = 5MINFLUXDB3_ENTERPRISE_COMPACTION_GEN2_DURATION = 5MINFLUXDB3_ENTERPRISE_COMPACTION_MAX_NUM_FILES_PLAN = 100MINFLUXDB3_ENTERPRISE_COMPACTION_MAX_NUMERAN_PLUXDB3_ENTER AccessInfluxdb3_wal_flush_interval = 100msinfluxdb3_wal_max_write_buffer_size = 200000
Windows меньше времени (пять минут против 10 минут по умолчанию) и более частые уплотнения предотвращают накопление файлов, и это работало достаточно хорошо для нашего сценария.
24-часовые результаты:
- 142 События автоматического уплотнения.
- От 127 файлов до 18 оптимизированных файлов (паркета).
- Хранение от 500 МБ до 30 МБ (снижение 94%).
Блок чтения
Мы делали 90+ отдельных вызовов API через DLL FSUIPC для сбора телеметрии. На 60 кадров в секунду это более 5000 звонков в секунду. Накладные расходы были сокрушительными.
Решение: групповые метрики в блоки памяти.
_memoryblocks = новый словарь <строка, блокировка Memory Block> {// положение, отношение, высота {«FlightData», New MemoryBlock (0x0560, 48)}, {«Engine1», New MemoryBlock (0x088c, 64)}, {«Engine2», New MemoryBlock (0x0924, 64)}, / / / / / controlm «Controls», New MemoryBlock (0x0bc0, 44)}, {«Autopilot», New MemoryBlock (0x07bc, 96)}}; 12345678910 _memoryBlocks = new Dictionary
Каждый блок получает несколько связанных параметров в одной операции.
Воздействие нанесло от 2700 до 5400 звонков/секунду до 240 до 480 звонков/секунды (90%+ сокращение).
Отделение в реальном времени от исторических запросов
Мы построили два различных режима:
- В реальном времени (с использованием кэша последнего значения): Только текущие значения, ответ на 10 мс.
- Исторический (традиционный SQL): Тенденции и анализ, приемлемые, чтобы быть медленным чтением.
Это разделение кажется очевидным в ретроспективе, но большинство систем мониторинга пытаются удовлетворить обе потребности с одинаковыми моделями запросов.
Шаблоны и практики для приборной панели в реальном времени
Это не экзотические методы. Независимо от того, отслеживаете ли вы производственное оборудование, отслеживаете метрики приложений или переработку рыночных данных рынка, шаблоны одинаковы:
Результаты
Эти методы работают в любом месте, где вы имеете дело с высокочастотными данными:
- Датчики IoT: Производственное оборудование, умные здания, мониторинг окружающей среды.
- Метрики приложения: Данные мониторинга производительности приложения (APM), микросервисная телеметрия, распределенная трассировка.
- Финансовые данные: Рыночные каналы, торговые системы, мониторинг рисков.
- Игры: Телеметрия игрока, метрики сервера, мониторинг производительности
После реализации этих шаблонов:
- Время запроса: 30 секунд вплоть до 10 мс.
- Хранение: снижение на 94%.
- Вызовы API: на 90% меньше.
- Опыт работы на панели управления: на самом деле в реальном времени (ну, настолько близко, насколько мы могли бы получить!).
Разница не о более быстрого оборудования, это связано с использованием правильных шаблонов для высокочастотных данных. Я надеюсь, что вы попробуете эти методы!
Код
Полная реализация на GitHub:
- C# мост данных: msfs2influxdb3-enterprise
- Next.js Dashboard: Flightsim2024-influxdb3enterprise
Независимо от того, создаете ли вы симуляторы полета или системы мониторинга производства, мы обнаружили, что эти модели были интересны, чтобы обнаружить на пути к обработке данных в реальном времени.
InfluxData является создателем PlupuxDB, ведущей платформы временных рядов. Более 1900 клиентов используют InfluxDB для сбора, хранения и анализа данных всех временных рядов в любом масштабе. Разработчики могут запрашивать и анализировать свои данные с временем, чтобы предсказать, реагировать и адаптироваться в режиме реального времени. Узнайте больше новейших из InfluxData Trending Stories YouTube.com/ThenewStack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Хизер Даунинг-старший разработчик, защищающий InfluxData, страстно страстно рассказывающую о данных, которые рассказывают об убедительных историях с помощью инструментов для разработчиков. Она принимает сложные проблемы с данными и переводит их в доступные решения, которые помогают разработчикам создавать значимые приложения с правой … Подробнее от Heather Downing
