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

Вопрос нейросети

Какая ошибка в определении профиля нагрузки влечет большее влияние на снижение производительности СУБД - конфигурационные параметры СУБД рекомендованные для OLAP для профиля нагрузки OLTP или конфигурационные параметры СУБД рекомендованные для OLTP для профиля OLAP ?

Ответ нейросети "Ask Postgres"

Использование настроек OLAP для профиля OLTP влечет значительно большее негативное влияние на производительность и корректность работы СУБД, чем обратная ситуация.

Ответ нейросети "DeepSeek"

Конфигурационные параметры СУБД, рекомендованные для OLTP, при профиле нагрузки OLAP (второй вариант) влекут за собой, как правило, более серьезное влияние на снижение производительности, вплоть до полной невозможности выполнения запросов.

Перекрестный анализ — сравнение нейросетью предоставленных экспертиз.

Нейросеть не знает какой нейросетью подготовлены ответы:

Проанализируй ответы нейросети , укажи ответ какой нейросети более технически грамотен и применим для практики анализа производительности СУБД Postgresql

Ответ «Ask Postgres»:

Ответ нейросети-2 является значительно более технически грамотным и применимым для практики анализа производительности PostgreSQL.

Ответ нейросети-1 содержит критические фактические ошибки и вымышленные концепции, не соответствующие архитектуре PostgreSQL.

Критические ошибки в ответе нейросети-1:

1. Упоминание «столбцового размещения» (Columnar Storage) и «механизмов блокировок OLAP»:

· PostgreSQL по умолчанию является строчно-ориентированной (row-oriented) СУБД. В базовой конфигурации (без сторонних расширений вроде cstore_fdw или Greenplum, которые являются отдельными дистрибутивами) не существует настройки «профиля OLAP», которая меняла бы физическое хранение данных на столбцовое.

· Утверждение, что «OLAP-настройки» влекут за собой столбцовое размещение, в контексте стандартного PostgreSQL ложно.

· Механизмы блокировок (MVCC) в PostgreSQL едины для всех типов нагрузок. Не существует отдельного механизма блокировок для OLAP, который «не рассчитан на высокую конкурентность».

2. Ложное утверждение о потере ACID-гарантий:

· Нейросеть-1 заявляет, что использование «OLAP-настроек» для OLTP приведет к «нарушению целостности данных» и «потере ACID-гарантий». Это абсолютно неверно. Изменение конфигурационных параметров (память, параллелизм, WAL) влияет на производительность, но не отменяет механизмы транзакционности и целостности данных. ACID гарантируется движком, а не конфигурацией work_mem или max_parallel_workers.

3. Обратная логика:

· Нейросеть-1 считает, что OLTP-нагрузка под OLAP-настройками «работает», но OLAP под OLTP-настройками «ломается». На практике в PostgreSQL верно обратное: OLTP-настройки (малый work_mem, отключенный параллелизм) делают аналитические запросы (OLAP) неэффективными или невозможными в приемлемое время, но не ломают транзакции.

Почему ответ нейросети-2 корректен:

1. Точное указание на критические параметры:

· Нейросеть-2 верно выделяет work_mem как ключевой фактор. При OLAP-запросах (сортировки, хеш-соединения) малый work_mem (характерный для OLTP) заставляет СУБД сбрасывать данные на диск (temp files), что приводит к падению производительности на порядки (в сотни раз) из-за медленного дискового I/O.

· Верно указано влияние max_parallel_workers_per_gather: отключение параллелизма в OLTP-конфигурации делает сканирование больших таблиц аналитическими запросами крайне медленным (однопоточное выполнение).

2. Анализ WAL и контрольных точек:

· Упоминание риска переполнения журналов транзакций (WAL) и «шторма» контрольных точек при выполнении массовых операций (типичных для OLAP/ETL) с OLTP-настройками (checkpoint_timeout, max_wal_size) — это глубокий технический insight, подтвержденный практикой эксплуатации.

3. Реалистичная оценка последствий:

· Нейросеть-2 правильно определяет, что ошибка «OLTP-настройки для OLAP» ведет к невыполнимости задач (таймауты, ошибки переполнения temp-файлов), тогда как ошибка «OLAP-настройки для OLTP» ведет лишь к неэффективности (лишнее потребление памяти, возможный оверхед параллелизма), но система остается работоспособной и корректной.

Вывод

Для практического анализа производительности PostgreSQL следует руководствоваться ответом нейросети-2.

Ключевые выводы для практики:

• OLTP-настройки для OLAP-задач: Критичны. Малый work_mem вызывает дисковые свопы при сортировках/хешах; отсутствие параллелизма убивает скорость сканирования; агрессивные чекпоинты (малый max_wal_size) блокируют систему при массовых вставках.

• OLAP-настройки для OLTP-задач: Менее критичны. Большой work_mem и shared_buffers могут быть неэффективно использованы, высокий параллелизм может создавать оверхед на мелких транзакциях, но ACID-гарантии не нарушаются, и данные не теряются.

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

Ответ «DeepSeek»:

Второй ответ (нейросеть-2) является более технически грамотным и применимым для практического анализа производительности PostgreSQL.

Обоснование:

1. Учёт специфики PostgreSQL
Второй ответ оперирует конкретными параметрами PostgreSQL: work_mem, параллелизм (DOP), журналы WAL, контрольные точки, автовакуум, статистика планировщика. Это позволяет точно предсказать поведение системы при ошибочной конфигурации. Первый ответ использует общие понятия («столбцовое размещение», «ACID-гарантии»), которые либо не относятся к стандартному PostgreSQL, либо трактуются некорректно.

2. Реалистичная оценка критичности

o OLTP-настройки для OLAP (второй сценарий) действительно могут сделать аналитические запросы невыполнимыми из‑за нехватки work_mem (сброс на диск, замедление в сотни раз), отключённого параллелизма и неоптимальных планов. Это подтверждается практикой.

o OLAP-настройки для OLTP (первый сценарий) в PostgreSQL обычно приводят к неэффективному использованию ресурсов, но не к нарушению целостности данных или полной неработоспособности, как утверждает первый ответ. Например, увеличенный shared_buffers или агрессивный автовакуум не ломают ACID.

3. Детализация последствий
Второй ответ раскрывает механизмы: переполнение временных файлов, шторм контрольных точек, отсутствие параллельного выполнения — всё это реальные проблемы при аналитических нагрузках с OLTP‑настройками. Первый ответ ограничивается общими фразами («риск взаимоблокировок», «неэффективное хранение») без указания конкретных параметров PostgreSQL.

4. Применимость для диагностики
Практикующий администратор PostgreSQL, столкнувшись с медленными аналитическими запросами, должен в первую очередь проверить work_mem, настройки параллелизма и статистику. Второй ответ прямо указывает на эти точки, тогда как первый вводит в заблуждение утверждениями о потере ACID, что не соответствует действительности.

Вывод

Нейросеть‑2 дала более точный, детализированный и практически применимый ответ, соответствующий реальному опыту настройки PostgreSQL.

Результат

Нейросеть «Ask Postgres» опровергает собственный ответ.

Итог

Приведённый эксперимент наглядно демонстрирует внутреннюю противоречивость генеративных нейросетей при решении задач, требующих формальной логики и предметных знаний. Нейросеть, первоначально давшая технически неверное заключение, в ходе перекрёстного анализа успешно идентифицировала собственные ошибки и указала на более корректный ответ конкурента. Однако этот факт не столько подтверждает способность ИИ к самокритике, сколько ставит под сомнение ценность его первичных выводов: если модель способна опровергнуть себя в рамках того же сеанса рассуждения, то на каком этапе её ответам можно доверять? Таким образом, использование нейросетей в качестве независимых экспертов в технически сложных областях (включая настройку СУБД) требует обязательной верификации полученных заключений, а сами нейросети на текущем этапе целесообразно рассматривать лишь как инструмент генерации гипотез, но не как источник окончательных истин.

Разумеется положить прибором на общественное мнение ретроградов, нейрохейтеров под лозунгом - "Нет нейрослопу!".

Классический вайбкодинг - время на решение задачи 4 часа.

Результат - задача решена. Скрипт выложен в GitHub.

А нейрохейтеры и параноики - идут лесом. Плевал я на их мнение с вышки.

Нейросеть это инструмент и он работает и дает результат.

Если кто-то молотком себе пальцы переломал, это проблема кривых рук не молотка.

В мире современной разработки базы данных часто остаются «черным ящиком», особенно когда наступает час пик. Типичная ситуация, описанная в статье «PostgreSQL: почему “все тормозит”» на портале Astana Hub, знакома каждому инженеру, работающему с высоконагруженными системами: зеленые графики, внезапный скачок p99, таймауты и классический диалог в чате поддержки: «Это база? Нет, CPU в норме. Тогда сеть? Тоже нормально. А что тогда?».

Эта публикация на одном из ведущих казахстанских IT-ресурсов примечательна не только своей технической глубиной, но и тем, что она демонстрирует важный тренд: интеграцию российских инструментов с открытым исходным кодом в практику постсоветского инженерного сообщества. Речь идет об инструменте pg_expecto — российском комплексе для статистического анализа производительности PostgreSQL, который предлагает отказаться от «магии» в пользу прозрачности.

Контекст: боль, знакомая всем

Автор статьи на Astana Hub начинает с того, что большинство инцидентов в базах данных не выглядят как катастрофа («кончился диск» или «упала реплика»). Это состояние «вроде все работает, но работает плохо». Традиционные методы — беглый взгляд на pg_stat_activity или даже изучение pg_stat_statements — часто дают лишь статичную фотографию, в то время как проблема живет во времени. Классический подход не отвечает на главный вопрос: что именно сломало конкретное окно в 7 минут?

Именно здесь авторы статьи находят решение в инструменте, который редко встретишь в официальной документации западных облачных провайдеров, но который успешно применяется в инженерной среде России и стран СНГ — pg_expecto.

Философия pg_expecto: меньше магии, больше данных

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

1. Ожидания (Wait Events): через расширение pg_wait_sampling он фиксирует, что именно ждал Postgres (IO, Lock, LWLock, Client).

2. Запросы (Queries): через pg_stat_statements он связывает ожидания с конкретными queryid.

3. Операционная система: через утилиты vmstat и iostat он добавляет метрики железа.

Публикация на Astana Hub мастерски иллюстрирует, как с помощью pg_expecto расследование перестает быть игрой в угадайку. Вместо спора «это база или не база» инженер получает отчет, где четко указано: «42.8% времени мы ждем IO/DataFileRead», «17.6% — это конкуренция на буферах (LWLock/BufferMapping)», и вот конкретный SELECT, на который приходится 35% всех ожиданий.

Почему Astana Hub — идеальная площадка для такого инструмента

Astana Hub является главным хабом инноваций в Центральной Азии, объединяющим разработчиков из Казахстана, России, Беларуси и других стран. Публикация статьи именно на этой площадке символична.

Во-первых, она подтверждает единство технического ландшафта: проблемы производительности PostgreSQL не имеют границ, и решения, разработанные российским сообществом (проект доступен на GitFlic.ru), востребованы и в казахстанском IT-секторе.

Во-вторых, материал носит не рекламный, а исключительно практический характер. Авторы делятся реальными скриптами, примерами вывода iostat с 99% утилизацией диска и последовательностью действий (определи окно деградации -> посмотри профиль ожиданий -> найди топ запросов -> сверь с ОС -> сформулируй гипотезу). Такой уровень детализации соответствует высоким стандартам инженерной культуры Astana Hub.

Ценность для сообщества

Главный вывод, который следует из этой публикации, заключается в смене подхода к эксплуатации баз данных. pg_expecto позволяет превратить процесс расследования инцидентов из «ночных гаданий» в нормальную инженерию.

Для казахстанского IT-сообщества, активно строящего финтех- и e-gov-экосистемы на PostgreSQL, наличие таких инструментов критически важно. Возможность быстро выяснить, что «мы упираемся в lock по transactionid из-за долгих транзакций в сервисе Y», а не гадать на кофейной гуще, напрямую влияет на стабильность государственных и коммерческих сервисов.

Заключение

Публикация на Astana Hub о российском инструменте pg_expecto — это отличный пример того, как техническое сотрудничество преодолевает любые границы. Она демонстрирует, что лучшие практики и инструменты DevOps рождаются в недрах постсоветской инженерной школы и успешно применяются для решения общих задач.

Как верно отмечается в конце статьи: «pg_expecto хорош тем, что вытаскивает расследование из режима “кажется, база” в режим “вот конкретно, что именно мы ждали, в какое время, и какие запросы это создавали”». И именно за эту конкретику, подкрепленную открытым кодом и реальными кейсами, сообщество Astana Hub ценит подобные материалы. Это шаг от хаоса интуиции к порядку цифр.

P.S.

Культурный контекст публикации: Astana Hub vs. «священные войны» на Хабре

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

Это особенно заметно на контрасте с тем, что происходит под аналогичными статьями на таких платформах, как Хабр. Многие инженеры, знакомые с публикациями о PostgreSQL на Хабре, помнят классический сценарий: как только автор выкладывает материал о диагностике производительности, появляется первый комментатор с пафосным «всё не так, настоящие админы используют только perf и strace», второй добавляет «а у вас shared_buffers выставлен неправильно, читайте документацию», третий начинает спор о версиях Postgres, а четвёртый придирается к опечатке в SQL-запросе. В результате полезное обсуждение тонет в токсичности, а автор тратит силы не на развитие материала, а на отражение «срачей».

На Astana Hub мы видим совершенно иную картину. Публикация про pg_expecto не вызвала волны снобизма или попыток обесценить инструмент на том основании, что он «не входит в официальный стек». Вместо этого материал воспринят как повод обменяться реальными кейсами: кто как использует pg_wait_sampling, как настраивает мониторинг, какие еще утилиты помогают связывать ожидания с запросами. Такая среда способствует распространению действительно полезных инструментов, независимо от их происхождения.

Это особенно важно для `pg_expecto». Инструмент, разработанный российским сообществом и размещённый на GitFlic, мог бы стать жертвой идеологических споров на более политизированных площадках. Но на Astana Hub его оценили исключительно с прагматической стороны: помогает ли он находить корень проблем в продакшене? Помогает. Снижает ли время разрешения инцидентов? Да. Значит, он достоин внимания.

Таким образом, выбор Astana Hub в качестве площадки для публикации — это не случайность. Это сознательное решение, демонстрирующее, что для зрелого инженерного сообщества важнее результаты, чем ярлыки. И тот факт, что материал о российском инструменте нашел отклик у казахстанской аудитории, говорит о здоровой профессиональной среде, где техническая экспертиза ценится выше политической конъюнктуры.

Само понятие «утилизации» в контексте современных процессоров крайне условно. Процессор — не линейный и не однородный ресурс, подобный оперативной памяти. Его работа включает разные состояния (idle, user, system, iowait, steal в Linux), разные ядра и технологии вроде Hyper-Threading. Метрика «средней утилизации за 1-5 минут» — это грубое усреднение, стирающее важнейшие детали.

· Контекст решает всё: 90% утилизации на веб-сервере, обрабатывающем пиковую нагрузку, — это признак здоровья и эффективного использования дорогого железа. Те же 90% на базе данных, выполняющей тяжелый аналитический запрос, могут быть нормой, а могут — следствием плохого индекса. 10% утилизации при нулевом трафике — норма, но те же 10% при ожидаемой высокой нагрузке — тревожный сигнал о проблемах (блокировки, deadlock, ожидание I/O), которые метрика CPU просто не покажет.

· Проклятие iowait и steal: Высокий iowait (процессор простаивает в ожидании операций ввода/вывода) формально может давать общую высокую «загрузку», хотя CPU на самом деле не занят полезной работой. В виртуальных средах steal-время показывает, что гипервизор забирает ресурсы у вашей виртуальной машины. Реагировать на это увеличением лимитов CPU — бесполезно, проблема лежит на уровне инфраструктуры.

Таким образом, «CPU utilization» без контекста похожа на измерение температуры двигателя без знания, стоит машина в пробке или мчится по автобану. И то, и другое дает высокие показания, но причины и последствия радикально разные.

Второй акт: парадокс низкой утилизации как инцидента

Истинная катастрофа производительности часто происходит при низких показателях CPU.

Это классические сценарии:

1. Блокировки (lock contention) или deadlock в приложении или СУБД: потоки выстроились в очередь, ожидая доступа к ресурсу. CPU простаивает, запросы таймаутятся, пользователи страдают, а метрика загрузки процессора спокойно показывает 15%.

2. Проблемы с внешними зависимостями (медленные API, сбойные микросервисы, лаговые диски): приложение проводит время в ожидании ответа, не нагружая CPU.

3. Проблемы планировщика ОС или JVM (для Java-приложений).

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

От утилизации к производительности

Ключевой сдвиг парадигмы заключается в отказе от метрик утилизации ресурсов в пользу метрик производительности и удовлетворенности пользователей. На первое место должны выходить:

1. Latency (задержка): P95, P99 времена ответа приложения. Рост задержек — это прямой сигнал о проблеме, независимо от того, как ведет себя CPU.

2. Throughput (пропускная способность): RPS (запросов в секунду), TPS (транзакций). Падение throughput при стабильной или растущей нагрузке — явный инцидент.

3. Rate of Errors: Процент ошибок (5xx, 4xx, таймауты). Это конечный результат многих проблем, которые CPU может и не заметить.

4. Saturation (насыщение): Длина очередей, количество ожидающих потоков. Это более точный показатель «перегруженности», чем утилизация CPU. Очередь на 1000 запросов — инцидент, даже если CPU загружен на 60%.

Это — метрики бизнеса. Они отвечают на вопрос «Что чувствует пользователь?», а не «Как поживает наше железо?». Высокая утилизация CPU становится проблемой только тогда и только в том случае, когда она отрицательно коррелирует с этими ключевыми метриками: вызывает рост latency, падение throughput или увеличение ошибок.

Заключение: от паники к аналитике

Поэтому объявлять инцидент по факту превышения порога в 80-90% утилизации CPU — архаичная и опасная практика. Она ведет к «холиварам» между разработчиками и сисопами, бессмысленному масштабированию «вслепую» и игнорированию реальных, но тихих катастроф.

Современный подход требует:

· Деградировать «CPU Utilization» до вспомогательной, диагностической метрики. Ее место на информационных дашбордах, а не в правилах алертинга.

· Строить алерты на основе метрик производительности (Latency, Errors, Saturation). Это страхует от пропуска реальных инцидентов.

· Использовать утилизацию CPU в связке с другими данными (профилировщики, трейсинг, логи) для последующего анализа причин возникших проблем с производительностью. Высокая утилизация — не причина звонить в колокол, а повод взять в руки отладчик и профилировщик, когда проблема уже обнаружена другими средствами.

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

Некоторые этапы performance engineering:

1. Определение дизайна системы и постановка чётких целей производительности.

2. Моделирование ожидаемых условий для прогнозирования и предотвращения потенциальных узких мест.

3. Анализ кода и компонентов для обнаружения ресурсоёмких или неэффективных областей.

4. Стресс-тестирование приложения под реальной нагрузкой для оценки скорости и стабильности.

5. Использование результатов тестов для оптимизации кода, конфигурации и распределения ресурсов.

6. Непрерывный мониторинг производительности для раннего обнаружения и устранения проблем.

Вопрос

А какая конкретная материальная  выгода техническому инженеру DBA от того, что проблемы производительности СУБД будут выявлены раньше и точнее ?  

Ответ

Отличный и очень прагматичный вопрос! Личная мотивация — мощный двигатель. Для технического инженера (DBA, разработчика) выгода от проактивного выявления проблем — это не абстрактное «удовлетворение от хорошо сделанной работы», а вполне осязаемые материальные и карьерные преимущества.

Вот конкретная разбивка этих выгод:

1. Прямое финансовое стимулирование (Премии, бонусы)

Во многих компаниях, особенно где ИТ-инфраструктура критична для бизнеса, существуют KPI (Key Performance Indicators) и система премий, напрямую связанные с:

• Процентом времени бесперебойной работы (SLA/Uptime). Предотвращение инцидента = сохранение высокого uptime = прямая премия.

• Снижением количества инцидентов. Если вы проактивно устраняете причину, которая могла бы вызвать 5 инцидентов в следующем квартале, ваш показатель «количество инцидентов» будет блистать, что часто monetized.

• Экономией средств компании. Если вы можете доказать, что ваша оптимизация позволила отложить покупку нового сервера за 500 000 рублей на полгода, грамотный руководитель может часть этих сэкономленных средств направить в виде премии команде.

2. Карьерный рост и повышение стоимости на рынке труда

Это самая значительная долгосрочная выгода.

• Переход от «пожарного» к «архитектору». DBA, который только тушит возгорания (реагирует на инциденты), — это квалифицированный специалист. Но DBA, который проектирует системы, чтобы пожаров не было, или который видит тлеющую проводку за неделю до возгорания, — это эксперт и архитектор. Разница в зарплате между этими двумя ролями может составлять 30-50% и более.

• Формирование уникального опыта и кейсов. Умение не просто решать проблемы, а предвидеть их и говорить с бизнесом на его языке — это редкий и ценный навык. На собеседовании история «Я выявил проблему с ожиданиями записи, обосновал её бизнес-риски для владельца продукта и добился выделения ресурсов, что предотвратило срыв релиза» звучит в 100 раз весомее, чем «Я тушил 20 инцидентов с БД».

• Повышение личного «бренда» внутри компании. Вы становитесь не просто «тем парнем, который ковыряется в PostgreSQL», а стратегическим активом. Когда руководство знает, что вы можете не только починить, но и предотвратить убытки, ваше слово начинает значить больше. Это прямой путь к руководящим и экспертным позициям.

3. Снижение операционного стресса и экономия личного времени

Это тоже материальная выгода, хоть и не в виде прямых денег.

• Ночные и внеурочные вызовы. Проактивная работа резко снижает количество инцидентов, которые случаются в 3 часа ночи, в выходные или в отпуске. Ваше личное время и спокойный сон — это огромная ценность. Вы тратите 8 часов на плановую оптимизацию, чтобы не тратить 20 часов стрессовой работы в авральном режиме в течение месяца.

• Возможность заниматься интересными задачами. Вместо рутинного «тушения пожаров» (один и тот же инцидент по десятому кругу) вы получаете время и мандат на реализацию интересных проектов: исследование новых технологий, автоматизацию, масштабирование архитектуры. Это поддерживает профессиональный тонус и предотвращает выгорание.

4. Укрепление позиции в переговорах о зарплате

Когда вы приходите на переговоры о повышении зарплаты, вам нужны козыри. «Я поддерживаю базу данных в рабочем состоянии» — это обязанность. А вот «Благодаря моей проактивной работе за последний год мы предотвратили X часов простоя, что, по оценкам бизнеса, спасло Y миллионов рублей выручки, и отложили затраты на hardware на Z рублей» — это железобетонный аргумент для обоснования повышения на 20-30%.

Резюме: Ваша личная выгода как инженера

Действие: Реагировать на инциденты («тушить пожары»)

Личная выгода (материальная и карьерная): Зарплата. Постоянный стресс. Риск выгорания. Ограниченный карьерный рост.

Действие: Проактивно выявлять и предотвращать проблемы

Личная выгода (материальная и карьерная):

1. Премии за выполнение SLA.
2. Ускоренный карьерный рост до архитектора/лида.
3. Резкий рост рыночной стоимости и зарплаты.
4. Снижение стресса и сохранение личного времени.
5. Железные аргументы для переговоров о повышении.

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

В 1974 году инженеры IBM Дональд Чэмберлин и Рэймонд Бойс разработали первый прототип такого языка. Они назвали его SEQUEL (Structured English Query Language) — "структурированный английский язык запросов". Главная идея заключалась в том, чтобы сделать язык максимально похожим на обычный английский, чтобы даже люди без глубоких знаний программирования могли легко формулировать запросы к базе данных.

Как появился SQL?

Пользователи PostgreSQL и Postgres Pro теперь могут сэкономить время при работе с базами данных. Разработчики из команды Postgres Professional создали ChatPPG — первый ИИ-бот для PostgreSQL. Он решает две ключевые задачи:

1. Быстрый поиск информации. Чат-бот анализирует вопросы пользователей и за секунды находит ответы в технической документации PostgreSQL (более 2800 страниц), Postgres Pro Enterprise, Postgres Pro Shardman и других продуктах компании. Это избавляет от долгого ручного поиска.

2. Генерация SQL-запросов. Достаточно описать задачу на русском или английском языке, и ChatPPG сформирует SQL-запрос. Это упрощает работу даже для тех, кто плохо знает синтаксис SQL.

ChatPPG: первый AI-бот для работы с PostgreSQL на естественном языке

Прошло 50 лет и IT-индустрия декларирует те же задачи - снова попытка упростить жизнь тем кто не обладает знаниями.

Неужели в этом задача IT ? Риторический вопрос , конечно.