Серия «ITшное»

Какого цвета стоп кран в самолете ?

Блин, искусственный интеллект гпупее ребёнка, мы этот прикол ещё в садике знали 😂

Ну а DeepSeek , в своем духе, умным прикидывается - "вот рыба , у рыбы чешуя , не было бы чешуи была бы шерсть, а в шерсти - блохи".

Цвета аварийных систем в транспорте выбраны с учётом стандартов безопасности, исторических традиций и специфики эксплуатации:

1. **Поезда (красный стоп-кран):**
- **Привлечение внимания:** Красный цвет ассоциируется с опасностью и экстренной остановкой. Это универсальный сигнал, знакомый ещё со времён семафоров на железных дорогах.
- **Исторический контекст:** В железнодорожной отрасли красный издавна использовался для сигналов остановки (светофоры, флаги), что закрепилось в конструкции стоп-крана.
- **Простота идентификации:** В вагоне с пассажирами красный цвет легко заметить даже в стрессовой ситуации.

2. **Самолёты (синий аварийный рычаг):**
- **Избежание путаницы:** В кабине пилота множество красных индикаторов (пожарная система, аварийные предупреждения). Синий помогает выделить конкретный механизм (например, аварийное открытие дверей после посадки).
- **Специфика функции:** В воздухе «остановка» невозможна, поэтому синий часто обозначает системы, активируемые на земле (аварийные выходы, тормоза).
- **Эргономика:** Синий менее агрессивно воздействует на зрение пилотов, снижая риск ошибок в сложной приборной панели.

3. **Стандарты:**
- В авиации цветовая кодировка регулируется международными нормами (например, ICAO). Синий может обозначать ручное управление или системы, не связанные с критической остановкой.
- В железнодорожном транспорте красный закреплён в правилах как цвет экстренного торможения.

**Итог:** Разница в цветах обусловлена различиями в функциях, историческом развитии отраслей и требованиях эргономики. Красный в поездах — прямое указание на остановку, синий в самолётах — часть сложной системы аварийного управления, где важно минимизировать риски путаницы.

Показать полностью 3

Мнение YandexGPT по распределению значений бенчмарка

Продолжение по теме
Распределение значений бенчмарка

Вопрос : При условии постоянной нагрузки и неизменного тестового запроса , какое распределение значений бенчмарка производительности СУБД для СУБД PostgreSQL будет встречаться чаще ?

Ответ YandexGPT:

При постоянной нагрузке и неизменном тестовом запросе для PostgreSQL наиболее вероятными будут следующие типы распределений значений бенчмарка производительности:

Нормальное распределение (Гауссово) - наиболее часто встречается при стабильной работе системы. Характеризуется симметричным колоколом с преобладанием средних значений и постепенным убыванием частоты крайних значений.

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

Распределение Пуассона - может наблюдаться при подсчете количества операций за фиксированный период времени при редких событиях.
Факторы, влияющие на форму распределения:

Нагрузка на CPU и RAM
Состояние кэша
Конфигурация PostgreSQL
Тип и сложность запроса
Параллельность выполнения
При анализе производительности важно отслеживать не только среднее значение, но и дисперсию, медиану и квартили, так как даже при нормальном распределении могут возникать значимые отклонения из-за внешних факторов или особенностей работы СУБД.

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


IMHO мне кажется теперь становится ясно, почему авторы стали исследовать разные распределения, а не анализировать причины отклонения от нормального .
Хотя , конечно же, я могу ошибаться .
В любом случае - тема интересная и перспективная. Жаль , авторы молчат и не публикуются для обсуждения .

Показать полностью

Мнение DeepSeek по распределению значений бенчмарка

Продолжение по теме
Распределение значений бенчмарка

Вопрос : При условии постоянной нагрузки и неизменного тестового запроса , какое распределение значений бенчмарка производительности СУБД для СУБД PostgreSQL будет встречаться чаще ?

Ответ DeepSeek:

При постоянной нагрузке и неизменных тестовых запросах распределение значений бенчмарка производительности PostgreSQL чаще всего будет приближаться к **нормальному распределению** (Гауссову распределению). Это объясняется следующими причинами:

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

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

3. **Минимизация выбросов**:
В идеальных условиях (оптимизированные индексы, достаточные ресурсы) редкие аномалии (например, внезапные задержки из-за сборки мусора) подавляются, и распределение становится более «гладким».

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

Показать полностью
1

Распределение значений бенчмарка

Распределение  значений бенчмарка

Постановка эксперимента.
▫️Постоянная нагрузка (количество одновременных запросов) на СУБД
▫️Одинаковый запрос
▫️Длительный период наблюдения
Вопрос математикам :
▫️Какое распределение значений бенчмарка будет наблюдаться ?

Есть два ответа на данный вопрос:
1️⃣В идеальном случае , при минимальном влиянии инфраструктуры будет нормальное распределение , характеристики которого (отклонение, дисперсия, медиана ) и будут результатом эксперимента .
2️⃣Распределение может быть любым , даже мультимодальным и характеристики распределения будут результатами экспериментов .

Вопрос - какой ответ корректнее с математической точки зрения ?

P.S. По поводу второй точки зрения - я задавал вопрос авторам, но пока , в ответ тишина. А было бы очень интересно обсудить тему.

Показать полностью 1

Нейросеть или поисковик - у кого спрашивать ? Кто реально поможет , а не отмажется пустым базаром ?

Вопрос : Какие события ожидания являются характерными признаками отсутствия индекса в таблице при выполнении массовых операций select и update в СУБД PostgreSQL ?


Ответ YandexGPT

Характерные признаки отсутствия индекса в таблице при выполнении массовых операций SELECT и UPDATE в СУБД PostgreSQL включают следующие события ожидания:

1. Ожидания Lock (ожидание завершения транзакции, ожидание блокировки кортежа).
2. Ожидания LWLock (ожидание информации о тяжёлых блокировках, ожидание доступа к общим структурам данных).
3. Ожидания IO (ожидание синхронизации файлов отображения отношений, ожидание заполнения нулями файла поддержки динамической общей памяти).
4. Ожидания IPC (ожидание завершения буферного ввода-вывода, ожидание завершения вычислений параллельными рабочими процессами, ожидание завершения фонового рабочего процесса).


В общем то , в принципе всё верно , но , что с этой информацией делать? Как ответ искусственного интеллекта поможет в реальном анализе ситуации , например ? Ну как обычно самый главный вопрос вопросов - а какая реальная помощь от искусственного интеллекта ?


А , что если воспользоваться старым проверенным способом - спросить поисковик ?

Во-первых : в ответе поисковика указывается не тип ожидания, а событие ожидания . А это принципиально сокращает объем информации для анализа причин.

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

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

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

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

Показать полностью 3
Вопрос из ленты «Эксперты»

Однако похоже пора оформлять приоритет в исследовании темы

Кто то знает - являетесь ли публикация в Дзен канале официальной публикацией или нужно в какой то научно-популярный журнал статью писать и отправлять ?
Как этот процесс вообще происходит ? Оформление и отправка статьи. В крайний раз официально публиковался в даааалеком 1988м году.

Однако похоже пора оформлять приоритет в исследовании темы
Показать полностью 1

YandexGPT vs DeepSeek. Китаец в пролёте . В полном

Вопрос :Где можно найти материалы по методу корреляционного анализа ожиданий СУБД PostgreSQL ?

Ответ YandexGPT

**Корреляционный анализ ожиданий** в PostgreSQL - это методика поиска проблемных SQL-запросов при продуктивной нагрузке.

Основные источники информации по данной методике:

* **PG_HAZEL** - инструмент для анализа производительности PostgreSQL, использующий данный метод
* **Документация PostgreSQL** - содержит базовые понятия и термины, связанные с ожиданиями и производительностью
* **Специализированные блоги** и публикации DBA-специалистов, где описываются практические кейсы применения метода

Методика включает следующие этапы:

* **Анализ операционной скорости** на уровне кластера
* **Мониторинг ожиданий** на уровне кластера
* **Корреляционный анализ** на уровне кластера
* **Статистический анализ** выполнений и ожиданий по отдельным SQL-запросам

Ключевые метрики для анализа:

* **QUERYID** - идентификатор SQL-запроса
* **CORRELATION** - коэффициент корреляции между ожиданиями
* **CALLS** - количество выполнений запроса
* **WAITINGS** - количество ожиданий
* **WAITINGS TO CALL** - отношение ожиданий к выполнениям

Особое внимание уделяется **типам ожиданий**:
* DataFilePrefetch
* DataFileRead
* DataFileWrite
* WALSync
* WALWrite

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


Ответ DeepSeek

Для изучения метода корреляционного анализа ожиданий (Correlation Analysis of Expectations) в PostgreSQL вы можете обратиться к следующим источникам:

### **1. Официальная документация PostgreSQL**
- **Planner/Optimizer Statistics**: В документации PostgreSQL описано, как оптимизатор использует статистику для построения планов запросов, включая корреляцию между столбцами.
- [PostgreSQL: Statistics Used by the Planner](https://www.postgresql.org/docs/current/planner-stats.html)
- [PostgreSQL: Multivariate Statistics](https://www.postgresql.org/docs/current/multivariate-statist...) (для анализа корреляции между несколькими столбцами)

### **2. Книги и учебные материалы**
- **"PostgreSQL 14 Internals"** (E. Rogov, A. Belyaev) – книга объясняет работу планировщика и статистику, включая корреляцию.
- **"Mastering PostgreSQL"** (Hans-Jürgen Schönig) – содержит разделы по оптимизации запросов и статистике.

### **3. Статьи и блоги**
- **Use of Correlation in PostgreSQL Query Planning**:
- [Understanding PostgreSQL Query Planning](https://www.timescale.com/blog/how-postgresql-query-optimiza...)
- [Correlation and PostgreSQL Indexes](https://www.cybertec-postgresql.com/en/postgresql-index-corr...)
- **Примеры анализа корреляции через `pg_stats`**:
```sql
SELECT attname, correlation
FROM pg_stats
WHERE tablename = 'your_table' AND schemaname = 'public';
```

### **4. Исследовательские работы и презентации**
- **"Advanced Query Planning in PostgreSQL"** (лекции с конференций PGConf, PGDay).
- **"Statistics in PostgreSQL: How the Planner Works"** (доклады разработчиков, например, от Robert Haas).

### **5. Практические примеры**
- **Создание расширенной статистики для корреляции**:
```sql
CREATE STATISTICS corr_stats (dependencies) ON column1, column2 FROM table_name;
ANALYZE table_name;
```
- **Использование `pg_stats` для анализа корреляции**:
```sql
SELECT tablename, attname, correlation
FROM pg_stats
WHERE schemaname = 'public'
ORDER BY abs(correlation) DESC;
```

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


Вывод :
Очередная, иллюстрация - китайская нейросеть вообще ничего не знает о материалах в российском сегменте интернета .

Ну а команде Yandex - очередной заслуженный респект.

P.S. Чтобы еще усугубить и резко обозначить разницу можно задать вопрос " Кто автор методологии корреляционного анализа ожиданий СУБД PostgreSQL ? "
DeepSeek, как обычно несет мусор.
А вот ответ, YandexGPT, вполне по делу:

YandexGPT vs DeepSeek. Китаец в пролёте . В полном

Дальше - дело техники - простейший поиск по ключевому слову "pg_hazel" и живое общение с автором 😎

Показать полностью 1

Стандартный пример того, как опасно использовать ответы нейронных сетей

Продолжение игр с большими языковыми моделями .

Вопрос : Расскажи мне про использование индикатора CPI при анализе производительности СУБД PostgreSQL

Ответ DeepSeek , не приводится , китаец как обычно , по данной теме, полную пургу несет.
Ответ YandexGPT:

**CPI** (Cycles Per Instruction) в контексте PostgreSQL представляет собой метрику производительности, которая рассчитывается как модуль вектора из трех показателей:

* **QPS** - количество запросов в секунду
* **TPS** - количество транзакций в секунду
* **RPS** - количество строк, полученных клиентом в секунду

Для измерения времени выполнения операций используются данные из системных представлений:
* **active_time** из pg_stat_database
* **total_exec_time** из pg_stat_statements

Дополнительно введены расширенные метрики:
* **CPI_VOLUME** - объем обработанных блоков распределенной памяти при выполнении SQL-операторов
* **CPI_RATIO** - отношение основной метрики производительности к объему обработанных блоков

**CPI_RATIO** особенно важен для оценки эффективности работы СУБД, так как показывает, насколько эффективно система обрабатывает данные - для достижения одинакового результата требуется обработать меньший объем информации.

При проведении анализа производительности рекомендуется следующий подход:
* Выполнить серию тестовых операций (SELECT, INSERT, UPDATE, DELETE)
* Создать необходимые индексы
* Повторить тестовые операции
* Проанализировать полученные результаты

Экспериментально подтверждено, что цифровые показатели CPI полностью коррелируют с наблюдаемым эффектом от создания индексов, что делает эту метрику надежным инструментом для анализа производительности PostgreSQL.

Сразу бросается в глаза полное несоответствие описания и расчёта .

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

Что делать ? Не доверять чат ботам, включать голову , искать и работать с первоисточниками и материалами самостоятельно .
Лучше с авторами.

Показать полностью
Отличная работа, все прочитано!