Абсолютно согласен. Примерно такие же мысли мы и пытались донести статьей: платформа 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» очень много, но эффективность и стабильность сегодняшнего прода определяют прежде всего процессы и коммуникации, а их из Интернета не скачаешь. Статья как раз об этом.
Хайп да, большой фактор. IT давным давно стал «модным» движением, когда технология часто выбирается исходя из красоты строчки в резюме, а не эффективности ее использования в конкретной задаче.
С другой стороны чем больше людей делает такой выбор тем спокойнее на душе :)
В целом кеширование по TTL не самая умная штука. Под нагрузкой работает, но если нужно существенную часть данных отдавать из кеша, лучше научить приложение ходить вместо базы в memcache / редис / etc
Выглядит как идея онлайн митапа :) Обдумаем :)
Абсолютно согласен. Примерно такие же мысли мы и пытались донести статьей: платформа ARM "выстрелит", когда под нее будет соптимизировано достаточное количество приложений, а это ресурсы и время.
я бы с удовольствием с тобой подискутировал, можно здесь, можно в любом другом месте, в идеале конечно лично.
Понятно, что новая технология какое-то время будет работать хуже, чем десятилетиями обкатанная архитектура x86, особенно на коде написанном для x86, что мы и видим в том числе на графиках выше.
Но есть один момент. ARM сейчас появляется везде , просто потому, что сделать и выпустить свой ARM процессор становится гораздо дешевле, чем закупать их у Intel или AMD. Apple со своим M1 - яркий пример.
Со временем и набором опыта код на новой архитектуре будет работать все быстрее и быстрее и разрыв будет уменьшаться, а стоимость ARM за счет массовости выпуска будет еще меньше.
Я бы говорил о том, что если проект использует меньше десятка серверов, то смысла играть с архитектурами нет ровно никакого.
Смысл появляется, когда один процент выигрыша производительности экономит сотни тысяч долларов в годовом бюджете. В этот момент начинается гораздо более внимательный выбор платформы и технологий. Код тут же становится компилируемым, а для майнинга из Китая заказывается спец. железки.
Вот так обычно и оказывается, что и бабушка не бабушка, а немножко дедушка, и SELECT не просто SELECT, а INSERT INTO… SELECT FROM, да еще целой таблицы. А это уже транзакция с записью. И никакая транзакционная БД вам за такое спасибо не скажет. И даже в этом случае таблица-источник в InnoDB не блокируются. Если так уж необходимо переливать всю таблицу — разбейте эту операцию на блоки по 3-5 тысяч строк, а лучше отрефакторите приложение. Админы и пользователи скажут Вам спасибо.
С другой стороны чем больше людей делает такой выбор тем спокойнее на душе :)