Подробнее
Может ли ИИ написать эффективный 5ф1--запрос?
А ты, типа, можешь?
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,sql,Искусственный Интеллект
Будьте реалистами, если запрос делает то, что вы от него хотите, то он эффективный. Многомиллионные корпорации не парятся, с чего обычным людям от этого в депрессию впадать.
Корпорации покупают новые сервера на сдачу от офисного кофе. Им не нужна эффективность, им нужно "завтра у меня отчет о проделанной работе, сделай к сроку".
А еще забыл, все отчеты на вчера и позавчера, делаются из массива благородного дерева с щепоткой удобрения благородных животных и с мыслями: потом перепишу нормально (с)
Помню как-то начальник начальника пришёл ко мне и начал спрашивать ,почему они не получают значения учёта нового продукта, который запустили на прошлой неделе. Было забавно, ведь ни я, и даже мой непосредственный начальник, не были в курсе, что они вообще что-то новое запускали.
Как обычно, директор что-то решил, дали срок месяц и пустили всё по цепочке вниз. Каждое звено отжирало неделю на перекладывание всяких бумажек и планирование ахуенных работ. А потом приходят к тебе и "ты ещё неделю назад должен сделать вот это".
VM - это VirtualBox, да всё верно, oracle linux ОЧЕНЬ часто используется особенно из за того, что он неплохо заточен под aws, хотя у них и свой дистр есть.
нет никаких эффективных запросов. Есть оптимизированные запросы, а задача оптимизации - это не "пальцем в небо" и не "у меня высокая экспертиза, я могу написать", а банальный поиск оптимума... а в этом машина безусловно превосходит человека. Так что больше на "приколы для даунов" смахивает.
Эм... Так то машина как раз ищет этот оптимум при составлении плана выполнения запроса, и если бы она "безусловно превосходила человека", то человек бы потом не занимался оптимизацией этого плана
ну так а машину, которая составляет план, кто пишет? А? А? Конечно, мы же помним про энтропию Шеннона - если человек созадет алгоритмическую машину, то именно он и вкладывает в нее информацию, поэтому машина на уровне "уметь все" человека не превосходит... но на уровне той алгоритмической задачи, которая ей поставлена, с учетмо кол-ва информации, заложенной программистом - в разы, в десятки раз, в сотни.
машина может тупо следовать инструкциям и иногда сама себя может перехитрить, особенно когда ей начинают сильно усложнять эти инструкции, этот поиск оптиума тоже пишется несовершенными людьми
приведу пример в 19ом оракле на основе сбора статистки по таблице оракл может перестраивать план запроса по щучьему велению
и когда в таблице 100 записей или пара миллионов это большая разница и этот перестроенный план может выстрелить в ногу
приходится хинтовать свои скрипты и прибивать свой план запроса гвоздями
Хаха, если бы.
Оптимизаторы нынче неплохи, но перестраивать целиком структуру запроса, что порой приводит к оптимизации порядков на 5, не умеет.
Как и анализировать не структуру, а непосредственно суть данных, чтобы поменять запрос, более оптимальный для конкретных данных именно вот в этой таблице именно сейчас.
мы же понимаем ,что в исходном "меме" ни слова про оптимизацию структуры запроса, а про "написание эффективного sql-запроса". Машина может написать "эффективный sql-запрос" просто потому что в принципе декларативный язык допускает оптимизаионный поиск.
А вы мне все пытаететсь рассказать про то как сейчас линейно устроена планирование запроса на уровне БД. Ну ок, так то еще в 60-х изобреталось :)
Вопрос трудящимся, какой есть годный материал для вкуривания про оптимизацию с SQL? Базовое понимание того, как оно работает у меня есть, равно как и работаю с ним активно второй год. Но любой рекомендации буду рад
Спасибо, да, индекс - хорошая вещь. Настолько, что у меня в базе есть таблица с парой миллионов строк и 50 столбцами, и на 80% она состоит из индексов. Прямые запросы к ней - ок бро, но стоит делать join‘ы с другой таблицей или, упаси боже, вставленные SELECT’ы в запросе/модификации - и оракл говорит: «я буду это делать 20 минут (хотя, стоимость исчисляет десятками тысяч операций, что по идее должно длиться секунды), за это время успеешь несколько раз сходить нахуй».
Разбирал по кирпичикам, проблема стреляет именно с join’ами
Не всегда решение в индексах или performance tuning'е самой бд, иногда приходится денормализировать таблицы или использовать clustered таблицы. От дисковой подсистемы опять же многое зависит. В идеале чтобы БД была на SSD и не на copy-on-write файловой системе.
Короче вопросы по БД это такая вещь где в общих чертах можно много чего посоветовать, но для дельных советов надо знать и структуру БД и запросы которые тормозят.
Все это понимают, но на собесе тебя про грааль плана запросов и тот самый идеальный селект в HL системе будут спрашивать, который все за 1нс выдает. А ты на должность уборщика метил
Собесы это вообще отдельная боль. У тебя может быть проект на гитхабе с тысячей звезд, который о твоих способностях говорит больше, чем любые вопросы, но вместо того чтобы слегка отойти от стандартного процесса и зайти к тебе на гитхаб тебе все равно будут трахать мозг какими-то базовыми вопросами ответить на которые ты не можешь банально потому что либо делаешь это на подсознательном уровне, либо какими-то терминами за свою практику ты не пользовался даже если используешь это каждый день.
Хочется тебе дорогой выпивки купить! Ты заговорил и попал в самое сердце. Но с другой стороны это и кандидатов оберегает: либо у тебя прикольный коллектив, либо деревянные нёрды с блестяще вызубреннлй теорией и ебаным продуктом
Ты удивишься, но...
Например, в колоночной распределенной базе, обычный column scan работает чаще всего быстрее, чем индекс. О чём, впрочем, прямо написано в документации, и почему так - тоже.
Так что не бывает универсальных советов, тем более, что индексы ебать как не бесплатны, если у тебя данные насираются миллионами строк в минуту.
Shurick Agapitov 31 Jul
• • •
Вы получили это письмо, потому что моя команда биг дата проанализровала ваши активности в жире, конфлюенс, гугл почте, чате, документах, дашбордах и пометила вас как невовлечные и малопродуктивные сотрудники, иными словами вы не всегда присутсвовали на рабочем мест
Глава Xsolla объяснил, как выбрали 147 неактивных сотрудников
atomlib
4-6 minutes
Александр Агапитов. Фотография: Xsolla
Основатель и руководитель компании Xsolla Александр Агапитов рассказал «Форбсу» детали о массовом увольнении сотрудников в пермском офисе компании. Агапитов также ответил на
потому что порой нужно сделать к __позавчера__ или ранее.
Как обычно, директор что-то решил, дали срок месяц и пустили всё по цепочке вниз. Каждое звено отжирало неделю на перекладывание всяких бумажек и планирование ахуенных работ. А потом приходят к тебе и "ты ещё неделю назад должен сделать вот это".
Скрипты работают? - Работают. Всё - релизим.
приведу пример в 19ом оракле на основе сбора статистки по таблице оракл может перестраивать план запроса по щучьему велению
и когда в таблице 100 записей или пара миллионов это большая разница и этот перестроенный план может выстрелить в ногу
приходится хинтовать свои скрипты и прибивать свой план запроса гвоздями
Оптимизаторы нынче неплохи, но перестраивать целиком структуру запроса, что порой приводит к оптимизации порядков на 5, не умеет.
Как и анализировать не структуру, а непосредственно суть данных, чтобы поменять запрос, более оптимальный для конкретных данных именно вот в этой таблице именно сейчас.
А вы мне все пытаететсь рассказать про то как сейчас линейно устроена планирование запроса на уровне БД. Ну ок, так то еще в 60-х изобреталось :)
Разбирал по кирпичикам, проблема стреляет именно с join’ами
Короче вопросы по БД это такая вещь где в общих чертах можно много чего посоветовать, но для дельных советов надо знать и структуру БД и запросы которые тормозят.
Например, в колоночной распределенной базе, обычный column scan работает чаще всего быстрее, чем индекс. О чём, впрочем, прямо написано в документации, и почему так - тоже.
Так что не бывает универсальных советов, тем более, что индексы ебать как не бесплатны, если у тебя данные насираются миллионами строк в минуту.