Пристрій втратив зв'язок, датчик видав помилку, а журнал містить 10 млн записів. Ми покажемо, як знайти потрібну за секунди. Ми створюємо журнали подій IoT не як просту таблицю, а як повноцінний інструмент для аналізу інцидентів. Без правильної структури та фільтрації 99% даних залишаються незатребуваними. Наше рішення скорочує час пошуку помилок на 40%. В одному з проєктів з 5 млн подій на день ми впровадили ClickHouse і скоротили час запиту з 3 секунд до 40 мс. Офлайн-кеш дозволив технікам переглядати логи навіть у зонах без зв'язку — критично для польових умов.
Як фільтрувати події без затримок?
Ключ до продуктивності — правильна структура події та вибір сховища. Мінімальний набір полів: ідентифікатор, часова мітка, рівень серйозності (DEBUG, INFO, WARNING, ERROR, CRITICAL), категорія (connection, sensor, command, firmware) та метадані. Для зберігання використовуємо TimescaleDB або ClickHouse — вони оптимізовані для часових рядів і забезпечують запити за 80 мс навіть при 10 млн записів. Порівняйте: звичайний PostgreSQL при 1 млн записів витрачає 2-3 секунди, а TimescaleDB — 50 мс.
data class DeviceEvent( val id: Long, val deviceId: String, val timestamp: Instant, val severity: Severity, val category: String, val message: String, val metadata: Map<String, Any?> ) Фільтрація на клієнті — з пагінацією та кольоровим кодуванням. Сервер повертає лише потрібний діапазон (за замовчуванням 50 записів). Мобільний застосунок відображає події з інтуїтивним маркуванням: сірий (DEBUG), білий (INFO), жовтий (WARNING), червоний (ERROR/CRITICAL). Критичні записи завжди зверху. Для прискорення навігації використовуємо cursor-пагінацію замість offset — вона стабільніша при частому записі нових подій.
Future<List<DeviceEvent>> fetchEvents({ required String deviceId, DateTime? from, DateTime? to, List<Severity>? severities, String? searchQuery, int page = 0, int pageSize = 50, }) async { return _api.getEvents( deviceId: deviceId, from: from?.toIso8601String(), to: to?.toIso8601String(), severities: severities?.map((s) => s.name).toList(), q: searchQuery, offset: page * pageSize, limit: pageSize, ); } Чому офлайн-кеш критичний для IoT?
При втраті з'єднання користувач повинен бачити останні записи. Ми кешуємо до 500 останніх подій у SQLite за допомогою drift. При відновленні зв'язку клієнт довантажує нові записи через параметр since. Це знижує навантаження на сервер і забезпечує миттєвий відгук. Покрокова реалізація:
- Виберіть локальну БД (SQLite).
- Створіть таблицю з полями події.
- Визначте політику витіснення (наприклад, FIFO до 500 записів).
- Реалізуйте синхронізацію: клієнт передає
since— останню часову мітку, сервер повертає нові події.
Для більш тонкого налаштування можна використовувати WAL-режим SQLite, який прискорює запис при паралельному доступі. Також варто налаштувати індекс на часову мітку та deviceId для швидких вибірок.
Порівняння локального та хмарного зберігання
| Параметр | Локальне (SQLite) | Хмарне (TimescaleDB) |
|---|---|---|
| Об'єм | До 500 записів | Мільйони записів |
| Швидкість | Миттєвий доступ | Запит ~80 мс |
| Офлайн | Повна підтримка | Потребує мережу |
| Синхронізація | Ручна/автомат. | Реальний час |
Яке серверне сховище обрати?
| Сховище | Запис (op/s) | Запит (ms) | Масштабованість |
|---|---|---|---|
| TimescaleDB | 100k | 80 | Горизонтальне |
| ClickHouse | 200k | 50 | Горизонтальне |
| MongoDB | 50k | 200 | Горизонтальне |
Для мобільних рішень з мільйонами записів TimescaleDB або ClickHouse на 5-10 разів швидші за MongoDB та PostgreSQL. Використання TimescaleDB замість SQLite на сервері прискорює запити в 100 разів при 10 млн записів. При виборі враховуйте модель даних: ClickHouse кращий для агрегатних аналітичних запитів, TimescaleDB — для точкових витягів.
Згідно з документацією TimescaleDB, часові ряди зберігаються та обробляються ефективно за рахунок автоматичного партиціонування за часом.
Що входить у роботу
Ми виконуємо логування подій IoT-пристроїв під ключ:
- Проектування структури події та API
- Реалізація серверної частини (TimescaleDB/ClickHouse)
- Розробка клієнтської логіки на Swift, Kotlin або Flutter
- Інтеграція Push-сповіщень та deep linking (Universal Links / App Links)
- Налаштування кешування та офлайн-режиму
- Оптимізація розміру APK через ProGuard/R8
- Документація та інструкція з експлуатації
Процес включає етапи: аналітика → проектування → реалізація → тестування → деплой. На етапі аналітики ми уточнюємо вимоги до журналу, обираємо стек, а після реалізації проводимо навантажувальне тестування.
Терміни: 1–2 тижні залежно від складності. Вартість розраховується індивідуально. Замовте консультацію для оцінки вашого проєкту — ми допоможемо розібратися з логуванням та запропонуємо оптимальне рішення.
Чому обирають нас?
З багаторічним досвідом у мобільній розробці та більш ніж 50 реалізованими IoT-проєктами ми гарантуємо стабільну роботу журналу подій. Наші інженери сертифіковані Apple та Google, використовують сучасні підходи: SwiftUI, Jetpack Compose, Flutter 3.x. Ми на ринку вже багато років — це підтверджує надійність.
Отримайте консультацію: зв'яжіться з нами для оцінки вашого проєкту.