Pull to refresh
12
0
Vladimir Fedorkov @astellar

MySQL, высокие нагрузки.

Send message

Выглядит как идея онлайн митапа :) Обдумаем :)

Абсолютно согласен. Примерно такие же мысли мы и пытались донести статьей: платформа ARM "выстрелит", когда под нее будет соптимизировано достаточное количество приложений, а это ресурсы и время.

я бы с удовольствием с тобой подискутировал, можно здесь, можно в любом другом месте, в идеале конечно лично.

Понятно, что новая технология какое-то время будет работать хуже, чем десятилетиями обкатанная архитектура x86, особенно на коде написанном для x86, что мы и видим в том числе на графиках выше.

Но есть один момент. ARM сейчас появляется везде , просто потому, что сделать и выпустить свой ARM процессор становится гораздо дешевле, чем закупать их у Intel или AMD. Apple со своим M1 - яркий пример.

Со временем и набором опыта код на новой архитектуре будет работать все быстрее и быстрее и разрыв будет уменьшаться, а стоимость ARM за счет массовости выпуска будет еще меньше.

Я бы говорил о том, что если проект использует меньше десятка серверов, то смысла играть с архитектурами нет ровно никакого.

Смысл появляется, когда один процент выигрыша производительности экономит сотни тысяч долларов в годовом бюджете. В этот момент начинается гораздо более внимательный выбор платформы и технологий. Код тут же становится компилируемым, а для майнинга из Китая заказывается спец. железки.

Не могу Вам посочувствовать. Нет желания добавлять индекс и нравится как работает Oracle — ставьте Oracle и работайте с ним.
Другими словами вы не хотите строить индекс, но хотите быстро. ШТОШ. MySQL это база с открытым кодом — у Вас всегда есть возможность сделать как надо.
Хорошо, допустим. Теперь вопрос: как и зачем в проде появляется запрос на изменение данных который делает 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 тысяч строк, а лучше отрефакторите приложение. Админы и пользователи скажут Вам спасибо.
Кроме того, MySQL при чтении сами строки не блокирует, если конечно не указать FOR UPDATE. Блокируются только метаданные (структура таблицы).
Если у Вас запрос сканирует всю таблицу, то начинать нужно не с блокировок, а с оптимизации этого самого запроса.
Вы говорите о технической стороне вопроса. Она безусловно важна, но в 2021-ом году как Вы справедливо и заметили источников на тему «как сделать самый лучший мониторинг MySQL, PostgreSQL, Kafka, Cassandra, Nginx, you name it» очень много, но эффективность и стабильность сегодняшнего прода определяют прежде всего процессы и коммуникации, а их из Интернета не скачаешь. Статья как раз об этом.
Мне как раз интресно как бывает в жизни. У меня очень специфичный опыт, поэтому и интересно как люди живут без понимания стека.
Оракл это отдельный большой мир, да.
Не представляю себе как можно работать с базами не понимая как таже база работает с операционкой и железом. Наверное это какие-то специальные DBA?
Хайп да, большой фактор. IT давным давно стал «модным» движением, когда технология часто выбирается исходя из красоты строчки в резюме, а не эффективности ее использования в конкретной задаче.
С другой стороны чем больше людей делает такой выбор тем спокойнее на душе :)
IT непрерывно расширяется и усложняется, поэтому люди из этих самых «сисадминов/девопсов/SRE» постоянно уходят в более тонкую специализацию.
В целом кеширование по TTL не самая умная штука. Под нагрузкой работает, но если нужно существенную часть данных отдавать из кеша, лучше научить приложение ходить вместо базы в memcache / редис / etc

Information

Rating
Does not participate
Works in
Registered
Activity