Home Assistant поставляется с SQLite, и это нормально на неделю. Потом графики на панели управления начинают отставать, панель истории открывается десять секунд, а база данных recorder растёт на несколько гигабайт, потому что датчики Zigbee пишут каждые 30 секунд. Смена бэкенда recorder это исправляет. Мы протестировали шесть баз данных на одном экземпляре (примерно 140 сущностей, хранение 30 дней), чтобы понять, какая действительно сделает умный дом снова отзывчивым.
Эта подборка для тех, чей Home Assistant вырос из базы данных по умолчанию. Docker или голое железо, мы рассказываем о компромиссах каждого бэкенда, что ломается при миграции, и какой выбрать, если вы также хотите долгосрочные дашборды Grafana.
На что обратить внимание при выборе бэкенда Home Assistant recorder
Несколько вещей имеют значение больше, чем сырые бенчмарки:
- Задержку на панелях истории и журнала, когда БД превышает 5 ГБ
- Как хорошо бэкенд обрабатывает паттерн записи Home Assistant (много небольших вставок, иногда большие запросы)
- Можете ли вы запрашивать его прямо из Grafana или Node-RED, не перегружая recorder
- Контроль хранения и понижения разрешения, потому что хранить полное разрешение навсегда — это растрата
- История резервного копирования, особенно если вы запускаете всё на SSD, который хотите сохранить
- Путь миграции из SQLite (вы сохраняете историю?)
Быстрое сравнение
| Backend | Лучше всего для | Лицензия | Модель хранения | Работает на |
|---|---|---|---|---|
| PostgreSQL | Большинства установок | PostgreSQL | Row-store, ACID | Linux, Windows, macOS |
| MariaDB | Прямая замена | GPL | Row-store, ACID | Linux, Windows, macOS |
| TimescaleDB | Долгосрочная история датчиков | Apache 2.0 / TSL | Hypertables поверх Postgres | Linux, Docker |
| InfluxDB 2.x | Дашборды, понижение разрешения | MIT (core) | Time-series columnar | Linux, Windows, macOS |
| MySQL | Существующая инфраструктура MySQL | GPL | Row-store, ACID | Linux, Windows, macOS |
| VictoriaMetrics | Метрики в масштабе | Apache 2.0 | Time-series columnar | Linux, Windows, macOS |
Бэкенды
1. PostgreSQL, лучшая общая замена для recorder
PostgreSQL — это выбор, если вы не уверены. Home Assistant нативно поддерживает интеграцию с ним, драйвер psycopg2 стабилен, и планирование запросов держится, когда база растёт больше 10 ГБ. Панель истории, которая занимала восемь секунд на SQLite, падает ниже одной секунды на скромной четырёхъядерной машине, как только прогреются индексы. Добавьте сжатие TOAST на таблицы states и events, и использование диска останется разумным.
Где это не работает: нужно запускать и делать резервное копирование настоящей базы данных. Это означает cron pg_dump, архив WAL, если вас интересует восстановление до точного момента времени, и план на случай переполнения диска. Ничего экзотического, но это больше работы, чем один файл .db.
Цена: Бесплатно, открытый исходный код под лицензией PostgreSQL. Нет платного уровня.
Платформы: Linux, Windows, macOS, Docker и любой NAS с пакетом Postgres.
Скачать: postgresql.org
Вывод: Выбирайте PostgreSQL сначала и смотрите в другие стороны, только если у вас есть конкретная причина.
2. MariaDB, форк, который большинство руководств предполагают
MariaDB — это бэкенд, который документация Home Assistant использует по умолчанию в примере, и это остаётся твёрдым выбором для тех, кто уже его запускает. Настройка задокументирована вплоть до точного блока recorder: YAML, и в Home Assistant OS есть добавка MariaDB, которая управляет установкой для вас. Производительность находится в том же диапазоне, что и Postgres для нагрузки recorder.
Где это не работает: миграции схемы при интенсивной нагрузке записи иногда блокируют таблицу states достаточно долго, чтобы recorder регистрировал предупреждения об обратном давлении. Ничего катастрофического, но вы это видите. Инструменты MySQL также кажутся старше, чем экосистема Postgres.
Цена: Бесплатно, открытый исходный код под лицензией GPLv2.
Платформы: Linux, Windows, macOS, Docker, встроенная добавка HAOS.
Скачать: mariadb.org
Вывод: Самый безопасный выбор, если вы хотите поддерживаемый, задокументированный путь с наименьшим количеством неожиданностей.
3. TimescaleDB, Postgres настроенный для истории датчиков
TimescaleDB работает как расширение PostgreSQL и превращает таблицы временных рядов в гипертаблицы, которые автоматически разбиваются по времени. Для умного дома, записывающего тысячи изменений состояния в день, это означает, что вы можете хранить год данных и всё ещё получить запросы меньше секунды. Непрерывные агрегаты позволяют предварительно вычислять ежедневные средние значения, чтобы панели Grafana не сканировали необработанные строки.
Где это не работает: нужно маршрутизировать recorder Home Assistant через Postgres нормально, потом преобразовать таблицы в гипертаблицы с помощью команды SQL. Не сложно, но это не галочка. Лицензия Timescale (TSL) на некоторые корпоративные функции не полностью открыта, но издание сообщества охватывает всё, что нужно для recorder.
Цена: Бесплатно издание сообщества; платная Timescale Cloud начинается примерно с $30/месяц для хостированных экземпляров.
Платформы: Linux, Docker, Timescale Cloud. Нет нативных пакетов Windows или macOS, хотя WSL работает.
Скачать: timescale.com
Вывод: Лучшая история долгосрочного хранения из шести, если вы готовы запускать расширение поверх Postgres.
4. InfluxDB 2.x, дашборды больше, чем recorder
InfluxDB — это не совсем замена recorder, это классическое сочетание, которое живёт рядом с Home Assistant. Интеграция influxdb передаёт изменения состояния в InfluxDB параллельно с любым SQL-бэкендом, который использует recorder, а Grafana вытягивает из Influx для красивых дашбордов. Запросы Flux позволяют вам понизить разрешение без cronjob.
Где это не работает: язык запросов Influx изменился между 1.x, 2.x и 3.x, так что половина найденных вами руководств устарела. И поскольку это не заменяет recorder, вы запускаете две базы данных вместо одной.
Цена: Бесплатно InfluxDB 2.x OSS; InfluxDB Cloud имеет бесплатный уровень и оплату по мере использования выше него.
Платформы: Linux, Windows, macOS, Docker, добавка HAOS.
Скачать: influxdata.com
Вывод: Используйте его рядом с SQL-recorder, когда вы хотите серьёзные дашборды Grafana, не как замена recorder.
5. MySQL, только если вы уже его запускаете
MySQL работает с Home Assistant, и если вы уже имеете сервер MySQL, гудящий для другого сервиса, добавление базы данных recorder к нему является простым. Драйвер mysqlclient хорошо изношен, и recorder не давит его сильно.
Где это не работает: MariaDB — это форк прямой замены, на который большинство руководств Home Assistant направлены напрямую, так что вы заканчиваете переводом инструкций. Лицензирование Oracle вокруг MySQL Enterprise добавляет морщину, если вы когда-либо хотели платной поддержки.
Цена: Бесплатно MySQL Community Edition; платные корпоративные уровни начинаются примерно с $2000/год.
Платформы: Linux, Windows, macOS, Docker.
Скачать: mysql.com
Вывод: Выбирайте это только если вы уже имеете экземпляр MySQL, который хотите переиспользовать.
6. VictoriaMetrics, когда recorder — узкое место
VictoriaMetrics сияет, когда у вас сотни сущностей и сам recorder становится медленной частью. Он поглощает через совместимую с Prometheus конечную точку, поэтому интеграция prometheus Home Assistant питает его напрямую. Хранилище примерно в 10 раз более компактно, чем InfluxDB для одних и тех же данных.
Где это не работает: это только метрики. Вы не получаете историю состояния так же, как recorder вам даёт, поэтому встроенная панель истории все ещё нуждается в SQL-бэкенде. Это дополнение, а не замена.
Цена: Бесплатно открытый исходный код; VictoriaMetrics Enterprise для больших развёртываний имеет индивидуальное ценообразование.
Платформы: Linux, Windows, macOS, Docker.
Скачать: victoriametrics.com
Вывод: Хранилище метрик, которое нужно использовать, когда ваши экспорты Prometheus становятся объёмными и Influx начинает ощущаться тяжёлым.
Как выбрать правильный
Если вы просто хотите, чтобы ваш дашборд работал быстро: PostgreSQL и прекратите читать здесь.
Если вы тщательно следуете руководствам и хотите задокументированный путь: MariaDB.
Если вы планируете хранить годы истории датчиков и запрашивать её позже: TimescaleDB поверх PostgreSQL.
Если ваша цель действительно красивые дашборды Grafana с понижением разрешения: держите recorder на Postgres или MariaDB и добавьте InfluxDB для слоя метрик.
Если ваша установка Home Assistant действительно огромна (500+ сущностей, миллионы+ изменений состояния в день): соедините PostgreSQL как recorder с VictoriaMetrics для метрик в стиле Prometheus.
Пропустите MySQL, если вы не запускаете его уже для чего-то другого.
Часто задаваемые вопросы
PostgreSQL быстрее SQLite для Home Assistant?
Да, как только ваша база превышает несколько гигабайт. На небольших установках SQLite сопоставим, но панели истории и журнала ощутимо быстрее на PostgreSQL, когда данные растут, потому что планирование запросов и параллельные чтения масштабируются лучше.
Могу ли я перенести историю SQLite в PostgreSQL без потери данных?
Да, используя pgloader или ручной dump/restore, но это непросто. Большинство пользователей начинают с нуля на новом бэкенде и принимают потерю старой истории, а не борются с преобразованием схемы.
Home Assistant поддерживает InfluxDB как замену recorder?
Нет. InfluxDB работает рядом с recorder через интеграцию influxdb, передавая изменения состояния параллельно. Сам recorder всё ещё нуждается в SQLite, PostgreSQL, MariaDB или MySQL.
Какой лучший бэкенд для долгосрочной истории Home Assistant?
TimescaleDB. Непрерывные агрегаты и разбиение по времени позволяют вам хранить год или больше данных и всё ещё получать быстрые запросы. VictoriaMetrics близко, если вас интересуют только числовые метрики.
Изменение бэкенда recorder сломает мои автоматизации?
Нет. Автоматизации читают из машины состояния Home Assistant, а не базы данных recorder. Смена бэкенда влияет на историю, статистику и долгосрочное хранение, а не на актуальное состояние.