Расскажите, пожалуйста, чем эффективнее? Если отсутствием длинной транзакции, то как я написал коллеге чуть ниже, миграция одной транзакцией позволяет легко откатить изменения при проблемах. Это такая архитектурная необходимость.
Я искал такую возможность в PgLoader, но не обнаружил. Оно и логично, т.к. миграция в одной транзакции позволяет легко откатить все изменения, если что-то пошло не так при миграции. У меня лично было много проблем на PgLoader 3.6.1. И без отката всех изменений было бы очень неудобно.
Верно, я не стал пытаться объять необъятное и включать в одну статью еще и причины выбора СУБД, и вопросы ее тюнинга. Миграция на PostgreSQL нужна была для того, чтобы в последующем применить TimescaleDB. О преимуществах TimescaleDB для Zabbix уже неоднократно писали в том числе здесь на Хабре. Базы данных временных рядов в целом больше подходят для систем мониторинга.
Например, одна из самых назойливых проблем при работе Zabbix на реляционной БД — медленный Housekeeper. Хотя бы для решения этой проблемы уже стоит мигрировать.
Нашел статью: habr.com/ru/company/oleg-bunin/blog/470902
Information
Rating
Does not participate
Location
Ханты-Мансийск, Тюменская обл. и Ханты-Мансийский АО, Россия
После этой фразы я до конца статьи ждал проблему. Но не дождался. Интересно, спасибо.
Например, одна из самых назойливых проблем при работе Zabbix на реляционной БД — медленный Housekeeper. Хотя бы для решения этой проблемы уже стоит мигрировать.
Нашел статью:
habr.com/ru/company/oleg-bunin/blog/470902