100%. В статье специально был показан кейс с несколькими возможными улучшениями. Базу, знаете ли, рестартовать тоже может быть не самая умной идеей! :)
Про оценку времени между событиями. Могу согласиться в том, что это может не быть первым приоритетом, но если время эскалации 5 дней (пять, дней!): в понедельник выстрелило, забили, а в пятницу вечером как мы любим очнулись и назвали критом, то время простоя здесь выходит на первые позиции, потому что ты попробуй в пятницу вечером собери трезвую команду.
Про приоритет в точку. Грамотная организация дежурств подразумевает, что человек заступая на "вахту" будет готов подключиться и внезапный инцидент не поломает ему личные и семейные планы. Иначе может получится ситуация когда все инциденты решает один человек. Знаю компанию в которой этот самый один человек в какой-то момент просто выключил ночью телефон, так к нему домой приехали в 4 утра на такси и начили стучать в дверь. Адекватной работой с инцидент менеджментом (да и в целом) такое назвать нельзя.
Абсолютно согласен. Примерно такие же мысли мы и пытались донести статьей: платформа ARM "выстрелит", когда под нее будет соптимизировано достаточное количество приложений, а это ресурсы и время.
Понятно, что новая технология какое-то время будет работать хуже, чем десятилетиями обкатанная архитектура x86, особенно на коде написанном для x86, что мы и видим в том числе на графиках выше.
Но есть один момент. ARM сейчас появляется везде , просто потому, что сделать и выпустить свой ARM процессор становится гораздо дешевле, чем закупать их у Intel или AMD. Apple со своим M1 - яркий пример.
Со временем и набором опыта код на новой архитектуре будет работать все быстрее и быстрее и разрыв будет уменьшаться, а стоимость ARM за счет массовости выпуска будет еще меньше.
Я бы говорил о том, что если проект использует меньше десятка серверов, то смысла играть с архитектурами нет ровно никакого.
Смысл появляется, когда один процент выигрыша производительности экономит сотни тысяч долларов в годовом бюджете. В этот момент начинается гораздо более внимательный выбор платформы и технологий. Код тут же становится компилируемым, а для майнинга из Китая заказывается спец. железки.
Хорошо, допустим. Теперь вопрос: как и зачем в проде появляется запрос на изменение данных который делает full scan? Может быть есть смысл построить индекс и читать только те строки, которые обновляются? Или обновлять значения по первичному ключу?
Когда-то давно на sql.ru постили песенку Ослика-ораклиста. Прошло много лет, но актуальности она не потеряла
Hе секрет, что rollback надо делать пореже,
Лучше делать почаще commit!
Я программой своей скоро сервер повешу -
У админа пускай голова поболит.
Под крики о кастрации,
В обкуренной прострации,
Как следствие мутации
Рождается в момент
Rollback segment для маленькой,
Для маленькой такой транзакции,
Для скромной такой транзакции
Огромный такой сегмент!
Hе секрет, что rollback - это язва и грыжа,
Геморрой и чуть-чуть гайморит.
Если ты программист, а не ослик бесстыжий -
Лучше делай почаще commit!
Припев.
Hе секрет, что друзьям тоже надо ресурсы,
Hадо память, процессор и диск...
Так что делай commit, а иначе... ты в курсе,
Что rollback - для тебя неоправданный риск.
MySQL, как и любая ACID-complaint база вынуждена блокировать изменяемые строки, что бы не допустить ситуации, когда одна и так же строка будет поменяна в двух параллельных транзакциях. Такой подход гарантирует целостность данных, например то, что стоимость покупки в магазине не будет списана с Вашего счета дважды. Если Вам не нужна целостность данных — Вам не нужна транзакционность и связанные с ней накладные расходы (блокировки это только один пункт из большого списка). В целом Вам не нужна ACID база. Берите что-то по-проще и будет Вас счастье.
Спасибо за шикарный пример!
Вот так обычно и оказывается, что и бабушка не бабушка, а немножко дедушка, и SELECT не просто SELECT, а INSERT INTO… SELECT FROM, да еще целой таблицы. А это уже транзакция с записью. И никакая транзакционная БД вам за такое спасибо не скажет. И даже в этом случае таблица-источник в InnoDB не блокируются. Если так уж необходимо переливать всю таблицу — разбейте эту операцию на блоки по 3-5 тысяч строк, а лучше отрефакторите приложение. Админы и пользователи скажут Вам спасибо.
Вы говорите о технической стороне вопроса. Она безусловно важна, но в 2021-ом году как Вы справедливо и заметили источников на тему «как сделать самый лучший мониторинг MySQL, PostgreSQL, Kafka, Cassandra, Nginx, you name it» очень много, но эффективность и стабильность сегодняшнего прода определяют прежде всего процессы и коммуникации, а их из Интернета не скачаешь. Статья как раз об этом.
100%. В статье специально был показан кейс с несколькими возможными улучшениями. Базу, знаете ли, рестартовать тоже может быть не самая умной идеей! :)
Про Root Cause спасибо большое что поделился, если можешь - напиши пожалуйста про размер IT команды в которой этот процесс работал?
Про оценку времени между событиями. Могу согласиться в том, что это может не быть первым приоритетом, но если время эскалации 5 дней (пять, дней!): в понедельник выстрелило, забили, а в пятницу вечером как мы любим очнулись и назвали критом, то время простоя здесь выходит на первые позиции, потому что ты попробуй в пятницу вечером собери
трезвуюкоманду.Про приоритет в точку. Грамотная организация дежурств подразумевает, что человек заступая на "вахту" будет готов подключиться и внезапный инцидент не поломает ему личные и семейные планы. Иначе может получится ситуация когда все инциденты решает один человек. Знаю компанию в которой этот самый один человек в какой-то момент просто выключил ночью телефон, так к нему домой приехали в 4 утра на такси и начили стучать в дверь. Адекватной работой с инцидент менеджментом (да и в целом) такое назвать нельзя.
Выглядит как идея онлайн митапа :) Обдумаем :)
Абсолютно согласен. Примерно такие же мысли мы и пытались донести статьей: платформа ARM "выстрелит", когда под нее будет соптимизировано достаточное количество приложений, а это ресурсы и время.
я бы с удовольствием с тобой подискутировал, можно здесь, можно в любом другом месте, в идеале конечно лично.
Понятно, что новая технология какое-то время будет работать хуже, чем десятилетиями обкатанная архитектура x86, особенно на коде написанном для x86, что мы и видим в том числе на графиках выше.
Но есть один момент. ARM сейчас появляется везде , просто потому, что сделать и выпустить свой ARM процессор становится гораздо дешевле, чем закупать их у Intel или AMD. Apple со своим M1 - яркий пример.
Со временем и набором опыта код на новой архитектуре будет работать все быстрее и быстрее и разрыв будет уменьшаться, а стоимость ARM за счет массовости выпуска будет еще меньше.
Я бы говорил о том, что если проект использует меньше десятка серверов, то смысла играть с архитектурами нет ровно никакого.
Смысл появляется, когда один процент выигрыша производительности экономит сотни тысяч долларов в годовом бюджете. В этот момент начинается гораздо более внимательный выбор платформы и технологий. Код тут же становится компилируемым, а для майнинга из Китая заказывается спец. железки.
Вот так обычно и оказывается, что и бабушка не бабушка, а немножко дедушка, и SELECT не просто SELECT, а INSERT INTO… SELECT FROM, да еще целой таблицы. А это уже транзакция с записью. И никакая транзакционная БД вам за такое спасибо не скажет. И даже в этом случае таблица-источник в InnoDB не блокируются. Если так уж необходимо переливать всю таблицу — разбейте эту операцию на блоки по 3-5 тысяч строк, а лучше отрефакторите приложение. Админы и пользователи скажут Вам спасибо.