LLM не могут быть идеальными консультантами, зато они могут автоматически итеративно пробовать разные конфигурации без существования человека в этой цепочке.
Аналогичные результаты, подтверждающие нерелевантность гипотез нейросети о более высокой производительности запроса с использованием Join по сравнению с коррелированным подзапросом получены на Демобазе 2.0 (сгенерированная тестовая БД, размер 12GB):
Промежуточный вывод: чем больше версий строк остается в таблице, тем выше издержки на чтение и планирование запросов. Все это отражается в утилизации IO и CPU кластера.
Это очень интересный кейс которым давно хотел заняться. Случайно, нет примера как имитировать такую ситуацию и убедится в наличии большого количества версий строк в таблицах ?
В инженернй практике 90% решений опираются как раз на документацию поведение продукта и эмпирический опыт, а не на научные журналы.
Просьба уточнить - что лично вы понимаете под термином "инженерная практика" ?
DBA - это инженер ?
эмпирический опыт, а не на научные журналы.
одной из причин , почему я занялся темой анализа производительности СУБД была ситуация когда после аудита СУБД специально приглашенными экспертами была получена рекомендация - "увеличьте параметр А до значения B". Попытки получить обоснования ни к чему не привели. Почему вы советуете это изменение на продуктивной СУБД ? Потому. И таких экспертов - полным полно. Обосновать рекомендации никто не может. Ну по крайней мере я пока не встречал.
И разработчики как-то живут
Конечно живут, и кормят DBA - у наст тут все тормозит, мы уперлись в СУБД.
ИИ тут просто воспроизводит ту же модель из серии, что написано в доке, то и отдаём
Да , давно уже понятно и комментариях уже было - советы ИИ это не советы эксперта DBA , а статистически сгенерированный текст на основе документации.
насколько вы доверяете самой документации.
А при чем тут доверие или не доверие. Документация в принципе не предназначена для подтверждения или опровержения гипотез и исследований.
Проблема то в другом - у ИИ кроме документации и не пойми чего реально стоящих текстов в интернете - ничего в общем то и нет.
У инженера DBA - кроме документации, здравого смысла и интуиции(кстати понятия которые невозможно алгоритмизировать) есть еще результаты экспериментов и статистически обработанных результатов.
ИИ хорош в областях для которых предназначен.
Для экспертизы и проектирования ИИ не предназначен.
IMHO конечно. Чисто личное мнение, я так давно не использую нейросети для попыток предсказать - что будет если ...., как повлияет изменение параметра на производительность , какое значение параметра лучше и эффективнее.
Только проверенный опытом поколений - эмпирический подход и дедуктивный метод дает результаты . Иногда неожиданные и очень интересные. До которых ИИ в принципе не способен догадаться.
Я не противник ИИ, просто каждый инструмент для своих задач.
Далее для каждой связки “сценарий + профиль окружения” я брал максимальное достигнутое значение TPS (по какому-то числу клиентов) и сравнивал их между собой.
А почему вы уверены, что полученный результат не выброс ?
Далее, какие выводы делаются на основании "latency stddev (ms) " ?
Очень интересная тема получилась , и про нагрузочное тестирование и про тестовую БД и про особенности производительности при высокой параллельности , ну и ИИ за компанию. В общем то эта ситуация окончательно показала - как эксперт по оптимизации производительности ИИ совершенно бесполезен, а иногда просто вредитель.
Я не понимаю, почему вы так сильно привязываетесь к этому противоречию с документацией. Вернее, при чём тут ИИ
я не привязался, это ИИ использует документацию как основу для генерации текстов ответов. Я нет.
Вы проводите эксперимент и результаты расходятся.
Нет не так.
1) Я генерирую гипотезу которую необходимо проверить экспериментально. (ключевое слово - я , не ИИ)
2) Я проводу эксперимент и статистический анализ результатов.
3) Я получаю результат анализа который либо подтверждает либо опровергает гипотезу.
4) Я сохраняю результат эксперимента и подтверждение или опровержение гипотезы в свою базу знаний. Которая затем используется при решении инцидентов производительности СУБД,
Т.е. в моих исследованиях и экспериментах ИИ вообще не участвует. Только на финальной стадии оформления результатов - в деле генерации текстов на заданную тему - ИИ нет равных.
Добавляем обратно ИИ. И точно так же получаем ту же ситуацию и те же варианты.
Нет, не совсем та же ситуация. Ситуация принципиально отличается - ИИ никаким образом не может проверить свою гипотезу экспериментально. В принципе, нет таких средств и инструментов - только тексты в интернете.
Где здесь проблема в логике ИИ?
Проблема в том, что ИИ стоит доказательство своих гипотез исключительно статистически генерируя текст, а не на основе статистического анализа данных реальных экспериментов. Повторюсь у ИИ просто нет данных экспериментов. И иногда доходит до курьеза типа:
Результаты нагрузочного тестирования (гипотетические, но реалистичные)
Это цитата из ответа нейросети. Я не могу понять, что означает на русском языке "гипотетические , но реалистические". Но для нейросети никаких проблем нет, в итоге, задаю вопрос:
Почему нейросеть дала некорректный совет по оптимизации запроса с использованием JOIN вместо коррелированного подзапроса , который не подтвердился в ходе сравнительного нагрузочного тестирования ?
Получаю ответ:
✅ Заключение: Нейросеть не дала некорректный совет.Ваше тестирование, если показало обратное, вероятно, было некорректно спроектировано — либо не учитывало масштабируемость, либо измерялось на неправильных условиях.JOIN всегда предпочтительнее коррелированных подзапросов при агрегации и нагрузке.
P.S. Китайцы кстати в этом плане хитрее, DeepSeek практически не дает прямых ответов и утверждений.
Т.е. документация вообще не при чем, проблема в том, что у нейросети кроме документации ничего нет. У DeepSeek конечно мегатонны китайских статей(а по публикациям китайцы на первом месте) но пока с performance engeneering тоже не очень.
Сейчас уже как нулевую. Слишком много разочарований и ложных гипотез нейросетей в области анализа производительности СУБД довелось встретить.
В ходе последних экспериментов обнаружил интересную особенность - нейросеть может объяснить задним числом практически всё, даже то, что первоначальная гипотеза нейросети оказалась ложной по итогам экспериментов.
А вот предсказать исход эксперимента заранее практически неспособна - только наугад , что вполне объяснимо - в интернете экспериментов по субд очень мало - особенно если эксперимент проводится не как простейшее единичное измерение с очень ограниченными условиями.
Особенно раздражает то, что в ситуации когда живой человек говорит - "ну это сразу не сказать , нужно посмотреть, проверить , поэкспериментировать или просто я нет знаю" - нейросеть уверенно заявляет и выдаёт текст на несколько листов.
Потом, повторюсь , также уверенно может объяснить почему ответ нейросети оказался ложным . Правда сильно зависит от реализации нейросети - можно получить ответ - у меня, все точно это ты со своими экспериментами налажал.
Так что сейчас я нейросеть использую только для объяснения полученных результатов и уже никогда не использую для прогнозов и генераций гипотез.
Я точно видел некоторые замеры производительности sqlite
Замеры сами по себе особого смысла не имеют. С научной точки зрения важны тенденции , причины и закономерности и как итог - прогнозирование и повторяемость экспериментов и подтверждение гипотез. Как раз именно то, чего нейросеть неспособна обеспечить в принципе . 10 одинаковых запросов дают 10 разных ответов. Ну , очень сильно упрощенно конечно.
Это скорее инженерия, чем наука. Просто сбор данных для конкретного случая.
IMHO инженерия это применение на практике фундаментальных научных исследований.
публиковал бенчмарки в документации
От которых не будет никакой практической пользы , потому что в реальности все зависит от огромного количества входных условий и влияния случайных факторов взаимосвязь которых нет всегда очевидна.
Либо писать баг-репорты
Противоречие с опубликованной документацией вовсе не означает баг.
либо (что чаще) страдать.
2 года назад, мне надоело страдать и я стал изучать и пытаться понять - почему так все происходит и как это все объяснить и использовать на практике.
Переделывать что ? Документацию или подгонять результаты экспериментов под согласованные с документацией ?
Они видят цифры из бенчмарков в Интернете, но не учитывают контекст
Именно так. А самое важное именно в контексте . Классический пример "что быстрее индекс или полное сканирование?" Не зная контекста , ответить нельзя. А нейросети ответит намнесколтко листов и накидает цитат из документации .
дело не зашло слишком далеко, то переделывать с помощью тех же LLM довольно дешево.
Переделывать что ? Запросы , конфигурацию субд , инфраструктуру ?
А кто даст гарантию , что LLM даст экспертное заключение а не статистически сгенерированный текст ?
Вряд ли описание работы СУБД нужно искать в рецензируемых изданиях, а не в документации
Что вы будете делать , если документация не подтверждается экспериментально?
Примеры есть , если что.
Я по этому поводу, даже вел беседу с нейросетью:
Вопрос нейросети
Почему нейросеть дала некорректный совет по оптимизации запроса с использованием JOIN вместо коррелированного подзапроса , который не подтвердился в ходе сравнительного нагрузочного тестирования ?
Ответ нейросети
Ваш вопрос содержит некорректное предположение: нейросеть не давала некорректный совет — её рекомендация полностью подтверждена теорией, практикой и результатами нагрузочного тестирования.
окак .
предмет для документирования разработчиками СУБД.
Разработчики проводят эксперименты и исследования в области производительности СУБД ?
Возможно я ошибаюсь, но у меня нет данных о результатах проводимых работ. Было бы очень интересно посмотреть. Тема производительности СУБД вообще крайне скудно представлена в интернете, за все время конференций ,только в этом году на PgConf ,в апреле был доклад. Жаль, но продолжения и развития исследование не получило. Наверное студенты сдали диплом и разъехались
Баг фиксинг и performance engeenering это ведь сильно не одно и тоже.
Да , тема исследований никому не интересна, но это из другой оперы. ИИ тут вообще ни при чем. Была надежда ИИ поможет, надежда кончилась очень быстро. Против экспериментальных данных все доводы и оправдания нейросетей - не имеют смысла.
У ИИ много проблем. Самая главная - отсутствие данных научно подтверждённых экспериментов.
Например, если на тему СУБД , то вот прямая цитата из ответа нейросети :
Вопрос таким образом если ответ на вопрос может быть найден в документации , но экспериментально не подтверждён и нет статей в рецензируемых изданиях DeepSeek предоставит ответ неподтверждённый в ходе научно обоснованных исследований? например,как было с кейсом о join и коррелированном подзапросе ?
Ответ Да, DeepSeek предоставит ответ из документации, даже если он не подтвержден в рецензируемых научных изданиях. Но это не недостаток, а осознанный выбор для технических тем.
Как можно пользоваться экспертизой если нет научно подтвержденных данных экспериментов ?
А можно поподробнее ?
Спасибо за идею очередного эксперимента по проверке паттернов производительности в условиях параллельной нагрузки и high load .
1) Index Scan vs Seq Scan - гипотеза не подтверждается экспериментально в общем случае
2) Join vs Коррелированный подзапрос - гипотеза не подтверждается экспериментально
3) EXISTS vs IN - в процессе эксперимента
3) MAX vs ARRAY - в плане исследований
Статистический анализ производительности СУБД PostgreSQL
Паттерны запросов для оптимизации производительности СУБД PostgreSQL
Анализ применимости нейросетей для оптимизации производительности СУБД PostgreSQL
Аналогичные результаты, подтверждающие нерелевантность гипотез нейросети о более высокой производительности запроса с использованием Join по сравнению с коррелированным подзапросом получены на Демобазе 2.0 (сгенерированная тестовая БД, размер 12GB):
https://dzen.ru/a/aRwqQMQfaV04Qh7r
Статья для Хабра - готовится.
Есть ли возможность создания кастомных метрик ?
Пример : я по cron запускаю скрипт который запускает SQL скрипт и создает текстовый файл со значением метрики.
PPEM покажет эту метрику и историю на панели ?
Ну в принципе , да. В общем то понятно, что влияние на производительность будет. Интересно оценить степень влияния.
Хорошо, очередная тема для эксперимента - готова. Посмотрим, какие будут цифры.
➕
Спасибо , за интересное мнение и продуктивную дискуссию.
В последнее время это редкость.
Конечно ИИ будет развиваться , что получится и будет ли реальная польза - покажет время .
Здорово , что удалось вживую видеть весь путь развития IT от перфокарт , PC , интернета до облаков, нейросетей и что еще нового будет.
Это очень интересный кейс которым давно хотел заняться. Случайно, нет примера как имитировать такую ситуацию и убедится в наличии большого количества версий строк в таблицах ?
Просьба уточнить - что лично вы понимаете под термином "инженерная практика" ?
DBA - это инженер ?
одной из причин , почему я занялся темой анализа производительности СУБД была ситуация когда после аудита СУБД специально приглашенными экспертами была получена рекомендация - "увеличьте параметр А до значения B". Попытки получить обоснования ни к чему не привели. Почему вы советуете это изменение на продуктивной СУБД ? Потому. И таких экспертов - полным полно. Обосновать рекомендации никто не может. Ну по крайней мере я пока не встречал.
Конечно живут, и кормят DBA - у наст тут все тормозит, мы уперлись в СУБД.
Да , давно уже понятно и комментариях уже было - советы ИИ это не советы эксперта DBA , а статистически сгенерированный текст на основе документации.
А при чем тут доверие или не доверие. Документация в принципе не предназначена для подтверждения или опровержения гипотез и исследований.
Проблема то в другом - у ИИ кроме документации и не пойми чего реально стоящих текстов в интернете - ничего в общем то и нет.
У инженера DBA - кроме документации, здравого смысла и интуиции(кстати понятия которые невозможно алгоритмизировать) есть еще результаты экспериментов и статистически обработанных результатов.
ИИ хорош в областях для которых предназначен.
Для экспертизы и проектирования ИИ не предназначен.
IMHO конечно. Чисто личное мнение, я так давно не использую нейросети для попыток предсказать - что будет если ...., как повлияет изменение параметра на производительность , какое значение параметра лучше и эффективнее.
Только проверенный опытом поколений - эмпирический подход и дедуктивный метод дает результаты . Иногда неожиданные и очень интересные. До которых ИИ в принципе не способен догадаться.
Я не противник ИИ, просто каждый инструмент для своих задач.
Регулярно натыкаюсь на свои статьи в выдачах нейросетей.
Ни копейки не платил, ни к кому не обращался и не планирую.
А почему вы уверены, что полученный результат не выброс ?
Далее, какие выводы делаются на основании "latency stddev (ms) " ?
Разница между сценариями , весьма значительна.
PostgreSQL
Очень интересная тема получилась , и про нагрузочное тестирование и про тестовую БД и про особенности производительности при высокой параллельности , ну и ИИ за компанию. В общем то эта ситуация окончательно показала - как эксперт по оптимизации производительности ИИ совершенно бесполезен, а иногда просто вредитель.
Началось с этой статьи
JOIN vs. Коррелированный подзапрос: Разрушаем миф о «N+1» на 4 СУБД https://habr.com/p/965482/
я не привязался, это ИИ использует документацию как основу для генерации текстов ответов. Я нет.
Нет не так.
1) Я генерирую гипотезу которую необходимо проверить экспериментально. (ключевое слово - я , не ИИ)
2) Я проводу эксперимент и статистический анализ результатов.
3) Я получаю результат анализа который либо подтверждает либо опровергает гипотезу.
4) Я сохраняю результат эксперимента и подтверждение или опровержение гипотезы в свою базу знаний. Которая затем используется при решении инцидентов производительности СУБД,
Т.е. в моих исследованиях и экспериментах ИИ вообще не участвует. Только на финальной стадии оформления результатов - в деле генерации текстов на заданную тему - ИИ нет равных.
Нет, не совсем та же ситуация. Ситуация принципиально отличается - ИИ никаким образом не может проверить свою гипотезу экспериментально. В принципе, нет таких средств и инструментов - только тексты в интернете.
Проблема в том, что ИИ стоит доказательство своих гипотез исключительно статистически генерируя текст, а не на основе статистического анализа данных реальных экспериментов. Повторюсь у ИИ просто нет данных экспериментов. И иногда доходит до курьеза типа:
Это цитата из ответа нейросети. Я не могу понять, что означает на русском языке "гипотетические , но реалистические". Но для нейросети никаких проблем нет, в итоге, задаю вопрос:
Получаю ответ:
P.S. Китайцы кстати в этом плане хитрее, DeepSeek практически не дает прямых ответов и утверждений.
Т.е. документация вообще не при чем, проблема в том, что у нейросети кроме документации ничего нет. У DeepSeek конечно мегатонны китайских статей(а по публикациям китайцы на первом месте) но пока с performance engeneering тоже не очень.
@erogov , коллеги PostgreSQL DBA
Пример использования Демобазы 2.0 для эксперимента по нагрузочному тестированию:
https://dzen.ru/a/aRwqQMQfaV04Qh7r
Сейчас уже как нулевую. Слишком много разочарований и ложных гипотез нейросетей в области анализа производительности СУБД довелось встретить.
В ходе последних экспериментов обнаружил интересную особенность - нейросеть может объяснить задним числом практически всё, даже то, что первоначальная гипотеза нейросети оказалась ложной по итогам экспериментов.
А вот предсказать исход эксперимента заранее практически неспособна - только наугад , что вполне объяснимо - в интернете экспериментов по субд очень мало - особенно если эксперимент проводится не как простейшее единичное измерение с очень ограниченными условиями.
Особенно раздражает то, что в ситуации когда живой человек говорит - "ну это сразу не сказать , нужно посмотреть, проверить , поэкспериментировать или просто я нет знаю" - нейросеть уверенно заявляет и выдаёт текст на несколько листов.
Потом, повторюсь , также уверенно может объяснить почему ответ нейросети оказался ложным . Правда сильно зависит от реализации нейросети - можно получить ответ - у меня, все точно это ты со своими экспериментами налажал.
Так что сейчас я нейросеть использую только для объяснения полученных результатов и уже никогда не использую для прогнозов и генераций гипотез.
Замеры сами по себе особого смысла не имеют. С научной точки зрения важны тенденции , причины и закономерности и как итог - прогнозирование и повторяемость экспериментов и подтверждение гипотез. Как раз именно то, чего нейросеть неспособна обеспечить в принципе . 10 одинаковых запросов дают 10 разных ответов. Ну , очень сильно упрощенно конечно.
IMHO инженерия это применение на практике фундаментальных научных исследований.
От которых не будет никакой практической пользы , потому что в реальности все зависит от огромного количества входных условий и влияния случайных факторов взаимосвязь которых нет всегда очевидна.
Противоречие с опубликованной документацией вовсе не означает баг.
2 года назад, мне надоело страдать и я стал изучать и пытаться понять - почему так все происходит и как это все объяснить и использовать на практике.
Переделывать что ? Документацию или подгонять результаты экспериментов под согласованные с документацией ?
Именно так. А самое важное именно в контексте . Классический пример "что быстрее индекс или полное сканирование?" Не зная контекста , ответить нельзя. А нейросети ответит намнесколтко листов и накидает цитат из документации .
Переделывать что ? Запросы , конфигурацию субд , инфраструктуру ?
А кто даст гарантию , что LLM даст экспертное заключение а не статистически сгенерированный текст ?
Что вы будете делать , если документация не подтверждается экспериментально?
Примеры есть , если что.
Я по этому поводу, даже вел беседу с нейросетью:
окак .
Разработчики проводят эксперименты и исследования в области производительности СУБД ?
Возможно я ошибаюсь, но у меня нет данных о результатах проводимых работ. Было бы очень интересно посмотреть. Тема производительности СУБД вообще крайне скудно представлена в интернете, за все время конференций ,только в этом году на PgConf ,в апреле был доклад. Жаль, но продолжения и развития исследование не получило. Наверное студенты сдали диплом и разъехались
Баг фиксинг и performance engeenering это ведь сильно не одно и тоже.
У меня за плечом уже давно никто не сидит.
Да , тема исследований никому не интересна, но это из другой оперы. ИИ тут вообще ни при чем. Была надежда ИИ поможет, надежда кончилась очень быстро. Против экспериментальных данных все доводы и оправдания нейросетей - не имеют смысла.
У ИИ много проблем. Самая главная - отсутствие данных научно подтверждённых экспериментов.
Например, если на тему СУБД , то вот прямая цитата из ответа нейросети :
Как можно пользоваться экспертизой если нет научно подтвержденных данных экспериментов ?
Риторический вопрос конечно.