Выбор historian в 2026 году редко сводится к «какая база быстрее пишет точку». На весах лежат модель данных, привычный инструментарий команды, интеграции с полем и SCADA, путь от сырых тегов до отчёта для директора и полная стоимость владения - лицензии, железо, люди, простои при апгрейдах.
Ниже - сравнение трёх частых кандидатов в промышленных проектах: PI System (линейка, исторически OSIsoft; развитие и поддержка сейчас в экосистеме AVEVA), InfluxDB и TimescaleDB. Без религии и без обещания «одно решит всё».
Короткий ответ
PI System остаётся ориентиром там, где нужны зрелая дисциплина тегов и активов на масштабе предприятия, богатые OT-интеграции и предсказуемая модель для эксплуатации - цена за это обычно выше, но зато меньше сюрпризов при росте числа источников.
InfluxDB выигрывает как ядро временных рядов в современных стеках наблюдаемости и на edge/облаке, когда команде важны скорость внедрения и API-first подход.
TimescaleDB - сильный выбор, когда вы хотите SQL и временные ряды в одной БД на базе PostgreSQL: отчёты, связки с учётными таблицами, знакомый инструментарий для аналитиков.
Модель данных: теги, активы и таблицы
PI System исторически вырос вокруг PI Points и архива событий; в зрелых внедрениях ключевую роль играет Asset Framework (AF) - иерархия оборудования, шаблоны, атрибуты, нормализация именования. Это лечит хаос «тысячи тегов без структуры», если команда реально ведёт AF, а не делает вид.
InfluxDB опирается на measurements, tags, fields - модель хорошо ложится на потоки телеметрии и метрик. Гибко для IIoT, но без дисциплины легко получить взрыв кардинальности (слишком много уникальных комбинаций тегов), после которого и запись, и запросы становятся дорогими.
TimescaleDB представляет временные ряды как гипертаблицы поверх PostgreSQL: обычные столбцы, индексы, JOIN с бизнес-таблицами. Это упрощает сценарии «событие партии + тренды датчиков + справочники SKU» в одном SQL.
Масштаб и нагрузка
PI рассчитан на многолетнюю эксплуатацию крупных установок с высокой плотностью источников и типичными OT-паттернами буферизации и репликации между уровнями (концепции зависят от редакции и архитектуры заказчика).
InfluxDB хорошо масштабируется в модели высокой скорости записи и горизонтального разнесения в облачных и контейнерных инсталляциях - при условии что архитектура записи и retention продуманы заранее.
TimescaleDB масштабируется вместе с практиками PostgreSQL: партиционирование, репликация, отдельные ноды для чтения. Потолок упирается не столько в «движок рядов», сколько в дизайн таблиц и индексов и в культуру SQL.
Запросы: что инженер делает каждый день
PI предлагает привычный для OT инструментарий (в том числе клиентские приложения и отчётность на базе данных событий и атрибутов AF). Для многих производств это плюс: меньше самописной логики «как достать значение в момент времени».
InfluxDB силён запросами к временным рядам и интеграцией с Grafana, но сложные аналитические сценарии с множеством связей иногда приходится выносить во внешние сервисы.
TimescaleDB даёт полный SQL: оконные функции, представления, смешение операционных и исторических данных. Это снижает трение между OT и IT-аналитикой, если последняя уже живёт в Postgres.
Интеграции с OT
PI традиционно глубоко интегрирован с промышленным ландшафтом через экосистему интерфейсов и коннекторов к SCADA/DCS, OPC и типовым источникам - это главный аргумент «мы хотим промышленный historian, а не базу данных с адаптером своими руками».
InfluxDB обычно приходит в связке с Telegraf и кастомными писателями - гибко, но ответственность за качество данных и очереди лежит на интеграторе.
TimescaleDB не является historian из коробки в OT-смысле: нужны коннекторы (OPC UA, MQTT, партиции из SCADA) и слой метаданных. Зато дальнейшая аналитика часто проще.
Стоимость владения: что входит в TCO
У PI заметная доля стоимости - лицензирование и сопровождение экосистемы, плюс экспертиза в AF и правилах архива. Зато вы платите за зрелость типовых паттернов эксплуатации.
У InfluxDB важны модель лицензии выбранной редакции, инфраструктура (облако или своё железо), резервирование и стоимость хранения при агрессивном объёме точек.
У TimescaleDB часто выигрывает опора на PostgreSQL - проще найти DBA, проще встроить в существующий контур. Но нужно заложить работы по конвейеру данных из OT и мониторингу БД.
Сильные стороны и антипаттерны
PI System - Сильные стороны: OT-типовые сценарии, AF, зрелый жизненный цикл в промышленности. - Антипаттерн: развернули без модели активов - получили «дорогой архив тегов без смысла».
InfluxDB - Сильные стороны: скорость старта, экосистема observability, хорош для потоковых данных. - Антипаттерн: записывают всё подряд с высокой кардинальностью - база «течёт» по ресурсам.
TimescaleDB - Сильные стороны: SQL, связка временных рядов и учётных данных, переносимость навыков. - Антипаттерн: «одна таблица на всё» без политики сжатия и партиций - деградация на больших объёмах.
Матрица выбора: сценарий - historian - почему
Где уместен СТАБУР
В проектах на базе СТАБУР верхний уровень историзации часто строится совместно с интеграцией SCADA и MES: важно не только «какая БД», но и кто владеет моделью тегов, как проходят резервные копии и как изменения проходят через MOC. Выбор PI, Influx или Timescale должен совпадать с этой дисциплиной, а не заменять её.
Заключение
PI System, InfluxDB и TimescaleDB закрывают разные компромиссы.
PI - про промышленную зрелость и модель активов на масштабе.
InfluxDB - про скорость и потоки временных рядов в современном стеке.
TimescaleDB - про SQL и связку процессных данных с корпоративной аналитикой.
Правильный ответ почти всегда начинается с вопроса: кто будет владеть данными через пять лет и какими инструментами команда реально пользуется каждый день.
FAQ
Нужно ли мигрировать с PI на open source ради экономии?
Не обязательно. Миграция стоит дороже лицензий, если у вас глубоко ушли в AF и отчётность. Оценивайте не цену софта, а цену переезда.
InfluxDB и TimescaleDB - можно ли вместе?
Да, как разные домены: например, высокочастотные потоки в Influx, финансово-производственная аналитика в Postgres/Timescale - если есть ясная граница и синхронизация метаданных.
Что с высокой доступностью?
У всех трёх есть паттерны HA, но реализация разная: кластеры Postgres, репликации PI-архитектуры, Influx с отказоустойчивым разнесением. Это отдельный проектный блок.
Как избежать «историк есть, а данных нельзя доверять»?
Единая политика времени (NTP/PTP), журналирование качества, контроль пропусков и документированные источники.
Обязательно ли OPC UA напрямую в базу?
Не всегда. Часто разумнее буфер на шлюзе или через SCADA historian API - меньше связности и проще обслуживание.