Про микросервисную архитектуру и переход на неё написаны сотни статей, однако почти все они больше теоретические и описывают ситуацию лишь верхнеуровнево.
Вот так претенциозно и с обесцениванием других статей всё начиналось. Признаться, я ожидал оригинальных историй и суровой практики. А контент - из довольно очевидных вещей, в особенности "итоговые советы" - набор очевидностей, которые справедливы в любой ситуации, не только в распиле монолита. Совет "Используйте как можно меньше костылей" - серьёзно? Хорошо делайте, плохо не делайте. Ну, такое.
Вообще, одна из хорошо работающих практик - это выносить те вещи, которые в активной разработке. В этом случае уже есть разработчики, которые находятся в контексте этого куска, или которым всё равно надо будет туда погружаться. Как правило, это позволяет как минимум через некоторое время начать писать новый код только в новой парадигме, а старый изолировать и переписать когда дойдут руки. Очень странно выглядит ситуация, когда спустя три года после смены парадигмы монолит продолжает расти и постоянно релизиться...
Вот проблема в том, что огромное количество начинающих ставят вслепую по видосу, который говорит ставить Марию. В целом, статья чтобы им ссылку кидать :)
Вряд ли вы за счёт смены движков получите прирост на таких небольших масштабах. Здесь скорее стоит смотреть на структуру бд и на ваши запросы. И, например, вешать индексы или партиционировать.
Кликхаус крутой, но он больше про кластеризацию, широкие таблицы и обработку таких чудовищных массивов данных, с которыми классические субд не справляются.
В одинаковых условиях с HA ( вспоминаем про редкую запись, это ключевой фактор ). - горячий копипаст сработает и на mysql\psql и без проблем заведется, хоть это не является целевым подходом.
Ну ваще нет, mysql точно умеет упасть вдрезебезги даже если слепок был снят в момент без записи. Да, в каких-то редких случаях он может оказаться рабочим, но как либо рассчитывать на это не стоит.
SQLite же изрядно насилует диск, но шансы получить консистентный файл БД на порядок выше. Ровно потому что для него падение всего - штатная ситуация, а для нормальных СУБД - нет.
На самом деле, я в статье изрядно срезал углы, чтобы совсем в дебри не уходить. И могу сказать, что конечно же постгря и mysql лучше восстанавливаются. Но это только если они нормально настроены. Например, если для mysql binary logs включены. Но если ты ставишь через эддоны, то конечно же их у тебя не будет, и фиг ты их включишь. И даже поставить mysql/postgres отдельно рядом не сможешь, если у тебя supervised установка. Так что для казуального пользователя нормальная настройка mysql\postgres и их бекапа является фактически неподъёмной задачей, а не казуальный и так себе представляет, как обстоят дела. Статья рассчитана на первую категорию :)
Ну вот он у меня без маппига руками не смог перенести автоинкрементные поля, и сделал их обычными числовыми. При этом я PgLoader пробовал и версию из репозитория убунты и самую последнюю. Маппинг мне было лень делать - легко ошибиться - поэтому я структуру взял с новой инициализации, поверх пролил данные (чуть пострадав из-за разного количества полей) и поправил счётчики сиквенсов. Так норм.
А вы правы, ровно так и было, однако. У меня и мысли не возникло, что в mc есть встроенный вьювер для этого формата. Так что да, фигни написал, поправлю. Спасибо большое за конструктив :)
Ответ ниже, к сожалению, я перепутал комментатора с другим и таки ответил ему. Хотя такие формулировки вопросов крайне демотивируют к пояснению чего-либо.
Ох, что ж вы так душните-то, неужели надо разжевать всё?
Хорошо, раз надо - 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 в любом другом виде, и для него файл СУБД - это именно текстовый файл.
Драйвера ClickHouse+sqlAlchemy есть, так что в целом не должно быть сложно. Возможно, прокатит просто доставить пакет через pip и прописать адрес кликхаус сервера.
Для HA же SQLite более чем достаточно почти всегда.
Так я ровно это и писал.
Но где вы в HA видели сотни параллельных процессов записи
И именно это у меня тоже и написано.
Про это уже писали выше, полная чушь.
Окей, тут я старался упростить максимально и видимо получилось плохо. Подумаю, как переписать. Имелось в виду, что в sqlite текстовый формат хранения базы в одном файлике, в котором имхо сложнее продолбать данные неискушённому пользователю, чем в бинарном.
Плохие-плохие, восстановление данных после краша — это стандартная функциональность и MariaDB и PostgreSQL
Хорошо восстанавливается только корректно настроенная СУБД. К сожалению, дефолтные настройки рассчитаны на некритичные данные, и на них база с лёгкостью помирает невозвратно. Можете посмотреть SO - там у народа регулярно безвозвратно погибает база, и они "лечат" это её удалением.
не-а, это хороший способ запороть базу
Это должно прям хорошо повести, чтобы в момент записи копию снять. Рекомендация говорит переписывать файл БД раз в минуту, кажется. Ну и опять же - бэкап должен быть не в единственном числе, так что если в этом вы умудрились попасть в интервал - возьмите соседний бэкап. Так что можно считать, что снимать копию на горячую - норм. С полноценными СУБД это невозможно в принципе.
Но там ничего сложного, запустил команду — получил бэкап, всё легко заскриптовывается.
Для вас и меня - ничего сложного. Но я рассчитывал на аудиторию, которая по ютубу HA ставит и не умеет в консоль и скрипты.
Не думал, что в РФ такие суровые потребители HA. Рассчитывал, что в среднем по больнице народ просто лампочки и розетки выключает. Хотя это наверное так и есть, тут играет ошибка выжившего - писать комментарии на хабре доходят только довольно суровые домовладельцы :)
Вот так претенциозно и с обесцениванием других статей всё начиналось. Признаться, я ожидал оригинальных историй и суровой практики. А контент - из довольно очевидных вещей, в особенности "итоговые советы" - набор очевидностей, которые справедливы в любой ситуации, не только в распиле монолита. Совет "Используйте как можно меньше костылей" - серьёзно? Хорошо делайте, плохо не делайте. Ну, такое.
Вообще, одна из хорошо работающих практик - это выносить те вещи, которые в активной разработке. В этом случае уже есть разработчики, которые находятся в контексте этого куска, или которым всё равно надо будет туда погружаться. Как правило, это позволяет как минимум через некоторое время начать писать новый код только в новой парадигме, а старый изолировать и переписать когда дойдут руки. Очень странно выглядит ситуация, когда спустя три года после смены парадигмы монолит продолжает расти и постоянно релизиться...
Вот проблема в том, что огромное количество начинающих ставят вслепую по видосу, который говорит ставить Марию. В целом, статья чтобы им ссылку кидать :)
Вряд ли вы за счёт смены движков получите прирост на таких небольших масштабах.
Здесь скорее стоит смотреть на структуру бд и на ваши запросы. И, например, вешать индексы или партиционировать.
Кликхаус крутой, но он больше про кластеризацию, широкие таблицы и обработку таких чудовищных массивов данных, с которыми классические субд не справляются.
А сколько терабайт данных вы храните?
Ну ваще нет, mysql точно умеет упасть вдрезебезги даже если слепок был снят в момент без записи. Да, в каких-то редких случаях он может оказаться рабочим, но как либо рассчитывать на это не стоит.
SQLite же изрядно насилует диск, но шансы получить консистентный файл БД на порядок выше. Ровно потому что для него падение всего - штатная ситуация, а для нормальных СУБД - нет.
На самом деле, я в статье изрядно срезал углы, чтобы совсем в дебри не уходить. И могу сказать, что конечно же постгря и mysql лучше восстанавливаются. Но это только если они нормально настроены. Например, если для mysql binary logs включены. Но если ты ставишь через эддоны, то конечно же их у тебя не будет, и фиг ты их включишь. И даже поставить mysql/postgres отдельно рядом не сможешь, если у тебя supervised установка. Так что для казуального пользователя нормальная настройка mysql\postgres и их бекапа является фактически неподъёмной задачей, а не казуальный и так себе представляет, как обстоят дела. Статья рассчитана на первую категорию :)
Получил ответ - говорят, что рассмотрели и добавят команду для включениях этих заголовков в будущих версиях. Крутотень!
Буду рад увидеть ваши аргументы или ответную статью.
UPD. Спасибо @Chupaka, показал, где я не прав, в тексте статьи некорректное утверждение удалено.
Ну вот он у меня без маппига руками не смог перенести автоинкрементные поля, и сделал их обычными числовыми. При этом я PgLoader пробовал и версию из репозитория убунты и самую последнюю. Маппинг мне было лень делать - легко ошибиться - поэтому я структуру взял с новой инициализации, поверх пролил данные (чуть пострадав из-за разного количества полей) и поправил счётчики сиквенсов. Так норм.
А чем вы данные переносили? Возможно, sequences некорректно выставились, данные могли куда попало привязываться в результате.
А вы правы, ровно так и было, однако. У меня и мысли не возникло, что в mc есть встроенный вьювер для этого формата. Так что да, фигни написал, поправлю. Спасибо большое за конструктив :)
Сходите по ссылке, там всё подробно объяснено.
Вот вы упорный.
Ладно, давайте совсем на пальцах.
При выборе настоящих СУБД в HA пользователь получает только бинарный формат данных, и делать дампы ему приходится самому.
При выборе SQLite он получает из коробки автоматический дамп, который и считает файлом своей базы данных.
Так понятно?
Ответ ниже, к сожалению, я перепутал комментатора с другим и таки ответил ему. Хотя такие формулировки вопросов крайне демотивируют к пояснению чего-либо.
Ох, что ж вы так душните-то, неужели надо разжевать всё?
Хорошо, раз надо - HA периодически экспортирует базу SQLite из её бинарного стораджа в текстовый файл с SQL запросами. Пользователи при этом вообще никогда не взаимодействуют с чем-либо кроме текстового файла, и даже в документации по HA написано
Пишут они это ровно по той же причине, почему я это пишу у себя в статье в таком виде - пользователю HA никогда не понадобится работать с базой SQLite в любом другом виде, и для него файл СУБД - это именно текстовый файл.
Драйвера ClickHouse+sqlAlchemy есть, так что в целом не должно быть сложно. Возможно, прокатит просто доставить пакет через pip и прописать адрес кликхаус сервера.
Ох, вы точно мою статью читали?
Так я ровно это и писал.
И именно это у меня тоже и написано.
Окей, тут я старался упростить максимально и видимо получилось плохо. Подумаю, как переписать. Имелось в виду, что в sqlite текстовый формат хранения базы в одном файлике, в котором имхо сложнее продолбать данные неискушённому пользователю, чем в бинарном.
Хорошо восстанавливается только корректно настроенная СУБД. К сожалению, дефолтные настройки рассчитаны на некритичные данные, и на них база с лёгкостью помирает невозвратно. Можете посмотреть SO - там у народа регулярно безвозвратно погибает база, и они "лечат" это её удалением.
Это должно прям хорошо повести, чтобы в момент записи копию снять. Рекомендация говорит переписывать файл БД раз в минуту, кажется. Ну и опять же - бэкап должен быть не в единственном числе, так что если в этом вы умудрились попасть в интервал - возьмите соседний бэкап. Так что можно считать, что снимать копию на горячую - норм. С полноценными СУБД это невозможно в принципе.
Для вас и меня - ничего сложного. Но я рассчитывал на аудиторию, которая по ютубу HA ставит и не умеет в консоль и скрипты.
Не думал, что в РФ такие суровые потребители HA. Рассчитывал, что в среднем по больнице народ просто лампочки и розетки выключает. Хотя это наверное так и есть, тут играет ошибка выжившего - писать комментарии на хабре доходят только довольно суровые домовладельцы :)
А вы выяснили, почему sqlite валился? И как он валился? Частичная потеря или прям всё в Тартар?
И чисто из любопытства - если не секрет, что за метрики вы хотите хранить для потомков? :)
Интересно, какая там политика ретраев. То есть, дольются ли данные при отключении базы на полчаса, например.