Понятно, что новая технология какое-то время будет работать хуже, чем десятилетиями обкатанная архитектура 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
IT сфера уже давно по большей своей части напоминает fashion индустрию: чем громче технология, тем больше у нее пользователей. С одной стороны это дает возможность индустрии быстро развиваться, с другой очень много ресурсов уходит с одной стороны на пиар с другой на использование непригодных для задачи инструментов.
По конфигу два коментария.
monitor_ping_interval у вас стоит в 200000ms (200 секунд), это означает что среднее время между падением сервера и обнаружением этого ProxySQL — 100 секунд, а в плохом случае ProxySQL будет ломиться на нерабочий сервер больше трех минут. Лучше поставить это значение хотя бы в дефолтное (8 секунд), а лучше раз в секунду, проверка легкая, сервер не тормозит.
max_connections у вас стоит в 10 000. Если каждый клиент откроет в пике 10к коннектов, базе может стать очень нехорошо. Лучше поставить в сотню, тем более что вы сами посчитали, что в среднем у вас 50-80 активных подключений с бокса, что честно говоря очень много и это значит что нужно смотреть на незакрытые транзакции и медленные запросы.
Понятно, что новая технология какое-то время будет работать хуже, чем десятилетиями обкатанная архитектура x86, особенно на коде написанном для x86, что мы и видим в том числе на графиках выше.
Но есть один момент. ARM сейчас появляется везде , просто потому, что сделать и выпустить свой ARM процессор становится гораздо дешевле, чем закупать их у Intel или AMD. Apple со своим M1 - яркий пример.
Со временем и набором опыта код на новой архитектуре будет работать все быстрее и быстрее и разрыв будет уменьшаться, а стоимость ARM за счет массовости выпуска будет еще меньше.
Я бы говорил о том, что если проект использует меньше десятка серверов, то смысла играть с архитектурами нет ровно никакого.
Смысл появляется, когда один процент выигрыша производительности экономит сотни тысяч долларов в годовом бюджете. В этот момент начинается гораздо более внимательный выбор платформы и технологий. Код тут же становится компилируемым, а для майнинга из Китая заказывается спец. железки.
Вот так обычно и оказывается, что и бабушка не бабушка, а немножко дедушка, и SELECT не просто SELECT, а INSERT INTO… SELECT FROM, да еще целой таблицы. А это уже транзакция с записью. И никакая транзакционная БД вам за такое спасибо не скажет. И даже в этом случае таблица-источник в InnoDB не блокируются. Если так уж необходимо переливать всю таблицу — разбейте эту операцию на блоки по 3-5 тысяч строк, а лучше отрефакторите приложение. Админы и пользователи скажут Вам спасибо.
С другой стороны чем больше людей делает такой выбор тем спокойнее на душе :)
monitor_ping_interval у вас стоит в 200000ms (200 секунд), это означает что среднее время между падением сервера и обнаружением этого ProxySQL — 100 секунд, а в плохом случае ProxySQL будет ломиться на нерабочий сервер больше трех минут. Лучше поставить это значение хотя бы в дефолтное (8 секунд), а лучше раз в секунду, проверка легкая, сервер не тормозит.
max_connections у вас стоит в 10 000. Если каждый клиент откроет в пике 10к коннектов, базе может стать очень нехорошо. Лучше поставить в сотню, тем более что вы сами посчитали, что в среднем у вас 50-80 активных подключений с бокса, что честно говоря очень много и это значит что нужно смотреть на незакрытые транзакции и медленные запросы.