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

1368dc5522682a7a54204d79b8d9d4bc.jpg

Введение

На случай, если ещё не встречались с 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 базу. Потому что это всего лишь файл с запросами в текстовом виде. Всегда может случиться какая-то проблема с железом, но от неё вообще мало что спасает кроме бекапов.

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

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

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

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

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

  1. Установка с видео выглядит легко и просто для пустого HA. Если у вас уже есть данные, то всё становится гораздо интереснее!

  2. Обратная миграция на 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 с сохранением данных и с автоматизированными бекапами :)

© Habrahabr.ru