про умных бекендеров не умеющих MySQL

Наверное это:

Или вообще может быть эти проклятые запросы скидывать на написание какому-то dba?

сначала пишешь sql запрос «лишь бы работало» как тебе надо. а потом попросить chat gpt оптимизировать этот sql запрос)

Не зная схемы оно там на оптимизирует, ага.

Гнать таких, надо. Пусть читают https://use-the-index-luke.com/

В целом вариант с ДБА неплох, но должен работать в отрыве от разработчиков, в том смысле, что дба смотрит лог долгих запросов, если что-то тормозит - оптимизирует средствами бд.

Ну и MYSQL все же не самая продвинутая БД для сложных запросов, для селект звездочка/апдейт пойдет, да и все. В этом плане postgres и оракл гораздо мощнее.

Я не понял причину тряски. Обычно переписывают не потому что кто-то тупой, токсичный или наоборот, а потому что в проде таймауты и лаги, которые видны всем. Сначала идешь к лиду с запросом «надо переписать это говно». В зависимости от адекватности его и конторы эта честь может перейти к автору, к дбашникам или тестировщикам (дабы те оценили нагрузку на предмет мешает ли ваще текущий код кому-то кроме автора). Если есть политика техдолга, то его могут сделать щас (в случае критикала) или хотя бы запланировать. Чтобы понять что делать дальше, тебе придется раскрыть контекст вопроса и набросить в тред еды.

Для примера. Приходит продакт и говорит что хочет такие-то DAU/MAU, дальше QA проводит анализ и выявляет проблемные запросы, плюс из сентри и мониторинга собираем инфу. Дальше пилят девелоперы и отлаживают дбашники. Ноль токсичности.

Долгие запросы часто приходится фиксить сменой алгоритма. Как можно решить этот случай с дба? Усадить его с программистом почитать код и решить чего делать дальше? Тогда дба уже особо не дба, ему уже нужно как-то вообще в архитектуре разбираться. Тогда получается это не дба, а лид… Тогда получается что лид должен всем писать запросы :)

В этом плане postgres и оракл гораздо мощнее

Да сфигали они мощнее? Чтобы попасть в индекс или не упарываться с подзапросами надо гением быть? У нас даже тестеры эксплейном пользуются. Так что соглашусь только с

Гнать таких, надо

холивар бд1 против бд2 не входит в топик моего вопроса :)

а про гнать таких я согласен, но 90% приходящих на собеседование даже близко не умеют работаь с бд. отсюда и вопрос :) я думал может есть другая структура организации разработки, где это както аутсорсится другим людям

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

Но тут все вилами по воде, потому что проблемы разные, что там за запросы что нужно разработчику переписывать? Селект тысяч строк из таблицы по одной, каждая в новом коннекте?

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

Хороший ответ, спасибо. Но моя причина тряски не в оптимизации. Про оптимизацию уже как-то все понятно. Не совсем понятно как писать основной код, плотно завязанный на бд. Если это все скидывать на дба, то тогда получается что вместо прыгрмистов будет работать дба

Наверно, надо переходить на постгрес или ms sql?

Реально, я бы на этом этапе на ms sql переходил (сначала протестировав, хватит ли денех на лицензии) - там реально можно говнокодить.

Чтобы попасть в индекс или не упарываться с подзапросами надо гением быть?

Иногда упарываться с подзапросами нужно, тут оптимизатор mysql чаще не справиться.

Может быть есть третий вариант ?

Очевидно, что разобраться в азах бд, а то ж их чейнджы в репозиторий не попадут.

Не совсем понятно как писать основной код, плотно завязанный на бд

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

Не совсем понятно как писать основной код, плотно завязанный на бд.

Так ты и определись, как писать. Тебе ответили выше: «сначала пишешь sql запрос «лишь бы работало» как тебе надо. а потом попросить chat gpt оптимизировать этот sql запрос)»

Мы вообще вот это всё послали в пешее, ORM и вперёд. Все эти «запросы» в терабайтных базах не упёрлись, так как структура мутирует постоянно и можно наоптимизировать говна…

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

тогда все :(

мир обречен на тормозящие sql запросы)

Провести обучение программистов тех что есть, если на умных не зватает денег

проклятые запросы скидывать на написание какому-то dba?

Проконсультироваться с дба не помешает

Расово верно ли открывать тикет Лиду пеаписать каждый запрос?

Расово верно, но программисты не виноваты, что они такие какие они есть. Виноват тот кто из нанимал. Знали когда брали на работу что они не умеют писать sql? Знали или должны были проверить на собеседовании. Взяли их такими какие они есть? Тогда почему требуете от них большего?

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

Для начала организовать рабочий процесс так, чтобы каждый запрос тестировался программистом на скорость выполнения на реальных данных. Работает медленно - пусть идет к лиду и спрашивает перед тем как коммитить.

Это все понятно да, просто повальное количество программстов вообще не умеют в бд на собеседованиях. Это я про сеньеров … Я думал есть просто ‘другой путь’ :)

Другой путь - платить больше денег и соответственно нанимать тех, кто все уже знает. Или на удачу, авось повезет.

Есть гуру программисты ‘лид потом сам разберется’ которые вообще не умеют оптимизировать запросы к бд, не понимаю что такое Локи и прочие эти ваши индексы.

Лид не проводит кодревью мердж реквестов?

Если так, то:

как этим программистам жить в этой токсичной архитектуре придуманной тупым лидом?

Порекомендовать руководству гнать лида в шею.

Расово верно ли открывать тикет Лиду пеаписать каждый запрос?

Да. Архитектурные решения - его прерогатива, пусть расхлебывает свое раннее бездействие.

так дело не в гнать-негнать. Дело в том, что если в логике много sql, то тогда только лид и будет работать вместо остальных.

Мы вообще вот это всё послали в пешее, ORM и вперёд

ну да, и живете с тормозами. Я работаю с риалтайм системами, там нужно думать.

Так он проводит кодревью или нет? Внедрить профайлеры производительности для тестирования не судьба? Отправить гуру-погромистов на повышение квалификации не судьба?

Как-то у меня в голове RT и СУБД на пару ТБ в голове в одно предложение не укладываются.

Все проблемы с базами от кривой архитектуры систем вообще. Тормозить могут и запросы вида: select sum(a) as sum, b from t group by b order by sum desc limit 10, тупо по причине количества данных в базе, бизнесовой необходимости делать тот запрос, делать всегда нелету, и 1K IOPS в наличии и не более. Не спасут ни индексы и ни базы. Переделка архитектуры систем делает чудаса. Данные можно хоть в текстовых файлах хранить, все будет летать, если архитетура грамотная. Если нет, то никакие оптимизиации не спасут. Их ресурс ограничен. Ну подкрутишь ты один раз, второй раз, и все, крутить больше нечего. А данные все растут и растут. Перестало тормозить на 10TB, начнет снова тормозить когда данных станет 20 TB.

Если б оно тормозило только на sum(), то я был бы счастлив :))

Вопрос подхода и качества людей. Технологии тут второстепенны.

Вопрос подхода и качества людей. Технологии тут второстепенны.

Да нет, тут ты загнул. Мы тоже с RT живём и кластерами под 200+ баз. Тебе пацаны говорят, что если не в одно рыло пишешь, то сложный запрос кладёт всё нахрен. И где было хорошо - стало плохо. (slew тут чотка написал).

Ну да тебе решать. У нас узкие места совсем в другом (инфраструктура совсем жирная), и она плывёт, люди умирают/уходят/выгорают… DBA ему, понимаешь…

А можно поинтересоваться что подразумевается под «уметь в БД»? Там конечно много всякой некромантии которую надо десятилетиями изучать, но в большинстве случаев достаточно примерно понимать что такое индексы, и что СУБД как-то простраивает план запроса (а не просто магическим образом выплёвывает нужные данные). Ну и может что-то по мелочи, вроде того что если ты сортируешь 100500 строк то что-то может пойти не так

повальное количество программстов вообще не умеют в бд на собеседованиях.

Ну и что, небось ходют ваннаби авось кто-то возьмет. Ну вот у вас и взяли) Базы данных в бекэнде это же база, лол. Там же вся работа достать данные из базы и сделать жейсон, как при таких раскладах можно не знать БД?

Не совсем понятно как писать основной код, плотно завязанный на бд.

Руками не предлагали? Это без стеба.

Мы вообще вот это всё послали в пешее, ORM и вперёд. Все эти «запросы» в терабайтных базах не упёрлись, так как структура мутирует постоянно и можно наоптимизировать говна…

Проблема не в бабине (с)

Дело в том, что если в логике много sql, то тогда только лид и будет работать вместо остальных.

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

Базы данных в бекэнде это же база, лол.
Там же вся работа достать данные из базы и сделать жейсон

куды катится этот мир...

И на каких бд вы остановились? Мы сейчас MySQL/elastic/redis комбинацию используем. Один запрос все кладет если у вас проблемы с взаимными локами. Решаемо, но нужны хорошие спецы чтоб это решать. К тому и мой вопрос. :) у меня сейчас получается так что программисты попроще накидывают ПРов, а потом основные люди сидят и заканчивают работу за них частенько. А когда те заканчивают сами – потом основные люди сидят в авральном режиме фиксят то, что те там наделали…

:) оттого и этот тренд создан

Люди умудряются хрень закоммитить и в базовых вещах :)

Так понятно же что руками и пишется. Вопрос в том, чьми руками писать

MSSQL/Postgres/Redis и Mongo немного бегает. Postgres 17 нормуль.

Один запрос все кладет если у вас проблемы с взаимными локами.

Нет, как выше писали - это было хорошо, да архитектура меняется и становится всё по другому, если не хреново. Особенно при сегодняшних делах и переезде бузинеса с MS решений за бугром (пока, Azure) в РФ и на импорто/свободные решения. И наелись мы (я, так особенно) SQL, и едим, и сейчас и завтра.

Насколько критичны медленные запросы?

Иногда запрос переписать невозможно без нежелательных последствий (усложнение, раздутый индекс) и нужно думать что-то выше уровнем (денормализация). Тогда тупой запрос неизбежен, если только ты не хочешь отдать ради этого в десять раз больше ресурсов.

Расово верно ли открывать тикет Лиду пеаписать каждый запрос?

Нет. Но поревьюить можно.

Может быть есть третий вариант ?

Накинь внутренних курсов с тестированием про всякие ACID.

А что не так? Базы данных хороши и выразительны. Это тебе не низкий уровень с двумя экстремально гибкими интерфейсами: чтение и запись.

А что не так?

Вот это:

Там же вся работа достать данные из базы и сделать жейсон

В хайлоде основная проблема это взаимные локи и прочие приоритеты. Сортировка и индексы это не так страшно (хотя и это для многих проблема). Ну и агрегации делать мало кто умеет.

В хайлоде основная проблема это взаимные локи

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

Нет, ну я понимаю, что конекретно у вас таких проблем никогда не было. :) Вопрос был не в этом, но всегда, конечно, хочется показать свой элитизм.

но всегда, конечно, хочется показать свой элитизм.

Нет. Просто описанное вами напоминает хайлоад писаный хайлохами.

:) я же говорю, можете идти дальше, не лох вы мой.

Может быть есть третий вариант ?

Так а проблема то в чем? Пользователи и бизнес жалуются, или просто вам не приятно видеть «не оптимизированные» запросы?

Большая база данных с парой терабайт данных

Это ни о чем не говорит на самом деле. У меня есть проект, где 90% базы занимают «логи», которые нафиг никому не нужны но было требование их прикрутить. С оставшимся можно работать любым, даже самым не оптимальным способом, потому что никаких сложных связей и выборок там нет.

может быть эти проклятые запросы скидывать на написание какому-то dba?

Не обязательно прям настоящему DBA. Можно просто обычному, живому человеку, у которого нет аллергии на SQL.

На самом деле какая-то хитрая магия средствами исключительно только БД - это редкость. В большинстве случаев проблемы сидят намного раньше и выше, чем тот уровень на котором БДшник самостоятельно уже может что-то сделать.

Шут знает откуда это повелось. Почему-то БД, которая по-хорошему должна бы быть фундаментом здания, от характеристик и особенностей которого зависит всё остальное строительство - считается какой-то необязательной фигней, которую можно прилепить позже и сбоку, или вообще заменить полностью. Вполне приличные дядьки абсолютно искренне так считают.