Comments 83
у меня mysql, потому, что Home Assistent живет в k3s, и уже есть HA MySQL (от гугла, у него есть дешёвый cloudsql), и потому, что были планы жить в stateless deployment, не в statefulset, но это пока у меня не реализовано. Хочу попробовать InfluxDB добавить, кажется, тогда можно будет отказаться от pvc, сделать сам home assistent Stateless.
Тогда будет не важно что там при бэкапе сломается - бэкапить средствами MySQL и influxdb
Слышал такую историю, что для внешнего доступа ставят Nginx Proxy Manager, который для своей работы требует наличие работающей MariaDB. Ну раз её приходится ставить, то и почему бы и базу заодно на неё не перенести, чтобы зазря не простаивала :) Понятно, что для внешнего доступа можно разные решения использовать, в том числе и без необходимости БД, но вот такой кейс встречался.
А зачем что-то менять?
По умолчанию в HA SQLite - вроде без нареканий всё работает...
Вы абсолютно правы, про это собственно и есть статья. Просто многие ставят по гайдам, где с наскоку без объяснений ставится Мария, а потом страдают, хотелось помочь этим людям.
Вроде да не вроде. После активного использования набора достаточных данных (не говорите, что чистить надо) sqllite ложится и более использовать ее БД в HA нет возможности. Кстати, и у MySQL тоже есть такие ограничения - но они просто заведомо выше. Именно поэтому я использую PG - пока не уперся и приложения работают по 3+ лет, потом все равно что-то да ломается))
У меня нет HA, но я бы использовал такой чудесный небольшой проект локальной/встроенной БД - ElevateDB. Я даже купил лицензию.
Нужно очень сильно постараться, чтобы запороть SQLite базу. Потому что это всего лишь файл с запросами в текстовом виде.
Чего? О_о
Ответ ниже, к сожалению, я перепутал комментатора с другим и таки ответил ему. Хотя такие формулировки вопросов крайне демотивируют к пояснению чего-либо.
Переформулирую в мотивирующем ключе: где у SQLite файл в текстовом виде?
Сходите по ссылке, там всё подробно объяснено.
UPD. Спасибо @Chupaka, показал, где я не прав, в тексте статьи некорректное утверждение удалено.
После нескольких лет и выброшенных sdcard на raspberry pi запустил mariadb в google cloud. Теперь записей на диск стало меньше и карта живёт значительно дольше. Осталось только что то подобное с логами провернуть
а старый ноутбучный hdd подойдет?
Да, я тоже думал о таком, но у меня часто пропадает интернет, не хотелось чтобы без него база отваливалась.
Зачем иметь локальный HA с базой в облаке? Засуньте и HA в облако тогда. Весь смысл локального HA в том, чтобы даже без интернета ваш умный дом не превращался в тыкву.
Ну кстати тут интересный вопрос того, как HA использует базу. Кажется, он подтягивает в себя оперативные данные, а в базу лезет только для периодической записи и давних исторических данных. Если это так, то отвал базы на некоторое время не особо повредит и не сломает текущие сценарии. Но это только гипотеза.
А уд без бд не превращается в тыкву. Ха спокойно работает с отвалившейся бд.
Я бы не назвал HA с отвалившейся БД умным домом.
Пустому ha без кучи сценариев тупо с кнопками, конечно, на базу пофиг. Но тупо кнопки это дом не умный, а ручной.
Если у вас есть автоматизации на основе данных других датчиков, на основе статистики, то умность дома улетучивается. Все что касается статистики или зависит от других сенсоров, и тем более событий, приобретает неопределенное поведение. Например, нормальное управление климатом по средней t за N минут перестает работать. Триггер с использованием for так же неадекватит. Ну вот просто гарантия корректности работы сценариев сходит на нет
Поэтому в локальном ha с базой в облаке смысла никакого. Тут и правда проще HA в облако засунуть целиком, смысл будет абсолютно тот же, раз уж УД тут для людей это просто ручная выключалка света и розеток.
У вас есть умный дом с ХА или это все только догадки? Или вы настолько накрутили ХА что он меняет свои алгоритмы по статистике? Лично я такого ни в одном из чатов по ХА не встречал да и слабо представляю как это вообще можно накрутить в контексте именно ХА.
Сами сценарии не хранятся в БД. Как и текущие состояния датчиков и прочего. И при чем тут ручная включалка? Я вот теперь просто требую пример автоматизации которая ну ни как без накопленной истории не может существовать.
Я согласен если у вас автоматизации на основе каких-то статистических данных... но лично я за 2 полных года ни одной такой не имею. И даже сейчас хорошенько подумав и спросив в одном из чатиков увлеченных уд, коллективно мы не придумали ни одной автоматизации именно в контексте ХА без которой прям жить нельзя или которая бы встала колом навсегда до появления БД.
Опять же даже если у вас и есть что-то такое, то в чем проблема в той же автоматизации предусмотреть такую проблему? Я уже точно год живу с внешней бд и не испытываю ни каких трудностей.
Вот к примеру кусочек автоматизация работы сплитов. Прекрасно держит заданную температуру в не зависимости от того есть ли сейчас бд, только что ха был перезапущен в том числе и без бд или нет.
Целиком отопление умное вот первую зиму живем (первую зиму как температура теплоносителя регулируется УД, остальное было уже в прошлую зиму). Нет ни каких проблем с отвалившейся бд.
Это управление котлом. В зависимости от температуры за бортом устанавливается температура теплоносителя. Без упреждений и прочего, ибо 30кВт котлу нагнать 10 градусов сверху на мой объем теплоносителя и теплопотери это всего ни чего (по хорошему переделать вообще на статистически заданную, но для этого надо еще много денег для переделки системы отопления). Статистика тут тоже особой роли не играет, ибо не поместившийся в первый скрин кусочек автоматизации тупо устанавливает температуру на термоголовках/термостатах и включает их вообще или выключает. Дальше уже работает пид термоголовок/термостатов.
Опять же одно время 2 батареи были через электроклапан, и управлялись они именно нодередом. но пид штука такая что он способен работать не только по накопленным данным, но и перманентно с момента включения только по текущему состоянию. В контексте того же отопления или охлаждения это небольшая пила от силы в 1 градус отклонения. И то это прям я сильно преувеличиваю.
И да, мне уже подсказали что именно в контексте именно умного дома который сам строит алгоритмы своей работы на поведении жильцов статистика и история будет важна. но не в контексте ХА. Да и опять таки как не крути, но у этого УД будет заложенные начальные сведения от которых он будет отталкиваться начав работать с нуля.
Опять же вернувшись к ХА:Assuming the recorder integration is running, historical sensor data is read from the database on startup and is available immediately after a restart of the platform. If the recorder integration is not running, it can take some time for the sensor to start reporting data because some characteristics calculations require more than one source sensor value.
Статистика не зависит от доступности БД. Просто она будет нулевая при запуске и для ее наполнения потребуется время. А уж если БД отвалилась во время работы, то статистика ни куда не денется, она все так же будет доступна.
А кто это такие картинки автоматизации рисует?..
Давайте я вам один вариант приведу - есть такая интеграция, Trends, через которую я сейчас настраиваю контроль резкого изменения показателей датчиков (увеличение температуры и влажности например за 5 минут на 15%). На сколько я понимаю, данная интеграция работает со статистикой. По данному датчику должна включится вытяжка на кухне :)
У вас есть умный дом с ХА или это все только догадки? Или вы настолько накрутили ХА что он меняет свои алгоритмы по статистике?
Какой смысл мне было бы вклиниваться в диалог по теме, которую я не знаю)
Да, накрутил,
Статистика не зависит от доступности БД. Просто она будет нулевая при запуске и для ее наполнения потребуется время. А уж если БД отвалилась во время работы, то статистика ни куда не денется, она все так же будет доступна.
и проблема в том, что в действительности это работает не совсем так, как я ожидаю из доки. Вы не учитываете, что в реальности могут быть баги и неотработанные ситуации, и описание на сайте не гарантия того, что не возникнет коллизий. Гляньте список багов в гитхабе, в тч на SQLAlchemy и, например psycopg2, если говорить про pg, будете приятно удивлены. В ситуации в вакууме вида "доступ до БД отвалился и вернулся" проблемы, конечно, вряд ли будут. Однако в реальности все сложнее и проблема не только в статистике.
Несколько моментов на разных инсталляциях, кейс везде ~одинаковый - HA был подключен к удаленной базе на VPSке.
Были проблемы с интернетом с клиентской стороны, но не просто недоступен, а высокий пинг и потери выше 50%, ну вроде и работает, а вроде и нет. HA успешно цеплялся к БД, но все операции производились с дикой задержкой и это, несмотря на документацию, влияло на работу всего HA - сенсоры и логика залипала с периодичностью в несколько секунд ( как выяснилось методом тыка позднее - это период равный db_retry_wait в конфиге рекордера ). Новые текущие значения появлялись в HA лишь после 1-2 секундного отлипания.
Как сайд-эффект - росло потребление памяти, так как HA копил зомби-коннекты к БД. Правда, это касалось именно PG и на текущий момент в либе psycopg2 это уже исправлено.
Да, пару секунд залипания не страшно и вроде бы незаметно, но очень неприятно, если речь о мгновенных сценариях, типа включения света ночью по датчикам, или ещё более неприятно на мгновенных реакциях на включение одной нагрузки чтобы отключить вторую нагрузку, чтобы не выбило автомат. Это вот реальные сценарии, которые страдали.
Из интересных моментов - db_max_retries в конфигурации рекордера в данном случае оказался бесполезен, так как подключение формально происходило за db_retry_wait, но вот сама операция не могла завершиться за это время, но у себя на стенде я не смог воспроизвести такое же поведение, чтобы отловить проблему и сдать багулю. В логах, увы, каких-то пикантных подробностей выцепить на проблемных инсталляциях не удалось.
По этой причине от удаленной базы я отказался, хотя изначально идея была довольно интересная в хранении долговременной истории, и чтобы пользователь не заморачивался с ней.
А по поводу статистики, все, с чем я сталкивался, было исправлено. Но было два кейса, которые всплывали после недоступности базы:
- Статистика была просто пустая после старта базы, хотя пока база была недоступна она вполне себе считалась. Решалось рестартом HA, данные, конечно, за период недоступности, пропали
- Смешная ситуация с расчетом скользящего среднего за N минут. После восстановления базы, пока не пройдут эти самые N минут - сенсор оставался пустым, хотя HA как бы и имел историю за этот период.
К слову, как раз скользящее среднее я использую для общей температуры в комнате, чтобы избежать пиков и пил, чтобы лишний раз не дергать кондер\обогреватель. Я без этой логики, конечно, не умру, но просто неприятно, если они туда сюда будут на каждый чих переключаться. С датчиками то +- все ок, просто бывают ситуации, когда из-за других факторов у них локально кратковременно может поменять температура ( приоткроется балкон на минуту, кто-то постоит рядом, или коты подышат в них ) и это не нужно учитывать "прям ща"
И еще по мелочи находились за последние 5 лет, пока я с HA, разной степени неприятности.
Обходные пути для проблем конечно были, но это просто немного неприятные моменты.
Тут важно отметить, что HA с того момента хорошо подкрутили и сделали его многопоточным (да и много багов позакрывали, в том числе со статистиками), что вроде как должно снизить риск появления таких ситуаций с залипанием. Однако это все равно не отменяет появления неопределенного поведения в ситуациях с удаленными БД и нестабильным коннектом. Как ни крути, этот кейс и в промышленных условиях вне темы HA часто всплывает и вызывает проблемы, как не обкладывай приложение проверками. И HA тут не будет исключением.
Опять же даже если у вас и есть что-то такое, то в чем проблема в той же автоматизации предусмотреть такую проблему?
Да есть, конечно, fallback-сценарии на основе текущих значений, в случае же отсутствия текущих - переводится в дефолтное состояние, как правило, в отключенное ( справедливо для мощных нагрузок, типа бойлеров, эл. обогревателей ). Это работает так, как и требуется, но это ведь костыль на всякий случай. Ну и опять же, в вышеописанной ситуации с мгновенными сценариями с залипаниями это и не помогло бы никак.
И да, мне уже подсказали что именно в контексте именно умного дома который сам строит алгоритмы своей работы на поведении жильцов статистика и история будет важна. но не в контексте ХА.
А почему не в контексте HA? Ничто же не мешает выстроить систему вокруг него. HA у меня выступает лишь UI для монитора и интегратором с девайсами. Абсолютно всю логику делает тот же NodeRed, все из Postgres реплицируется в clickhouse для долговременного хранения и просмотра в графане.
Сейчас еще ко всему прочему думаю, как накинуть и ML на вентилятор для принятия решений.
Пока первая проблематика, которую я хотел бы решить - иногда хочется температуру в комнатах немножко изменить ( жарковато или холодновато, хотя объективно t та же самая ), но непонятно, какие измеримые триггеры приводят к этому. Пока собираю инфу со всех датчиков и девайсов ( включая факт ручного изменения ) до ровного года и буду искать паттерны, по которым можно выносить решение.
В идеале - не хочу писать новые сценарии ( хотя это один из выходов ), а возложить это не предварительный расчет, сделанный в кликхаусе с помощью mindsdb по всем сенсорам. Далее он будет NR'ом через апишку доставаться с кликхауса.
Пока не знаю, стоит ли игра свеч и выгорит ли идея вообще, но попробовать хочется, но 200+ входных параметров в запросе уже немного пугают.
Если не получится - ну просто красивые графички нарисую с зависимостями x)
Лично я такого ни в одном из чатов по ХА не встречал
спросив в одном из чатиков увлеченных уд
Может не в тех чатах обитаете?) Заходите на огонек в дискордный англо чат, тут часто проскакивают довольно специфичные и интересные вопросы с инсталляциями от ультра-гиков ( я иначе их назвать не могу ). Ру тг чаты по УД довольно унылы, имхо, и вопросы с решениями довольно пресные и типовые.
если речь о мгновенных сценариях, типа включения света ночью по датчикам, или ещё более неприятно на мгновенных реакциях на включение одной нагрузки чтобы отключить вторую нагрузку, чтобы не выбило автомат
Запись в БД (подсчет статистики) не влияет на текущее состояние сенсора. Это 2 разные вещи (я говорю за текущее положение дел и как тот у кого бд внешняя не первый день). С провалами и пустотами после/до согласен, но у нас не тонкий процесс где дельта даже на 1 градус отклонения из-за такой внештатной ситуации превратит все наши старания в муки от использования УД (если она такая вообще будет).
К слову, как раз скользящее среднее я использую для общей температуры в комнате, чтобы избежать пиков и пил, чтобы лишний раз не дергать кондер\обогреватель.
Не испытываю проблем, хотя бы потому что пид (особенно хорошо подогнанный) прекрасно справляется и с позиции "включен с нуля". Опять же может если у Вас 20 кубов все помещение и 5кВт обогреватель с 5кВт кондером, то может это и влияет, но обычно климат в помещении вещь довольно инерционная. И что бы вот так вот перманентно чтобы была какая-то нереальная пила, да чтобы ее еще и ощутить можно было аж до дискомфорта... Я не представляю такой кейс. Тем более с тем же пидом.
когда из-за других факторов у них локально кратковременно может поменять температура ( приоткроется балкон на минуту, кто-то постоит рядом, или коты подышат в них ) и это не нужно учитывать "прям ща"
Открыли окно, словили триггер от датчика окна, поставили работу того же климата в положение "работает как работает" или вообще выключили, ибо смысл греть или остужать улицу. С расположением... И согласен и не согласен. Вы сами их так разместили что Ваш кот влияет на него (а может он это специально? не думали? ))) ) и теперь из-за этого придумываете каким костылем это подпереть. А так я и сам ловил прикол когда на диване уже холодно, но пид все еще напрягает сплит. Оказалось идея повесить датчик над потолком в дальнем внешнем углу когда за окном +50 идея прям сильно такая себе. И все стало предельно просто. Перевесил датчик именно там где мне нужна эта температура и забыл о проблеме (к слову теперь все датчики у меня располагаются на высоте 1-1.2 метра от пола. Т.е. я проблему создал не подумав и я же ее решил, без костылей. В особо сложных случаях (большое помещение) - 2 датчика и больше + берем минимум для охлаждения и максимум для обогрева с небольшой дельтой (я про однозонную работу климата). Ребус решен. Много кто вешает просто 2 датчика и работает по средней. Но все кого я знаю учитывают в автоматизациях эти внешние факторы и потребности в средней за N-минут ни кто не испытывает. Точнее не имеют проблем с отвалившимся рекордером или статистикой.
Как ни крути, этот кейс и в промышленных условиях вне темы HA часто всплывает и вызывает проблемы
У нас немного не промышленные условия и потребности. К примеру для Вас комфортная температура 25, но Вы же не чувствуете дискомфорт при 24?
Пока первая проблематика, которую я хотел бы решить - иногда хочется температуру в комнатах немножко изменить
"Ощущаемая температура". В контексте закрытого помещения в расчет берем влажность и температуру. Но у вас УД, управляем и влажностью и температурой и забываем об этой сложности. Хотя конечно это уже прилично другой бюджет. Но в том же NR вроде бы как есть аддоны с кучей факторов, но это настолько темный лес что я просто посмотрел и удалил элемент. Знаю 1 случай когда человек прям озадачился, но золотой середины добиться на сколько я знаю он не смог, особенно учитывая что два человека рядом сидящие могут по разному одно и тоже ощущать.
Интересно. Ваш опыт кардинально отличается от моего. Моя первая установка HA была на rpi. Ставил просто оригинальный образ. Не помню, что за БД была выбрана, но дополнительно стоял ещё Influx. Проблем с флешкой не было.
@peleccomАлександр, а сколько лет у вас sd карта жила на rpi с HomeAssistant?
И как много было устройств и как часто были запросы?
Ставить что-то для реальной эксплуатации на sd - такое. К долгой и внезапной дороге до места установки. Но есть способ увеличить срок жизни увеличив https://www.home-assistant.io/integrations/recorder#commit_interval и сохраняя логи на ram disk
Привет! Например хочу вернуться с Марии на стандартный sqlight. Пусть все пишется с нуля...
Что надо сделать для этого? Как выкарчевать? )
Довольно странная статья. Сравнивать базы данных по объёму в байтах - это, скажем так, странный подход. Заставляющий усомниться в компетентности автора.
Да, SQLite действительно медленнее MySQL, и сильно. Разница в скорости чтения становится заметной вполне отчётливо при размерах таблиц в первые сотни тысяч записей. Разница в скорости записи - при размерах в первые десятки тысяч. При этом объём базы данных может быть мегабайты, не больше. Параллельный доступ к одной базе в SQLite вообще невозможен.
При этом это всё совершенно не аргументы против использования SQLite - это замечательная вещь, поистине гениальная. Но она имеет вполне определённую область применения, вне которой её использовать не надо.
Интернет с вами не согласен - люди вполне успешно используют SQLite для баз данных в гигабайты, а на найденных мной бенчмарках по чтению он оказывается быстрее, чем mysql. Но конечно бенчмарки можно очень по разному делать, поэтому над официальными на сайте sqlite даже подписано большими буквами, что это старая информация. А новой нет - видимо, чтобы не провоцировать срачи :)
Но у меня нет цели заводить холивар, я написал ровно то же самое, что вы - что разные базы подходят для разных способов использования. И рассматривал именно контекст применения в стандартной инсталляции Home Assistant.
Опять же, размер становится понятной метрикой, когда мы говорим о конкретной структуре таблиц и хранении данных, которая в данном случае у нас имеется (HA). Так-то понятно, что забивать базу неиндексируемыми блобами или искать по миллионам текстовых записей - принципиально разные задачи :)
Вы упорствуете в измерении размера базы данных в байтах. Т.е., вы очевидно не понимаете, что это полностью бессмысленно.
И именно в контексте Home Assistant я вижу, что SQLite -- не лучшее решение, а MySQL подходит гораздо лучше. Я бы даже сказал, что для Home Assistant SQLite не годится, а применять следует исключительно MySQL.
на найденных мной бенчмарках по чтению он оказывается быстрее, чем mysq
По чтению действительно быстрее. Только в контексте HA более важна именно запись. А без тюнинга запись работает медленнее даже с пустой базой. Но для обычного пользователя это незаметно будет.
Исходя из собственного опыта
Sqlite отваливался у меня довольно часто и по разным причинам ( исход везде один - data corrupt ), при этом у mysql/psql сильно больше механизмов восстановления и самолечения, хотя и не пригождались еще.
По размерам принципиальной разницы нет на самом деле, если мы смотрим именно иенно базу ha, а не всю mysql целиком. Смотреть просто на папку со всей mysql бессмысленно
HA у меня срет довольно активно и за полгода собралось данных на 15+ Гб. Скорость, как записи, так и чтения, в sqlite снизилась катастрофически, автоматизации основанные на статистике, а равно выборке данных, срабатывали не моментально, запросы выполнялись по . С миграцией на psql ситуация нормализовалась. Psql не тюнил как-либо дополнительно - мне хватает дефолта.
К слову про первый пункт, мне не очень понятен тезис в статье про
MariaDB и PostgreSQL ... имеют довольно неплохие шансы накрыться при некорректном завершении работы, например, при выключении сервера кнопкой или отключении электричества
ведь абсолютно то же самое справедливо и для sqlite и шансы накрыться у них довольно одинаковые все же. Если в базу редко что-то пишется, что справедливо для HA ( по дефолту HA коммитит в базу изменения раз в 5 секунд, настройка commit_interval в рекордере ), то что с sqlite, что с mysql базу все же довольно сложно будет накрыть отрубанием электричества. В худшем случае мы потеряем 1-2 транзакции записи в обоих случаях. Если же мы будем говорить о какой-то продуктивной нагрузке с сотней одновременных записей в секунду - мы также получаем одинаково высокие шансы порчи базы в обоих случаях.
Но только в отличии от sqlite у mysql\psql больше механизмов восстановления и шансов восстановить запоротую БД сильно больше, если у вас нет резервной копии, сделанной заранее. Рассматривать надо не только в контексте падений, но и в контексте инструментария восстановления базы.
Другой вопрос, что в контексте HA исторические данные нужны и критичны далеко не всем, и хранить больше стандартных 10 дней мало кому надо, поэтому по большей части sqlite будет за глаза.
Для бекапа SQLite достаточно на горячую (при запущенном HA) скопировать файлик базы. А вот если вы скопируете файлы PostgreSQL или MySQL на горячую, то они у вас просто не заведутся.
Тут вы на самом деле привираете.
В одинаковых условиях с HA ( вспоминаем про редкую запись, это ключевой фактор ). - горячий копипаст сработает и на mysql\psql и без проблем заведется, хоть это не является целевым подходом.
Впрочем, копипаст и для sqlite не является целевым, для этих целей следует использовать Online Backup API. На больших объемах \ под большой нагрузкой шансы получить рабочий и полный бекап горячим копипастом снижаются точно также и для sqlite.
В одинаковых условиях с HA ( вспоминаем про редкую запись, это ключевой фактор ). - горячий копипаст сработает и на mysql\psql и без проблем заведется, хоть это не является целевым подходом.
Ну ваще нет, mysql точно умеет упасть вдрезебезги даже если слепок был снят в момент без записи. Да, в каких-то редких случаях он может оказаться рабочим, но как либо рассчитывать на это не стоит.
SQLite же изрядно насилует диск, но шансы получить консистентный файл БД на порядок выше. Ровно потому что для него падение всего - штатная ситуация, а для нормальных СУБД - нет.
На самом деле, я в статье изрядно срезал углы, чтобы совсем в дебри не уходить. И могу сказать, что конечно же постгря и mysql лучше восстанавливаются. Но это только если они нормально настроены. Например, если для mysql binary logs включены. Но если ты ставишь через эддоны, то конечно же их у тебя не будет, и фиг ты их включишь. И даже поставить mysql/postgres отдельно рядом не сможешь, если у тебя supervised установка. Так что для казуального пользователя нормальная настройка mysql\postgres и их бекапа является фактически неподъёмной задачей, а не казуальный и так себе представляет, как обстоят дела. Статья рассчитана на первую категорию :)
SQLite же изрядно насилует диск, но шансы получить консистентный файл БД на порядок выше
По сравнению с mysql\psql - нет, не выше. Шансы +- такие же, как и тех же mysql\psql, только в sqlite усугубляется тем, что он однофайловый.
Я просто исхожу из собственной статистики использования этих трех баз, как на работе, так и в домашних условиях.
Но тут вы верно отметили, все еще зависит от настроек базы, в mysql конечно надо поиграться, но я давненько в ней не копался уже, с момента разделения на марию, может там получше стало. В psql с этим все довольно хорошо и по дефолту, правда, насколько я помню, psql в супервизоре вроде и нет в аддонах, но могу ошибаться.
Но если ты ставишь через эддоны,
Ну слушай, если бы я был настолько зеленым и ставил бы все через аддоны в супервизор установке, как предлагается разрабами - вряд ли бы у меня поднялся вопрос о том, какую базу использовать вообще, я бы и использовал то, что предлагает HA из коробки. К слову, он и не поднимался, когда я только начал копаться в HA. А что за страшные слова тут с mysql и psql - да пофиг) Работает - не трогай)
Вобщем все равно на разницу в скоростях СУБД. У НА бутылочное горлышко явно не там. А глядеть в History выборку по всем объектам за все время - то ещё извращение.
Но, лично у меня SQLite в прошлом году валилась дважды с потерей данных, заставив меня обратиться к документации по recorder и тому как вообще устроено хранение метрик и истории в хоумассистант. Что сильно разочаровало. Я то думал что хранится все и навсегда.
Так что теперь рекордим в MariaDB, который и так вертится на отдельном хосте. И потихоньку мастерим свои RP и CQ в InfluxDB для увековечивания важных метрик для потомков.
А вы выяснили, почему sqlite валился? И как он валился? Частичная потеря или прям всё в Тартар?
И чисто из любопытства - если не секрет, что за метрики вы хотите хранить для потомков? :)
Database corrupt. Стандартные средства SQLite по восстановлению не справились.
Глубоко не копал. Полез на форума HA, увидел там вой на лайт и направление в сторону "мускула". Меня устроило. Мария уже есть. Репликация, бэкап, способы лечения понятны. Долго выбором не страдал.
Хранить хочу данные по энергопотреблению здания и климату. Чтобы хотя бы руками потом делать аналитику по климату и теплопотерям.
Выводы правильные, "просто используйте SQLite". Аргументы — неправильные.
MariaDB/MySQL быстрее, чем SQLite — и да и нет. Вопрос в деталях. Если запустить бенчмарк (тот же sysbench) c тысячами запросов в секунду и сотнями подключений — SQLite будет вообще не конкурент. Для HA же SQLite более чем достаточно почти всегда.
SQLite не очень хорошо работает с параллельными процессами записи?
Неа. Вот как раз Да-а. Но где вы в HA видели сотни параллельных процессов записи? То есть это реальный недостаток SQLite, но в данном случае он не играет роли.Нужно очень сильно постараться, чтобы запороть SQLite базу. Потому что это всего лишь файл с запросами в текстовом виде. Про это уже писали выше, полная чушь. SQLite — полноценная база данных, со страничной оранизацией данных. db разбит на страницы, там всё бинарное. Есть undo log и wal, как положено, для восстановления, если что. Вот как раз текстовый файл запороть — как два пальца.
В то время как MariaDB и PostgreSQL имеют довольно неплохие шансы накрыться при некорректном завершении работы. Плохие-плохие, восстановление данных после краша — это стандартная функциональность и MariaDB и PostgreSQL, она регулярно тестируется и регулярно же используется в проде (к сожалению). Это буква D в "ACID". Накрыться может всё, SQLite тоже, но шансы невелики.
Для бекапа SQLite достаточно на горячую (при запущенном HA) скопировать файлик базы. Как почти с любой базой данных — не-а, это хороший способ запороть базу (если уж выключение питания не помогло).
нужно или останавливать СУБД или пользоваться специальными инструментами экспорта — везде так, SQLite не исключение. Но там ничего сложного, запустил команду — получил бэкап, всё легко заскриптовывается.
Ох, вы точно мою статью читали?
Для HA же SQLite более чем достаточно почти всегда.
Так я ровно это и писал.
Но где вы в HA видели сотни параллельных процессов записи
И именно это у меня тоже и написано.
Про это уже писали выше, полная чушь.
Окей, тут я старался упростить максимально и видимо получилось плохо. Подумаю, как переписать. Имелось в виду, что в sqlite текстовый формат хранения базы в одном файлике, в котором имхо сложнее продолбать данные неискушённому пользователю, чем в бинарном.
Плохие-плохие, восстановление данных после краша — это стандартная функциональность и MariaDB и PostgreSQL
Хорошо восстанавливается только корректно настроенная СУБД. К сожалению, дефолтные настройки рассчитаны на некритичные данные, и на них база с лёгкостью помирает невозвратно. Можете посмотреть SO - там у народа регулярно безвозвратно погибает база, и они "лечат" это её удалением.
не-а, это хороший способ запороть базу
Это должно прям хорошо повести, чтобы в момент записи копию снять. Рекомендация говорит переписывать файл БД раз в минуту, кажется. Ну и опять же - бэкап должен быть не в единственном числе, так что если в этом вы умудрились попасть в интервал - возьмите соседний бэкап. Так что можно считать, что снимать копию на горячую - норм. С полноценными СУБД это невозможно в принципе.
Но там ничего сложного, запустил команду — получил бэкап, всё легко заскриптовывается.
Для вас и меня - ничего сложного. Но я рассчитывал на аудиторию, которая по ютубу HA ставит и не умеет в консоль и скрипты.
Имелось в виду, что в sqlite текстовый формат хранения базы в одном файлике
Чего? о_О
Я не понимаю, вы серьезно в это верите и с этим пришли на хабр со статьей о выборе оптимальной СУБД?
Ох, что ж вы так душните-то, неужели надо разжевать всё?
Хорошо, раз надо - HA периодически экспортирует базу SQLite из её бинарного стораджа в текстовый файл с SQL запросами. Пользователи при этом вообще никогда не взаимодействуют с чем-либо кроме текстового файла, и даже в документации по HA написано
The default, and recommended, database engine is SQLite which does not require any configuration. The database is stored in your Home Assistant configuration directory (’/config/’) and is named home-assistant_v2.db.
Пишут они это ровно по той же причине, почему я это пишу у себя в статье в таком виде - пользователю HA никогда не понадобится работать с базой SQLite в любом другом виде, и для него файл СУБД - это именно текстовый файл.
Вы точно хотели процитировать именно эту часть документации в качестве аргументации вашей позиции?
Коль уж меня душным назвали.
Все три упоминаемых вами СУБД используют бинарный формат хранения данных.
За исключением наверное csv storage engine для таблиц mysql/mariadb. Но там он только для отдельной таблицы и совсем не в виде запросов.
mysql так же умеет экспортировать базу в файл с тектовыми запросами - это называется дампом, но не является базой данных.
Поэтому ваше утверждение в статье заведомо некорректно:
Нужно очень сильно постараться, чтобы запороть SQLite базу. Потому что это всего лишь файл с запросами в текстовом виде.
Ваш последующий комментарий тоже некорректен:
в sqlite текстовый формат хранения базы в одном файлике
Но вы решили спорить дальше.
В какой текстовый файл HA экспортирует базу SQLite? Или вы в Midnight Commander нажали на файле F3 и увидели текстовые запросы? Тогда Shift+F3 вас сильно удивит
Конечно, читал. Я ж с этого комментарий и начал: выводы правильные ☺
И, опять, SQLite — полноценная база данных. В MariaDB, например, если подождать, пока она ничего не будет делать, тоже прекрасно можно файлы копировать, ничего не сломается. От нагрузки зависит, повезёт или нет.
Для всех метрик использую викторию, т.к. умеет нормально жать данные и можно хранить часто меняющиеся метрики очень долго не забивая место на карте памяти, для остального мария, т.к. она все равно нужна для других целей мне удобней все держать в одной базе и бэкапить целиком. Хотелось бы конечно плагин для работы с ClickHouse чтоб иметь единую базу и для метрик и для данных, но тут вариант только напилить самому, т.к. комьюнити это не особо интересно.
Я когда переезжал из SQLite на PostgreSQL, через пару недель заметил непонятную хрень. Присмотрелся — там действительно было что-то вроде подстановки одних исторических данных в графики других энтити. Пытался редактированием базы проблему решить, но полностью избавился лишь переездом на чистую базу, без сохранения истории. Благо, исторические данные в Victoria Metrics лежат.
А чем вы данные переносили? Возможно, sequences некорректно выставились, данные могли куда попало привязываться в результате.
Наверное, PgLoader, как и все. От 15-й версии Постгри.
Ну вот он у меня без маппига руками не смог перенести автоинкрементные поля, и сделал их обычными числовыми. При этом я PgLoader пробовал и версию из репозитория убунты и самую последнюю. Маппинг мне было лень делать - легко ошибиться - поэтому я структуру взял с новой инициализации, поверх пролил данные (чуть пострадав из-за разного количества полей) и поправил счётчики сиквенсов. Так норм.
Переехал на (уже установленную и работающую над другой задачей) Марию после того, как sqlite стал тормозить (данных было примерно за 6 мес).
В планах было организовать репликацию на соседнюю машину, но теперь тормозит и Мария, поэтому ищу способы переехать на кликхауз. Если не получится, буду агрегировать данные либо искать другие способы.
А сколько терабайт данных вы храните?
Прямо сейчас примерно 0.12. Машина не из самых производительных, плюс занята и другими задачами. Поэтому пытаюсь оптимизировать.
т.е. за 6 месяцев у вас sqlite база выросла до 120 гигабайт?
А какая мощность одноплатника (мини-пк) на котором запущен hass? (проц/память/emmc/sd/ssd/nvme?)
Вряд ли вы за счёт смены движков получите прирост на таких небольших масштабах.
Здесь скорее стоит смотреть на структуру бд и на ваши запросы. И, например, вешать индексы или партиционировать.
Кликхаус крутой, но он больше про кластеризацию, широкие таблицы и обработку таких чудовищных массивов данных, с которыми классические субд не справляются.
Организация БД в HA несколько нетрадиционная, на мой взгляд, но есть ощущение, что колоночная БД поможет. Смотрел в сторону инфлюкса, отзывы не самые положительные. Если не получится с каликхаусом, то может быть попробую MariaDB ColumnStore. Ну и на крайний случай агрегация (огрубление) имеющихся данных.
Организация БД в HA несколько нетрадиционная
@xhd, а что именно нетрадиционного? Я ещё не углублялся в базу хасса, просто интересно.
Какую базу данных выбрать для Home Assistant