Какую базу данных выбрать для Home Assistant

Оригинал поста на хабре

Введение

На случай, если ещё не встречались с HA (Home Assistant) - это opensource веб сервис для умного дома, доступный как на облаке, так и в виде self hosted, который позволяет подключить к себе кучу всяких устройств и настроить для них любые желаемые автоматизации. Например, открывать ворота при вашем приближении, заваривать кофе, когда ваш умный браслет понял, что вы проснулись, или автоматически кормить кошку по праздничным дням календаря.

Сегодня мы поговорим о том, какую СУБД (Систему Управления Базы Данными) для него лучше выбрать. Потому что очень часто в чат по HA приходят новички, и спрашивают, что им делать с MySQL, а им в ответ говорят, что они наркоманы и нанюхались одного известного видео с ютуба. А почему такая реакция, и что делать - начинающему автоматизатору понять довольно сложно без довольно специфического багажа знаний в айти. Так что надеюсь, что эта статья кому-то поможет.

Итак, Home Assistant написан с использованием SQLAlchemy - грубо говоря, это библиотека, которая в теории позволяет приложению использовать любую СУБД. Все возможные на свете варианты мы рассматривать не будем и ограничимся тремя вариантами - MariaDB, PostgreSQL, и вариант, который идёт в HA по умолчанию - SQLite. MySQL отдельно упоминать не буду т.к. различия с MariaDB до сих пор не такие значительные.

Частые аргументы

В статьях и видео, которые рекомендуют установку MariaDB/MySQL, в лучшем случае говорится, что она быстрее, чем SQLite. На этом сравнение заканчивается, и мы бодро идём ставить MariaDB. Но… Так ли это?

Если мы посмотрим бенчмарки на чтение данных, то совершенно внезапно оказывается… Что SQLite как минимум не медленнее, чем остальные два наших конкурента. В теории, он может оказаться медленнее на больших наборах данных, однако сколько данных - много? На практике оказывается, что много - это порядок десятков гигабайтов. А теперь посмотрите на свой размер базы. Моя, при условии большого количества устройств и истории, весит не более 200 MB…

Ну ладно, наверное не просто так люди MariaDB ставят. Видимо, есть какие-то ещё преимущества.

Хмм, может, то, что SQLite не очень хорошо работает с параллельными процессами записи?

Неа. Довольно сложно представить себе умный дом с настолько частыми операциями записи. Кроме того, бутылочным горлышком фактически будет ваш HA, который написан на питоне, который обычно использует довольно мало потоков. Более того, используется SQLAlchemy, который в целом умеет в многопоточность, но только если вы специально писали код с расчётом на неё. Как вы думаете, занимались ли этим разработчики HA? Честно скажу - свечку не держал - но навряд ли.

Ну, ладно. Может быть, другие решения надёжнее, чем SQLite, и ваша база упадёт с меньшей вероятность?

Ммм. Ну ваще нет. Нужно очень сильно постараться, чтобы запороть SQLite базу. Она разработана как раз с рассчётом на внезапное падение программы, ОС или выключение устройства. Между прочим, SQLite точно используется сейчас в вашем телефоне на андроиде - представляете, что она там пережила?

В то время как MariaDB и PostgreSQL в конфигурации по умолчанию имеют довольно неплохие шансы накрыться при некорректном завершении работы - например, при выключении сервера кнопкой или отключении электричества.

Хорошо. Ну может хотя бы с бекапами будет всё лучше?

Боюсь расстроить, но тут тоже подстава. Для бекапа SQLite достаточно на горячую (при запущенном HA) скопировать файлик базы. А вот если вы скопируете файлы PostgreSQL или MySQL на горячую, то они у вас просто не заведутся. И нужно или останавливать СУБД или пользоваться специальными инструментами экспорта…

Если вам этого мало

Помимо этого, есть ещё не очевидные плюшки:

  1. Установка с видео выглядит легко и просто для пустого HA. Если у вас уже есть данные, то всё становится гораздо интереснее!
  2. Обратная миграция на SQLite будет далеко не простой. Если, конечно, вы хотите сохранить данные базы. Если нет - просто снесите recorder.db_url и выключите эддоны, если они были включены - и после перезапуска жизнь начнётся с нового листа с записью в SQLite.
  3. Разработчики HA тестируют новые релизы на SQLite. И если у вас вдруг что-то сломается, то вам посочувствуют полтора инвалида, и разбираться с этим вы будете самостоятельно.
  4. Когда вы разделяете конфиг и базу, вам придётся заботиться о консистентности бэкапов. Иначе вы получите базу с лишними сущностями, или же наоборот - конфиг без данных.

Так почему все не используют SQLite?

Может возникнуть вопрос, почему же тогда SQLite не используется везде, раз остальные СУБД такие плохие.

Они не плохие. У них просто принципиально другое назначение:

  • Они могут использоваться с множества других машин.
  • Поддерживают многопоточную запись данных.
  • Поддерживают шардирование и репликацию.
  • Могут восстановить данные на произвольную точку времени.
  • Рассчитаны на использование сотнями, тысячами и даже большим количеством клиентов.
  • Могут успешно оперировать терабайтами данных.
  • Предлагают дополнительные типы данных, которые часто бывают востребованы в разработке всякой конкретики.

И ещё много-много других вещей. Которые никак вам не пригодятся в случае HA.

И всё же - в каком случае мне стоит поставить Maria/PostgreSQL?

Use cases бывают разные, и, может быть, вы - один из тех, кому это надо? Я накидал примерный чек лист:

  • Вы являетесь квалифицированным разработчиком, DevOPS или DBA.
  • У вас уже есть Maria/PostgreSQL, и вы уже его настроили и бэкапите.
  • У вас база данных HA на десятки гигабайт (если да, скажите, пожалуйста, в комментариях, зачем).
  • Вы используете БД для каких-то внешних запросов из другого приложения.
  • Вы хотите получать интересный незабываемый опыт.

В таких случаях - да, может быть и стоит.

А сам ты чего добился?

Всё это может прозвучать тухло без указания личного опыта. Да, давайте признаюсь - у меня HA стоит на PostgreSQL. Ровно потому что

  • Мне хотелось посмотреть, как это будет работать
  • У меня уже крутится несколько инстансов Postgres
  • Сам я являюсь веб разработчиком и DBA
  • Так же умею настраивать и восстанавливать бэкапы Postgres
  • И в целом люблю делать троллейбус из буханки хлеба

При этом, смигрировав свою базу на 200MB, я не заметил ровно никакого эффекта по росту производительности. И прекрасно отдаю себе отчёт в том, что в любой момент это может выстрелить мне в ногу и придётся смигрировать обратно или снести все данные и начать жизнь с нового листа.

Что делать, если я уже на альтернативной СУБД?

Мигрировать обратно будет довольно больно. Если у вас пока мало данных - лучше снести всё и поставить заново.

Если много, то лучше озаботиться регулярным бэкапом, дополнительно его делать перед каждым обновлением и быть готовым к тому, что всё превратится в тыкву.

Но у меня всё работает медленно, как ускориться?!

Не факт, что виновата СУБД. Можно попробовать следующее:

  • Писать показания датчиков реже.
  • Поиграть с настройками recorder и перестать записывать лишнее.
  • Сменить устройство, на котором у вас стоит HA, если это китайский огрызок компьютера, который не вытягивает по ресурсам.
  • Проверить, используется ли у вас своп. Если да - поиграть с настройками или добавить оперативной памяти.
  • Если ничто не помогает - посмотреть, наконец, что пишется в логах :)

Страшные ссылки

Если вы думаете, что я сгущаю краски, то вот подборка:

  1. На форуме HA до сих пор нет ответа, как бэкапить базу на MariaDB
  2. Ну ладно, на самом деле есть, но вы можете посмотреть, как это недружелюбно выглядит.
  3. Можете посмотреть пост про миграцию на postgres. Главное - не забудьте открыть комментарии и понять, что на самом деле там куча возни с внезапно лишними полями и не импортированными нормально sequences.
  4. Или посмотреть на другую историю миграции и количество плясок с бубном.
  5. На закуску - тред боли, где при обновлении у многих людей полегла MariaDB и они искали способ откатиться обратно.

Заключение

Почему я не стал писать здесь историю своей миграции? Просто для абсолютного большинства пользователей очевидный win-win выбор это SQLite. А остальные в целом должны обладать достаточной квалификацией, чтобы смигрировать сами. Потому что если они ей не обладают - то не смогут поддерживать такую установку и оперировать бэкапами базы.

На этом, наверное, всё. Буду рад, если вы расскажете мне о своих причинах, успехах и неудачах использования альтернативных СУБД. Если история будет убедительной, то готов выложить инструкцию по миграции на PostgreSQL с сохранением данных и с автоматизированными бекапами :)