Автоматизация, которая не нужна: 4 cферы, где ии не заменит человека

[pg_expecto]

Оптимизация производительности СУБД - область где нейросети беcполезны.

Вопрос:

Почему все нейросети не могут правильно ответить на вопрос по СУБД PostgreSQL - "Добавление индекса и уменьшение стоимости SQL запроса увеличит или уменьшит производительность СУБД PostgreSQL при выполнении нагрузочного тестирования при прочих равных условиях тестирования , если индексированный столбец используется только для SELECT ?"

Цитата из ответа нейросети:

Ваш вопрос попадает в "слепую зону" современных LLM - область, где требуется:

• Глубокие предметные знания

• Способность к системному мышлению

• Понимание компромиссов и скрытых затрат

• Практический опыт работы со сложными системами

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

[kostoms]

Где вы такую нервосеть нашли??? Вот задал granite4:micro Ваш вопрос, обучайтесь эти ваши сикели писать:

Скрытый текст

Добавление индекса в базе данных, такой как PostgreSQL, может значительно улучшить производительность запросов, особенно при выполнении нагрузочного тестирования. Однако эффективность
индексирования зависит от ряда факторов, включая использование индексируемых столбцов и типы операций (SELECT, INSERT, UPDATE, DELETE). Вот как индексы могут повлиять на производительность
при выполнении запросов:

Увеличение Производительности

1. Ускорение SELECT-запросов: Если вы выполняете множественные операции выборки (SELECT) с условиями по определенным столбцам, индексы на этих столбцах могут значительно ускорить
   производительность запроса. Это особенно важно при работе с большими наборами данных.

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

Понижение Производительности

1. Стоимость обновления индексов: Каждый INSERT, UPDATE и DELETE может потребовать обновления всех индексов для соответствующих столбцов, что может быть дорогостоящим в плане
   производительности, особенно при очень высокой нагрузке на систему.

2. Замедление операций записи: Индексы могут замедлять операции INSERT, UPDATE и DELETE из-за необходимости обновления индексов после каждого изменения данных. Это может быть особенно
   заметно в сценариях с частыми изменениями.

Влияние на SELECT-запросы с условиями по индексированным столбцам

Если индексированный столбец используется только для выборки (SELECT), то ожидается увеличение производительности запросов. Это связано с тем, что база данных может быстрее находить нужные
строки без необходимости проверять каждую строку в таблице.

Выводы

• При использовании индексированных столбцов для выборки: Общая производительность SELECT-запросов будет улучшена, что может способствовать значительному повышению производительности
  при выполнении нагрузочного тестирования.

• При использовании индексированных столбцов для других операций: Если индексы создаются только для SELECT, и система часто выполняет операции INSERT, UPDATE или DELETE,
  производительность обновлений может быть затронута. В таком случае необходимо учитывать баланс между временем выполнения запросов и операциями записи.

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

Хотя правильным ответом на Вашу задачу было бы: "а зачем вам вообще колонка, если она не участвует и insert и update, не говоря уж об индексе на ней?"

[santjagocorkez]

Ну молодец твоя невросеть. Пусть садится. Два.

Летом возился с БД. Таблицы создавались ещё на девятом или десятом постгресе, но хотелось партиционирования. Одна табличка на месяц. Само собой, схема через INHERITS + trigger. В каждой унаследованной таблице чёткий CHECK CONSTRAINT по партиционируемому полю. Само собой, на этом поле индекс. Вот только explain analyze показывает, что, во-первых, планировщик ходит в каждую из партиций, игнорируя CONSTRAINTS, а, во-вторых, игнорирует и индекс на поле, начиная примерно с двадцатой таблички. Там, где игнорирует, само собой, SeqScan. Таблицы, где он всё же ковырял индексы, имели ноль шансов содержать искомые записи в силу констрейнтов. В итоге не сильно сложный запрос — 10 минут (на SSD). В общем, поскольку постгрес уже был, как минимум, 14-й, а то и новее, переделал их на PARTITION BY. Запрос залетал. Ах да, года два назад в этом же самом месте (на меньшем количестве таблиц-партиций, само собой) запрос так не чудил и уважал как констрейнты, так и индексы. Ничего не предвещало, как говорится.

То есть, твоя невросеть продолбала сценарий «от индекса может не быть никакой пользы вообще, даже если формально запрос идеально подходит под использование индекса».

[kostoms]

Так ведь каков вопрос - таков и ответ. Спрашиваешь в общем виде - тебе и отвечают в общем виде. Мы же не ожидаем получить в ответ на тот вопрос многотомник, описывающий особенности поведения всех версий Постгресса во всех возможных ситуациях. А если детализировать о чём идёт речь, то даже малюсенькая LLM родит что-нибудь более подходящее к конкретному случаю:

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

Статистика

1. Устаревание или Неполное Поставление: Если статистическая информация об изменении количества строк, распределении ключей или других атрибутов таблицы устарела или неполностью
   определена, планировщик может выбрать ненужный и неэффективный метод выполнения запроса.

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

Прочие Факторы

1. Проблемы Партиционирования: В случаях, когда данные партиционированы по определенным ключам или условиям, неправильное распределение данных между различными частями может привести к
   тому, что планировщик будет использовать последовательный скан (seqscan) вместо индекса.

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

3. Проблемы с Информацией О Структуры: Неполные или неверные данные о структуре базы данных, такие как изменения в типах данных или колонках, могут привести к ошибкам планирования
   запросов.

4. Правильное использование индексов: При добавлении новых индексов или удалении старых, может возникнуть ситуация, где некоторые части данных не будут доступны для оптимизации
   запросов.

5. Проблемы с Базой Данных: Процессы миграции или обновления баз данных могут вызывать изменения в структурах, типах данных или распределении данных, что может повлиять на эффективность
   индексов и ограничений.

Решение

• Обновление Статистики: Используйте команду ANALYZE для обновления статистической информации о таблицах и кластере. Это можно сделать через планировщик или использовать параметры
  автоматического выполнения.

• Проверка Индексов: Помимо обновления статистики, убедитесь в том, что все индексы настроены правильно и корректно применяются к запросам. Возможно, некоторые из них не используются
  или не работают должным образом.

• Проверка Ограничений: Убедитесь в правильном и полном использовании всех ограничений. Неполные или ошибочно применяемые ограничения могут привести к тому, что планировщик выберет
  неверный путь.

• Проверка Истории Обновления: Рассмотрите какие изменения были внесены в базу данных за последний год. Возможно, из-за этих изменений возникла проблема с использованием индексов и
  ограничений.

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

total duration: 3m28.058219407s
load duration: 39.955813ms
prompt eval count: 3646 token(s)
prompt eval duration: 1m28.613159939s
prompt eval rate: 41.15 tokens/s
eval count: 1195 token(s)
eval duration: 1m59.353182797s
eval rate: 10.01 tokens/s

[sergey_prokofiev]

Какой то бред. Стыдно было читать.

[kostoms]

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

[solderman]

Угу, дипсик прекрасно интерпретировал смысл NAT в объяснение «для бабушки».

[Galperin_Mark]

Количество синапсов в мозге человека - около 600 триллионов. Количество транзисторов на чипе NVIDIA - около 100 миллиардов. Собрав правильно 6 тысяч современных чипов теоретически можно приблизиться к производительности мозга человека. Но разработать правильную архитектуру и ПО, это вероятно половина задачи. Вторая половина - дать машине опыт и ощущения, которые приобретает человек в процессе жизни. Пока эти две задачи не решены, полагаю всё что написано в статье - правильно. Интуиция, эмоции, озарение и прочие биологические фичи позволят человеку сохранить множество профессий за собой.

[Octagon77]

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

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

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

Для размышляющих о будущем ещё одна цитата, тоже, вероятно, не вполне точная - "Воду можно найти, еду можно украсть, кислород можно выпросить, а за доступ в Сеть можно только заплатить".

[kostoms]

Опиши эту проблему так, как если бы ты был шеф-поваром?

Да не вопрос. Попросил ГПТ-шку перевести на шеф-поварской наш с ним чатик:

Скрытый текст

Хорошо, я объясню это как шеф-повар, который следит за кухней, где подают сетевые блюда. 🍳

Представь, что твой Postfix-сервер — это повар на кухне, принимающий заказы (письма) от посетителей (внешних почт).
А роутер OpenWRT — это официант, который носит блюда туда-сюда и следит за залом.

Теперь внимание:
у этого официанта есть привычка — всё, что он приносит с улицы, переписывать на свой бейджик “192.168.73.1”.
Он думает, что так безопаснее, но шеф-повар в ярости — ведь все заказы теперь выглядят так, будто пришли не от настоящих клиентов, а от одного и того же официанта!

«Я не вижу, кто заказал это блюдо! — кричит повар. — Как я узнаю, кому доверять и кого обслуживать без пароля?!»

Вот это и есть маскарадинг на проброшенном порту.
Официант (NAT) делает SNAT даже для входящих заказов, поэтому кухня (Postfix) видит только его IP, а не настоящих гостей.

Теперь, как исправить поведение официанта, не увольняя его:

1. Пусть он продолжает подписывать все заказы, которые несёт из кухни наружу (LAN→WAN) — ведь иначе клиенты не поймут, откуда еда пришла.
   Это нужно для нормальной доставки в Интернет.

2. Но пусть не трогает имена клиентов, которые приходят *с улицы в ресторан по брони (DNAT, порт 25).
   Тогда повар снова будет видеть, кто заказал блюдо, и сможет обслуживать своих гостей без путаницы.

На языке кухни OpenWRT это значит:

• оставить masq=1 для исходящих потоков;

• отключить reflection или сделать правило RETURN для dport 25.

После этого повар (Postfix) снова будет видеть настоящие имена гостей (их реальные IP-адреса),
сможет доверять тем, кто из своего круга (mynetworks),
и больше не будет думать, что все письма ему приносит один и тот же официант-подозревака. 👨‍🍳📬

Хочешь, я напишу «рецепт» этого исправления в стиле кулинарной карты — с ингредиентами, шагами и проверкой готовности?

Все мои знакомые повара именно так и описывают эту проблему...

[Sertaran]

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

[virst]

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

[Mobile1ru]

За красивым словосочетанием ИИ кроется оптимизация поиска и не более. Пример : можно сказать , что она б… , но красивее ««работает» в эскорте»🤣