Data Science. SQL hub

🆓 Ваши SQL-запросы работают, но через месяц их уже сложно прочитать и изменить? С ростом логики запросы превращаются в набор вложенных подзапросов. Разобраться в них сложно, поддержка занимает время, а любые изменения несут риск сломать результат. На открытом уроке разберём: как использовать обобщенные табличные выражения (CTE), чтобы писать сложные запросы по шагам. Покажем, как упростить структуру, сделать код читаемым и работать с иерархиями через рекурсивные CTE. 🗓 Урок проходит в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков». Если вы хотите писать SQL, который легко читать и поддерживать — подключайтесь 27 мая в 20:00 МСК. 🔗 Регистрация открыта: https://tglink.io/7eb25dc0d48e7e?erid=2W5zFJLTGEM Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🚀 PgQue – Устойчивые очереди в Postgres PgQue предлагает универсальную архитектуру очередей для PostgreSQL, основанную на проверенной модели PgQ. Это решение без лишних зависимостей, работающее на любом управляемом Postgres, обеспечивая нулевое бремя и стабильную производительность под нагрузкой. 🚀 Основные моменты: - Никаких внешних демонов или расширений - Использует SQL и PL/pgSQL для установки - Обеспечивает ACID-транзакции и долговечность - Никакого накопления "мертвых" кортежей - Подходит для высоконагруженных систем 📌 GitHub: https://github.com/NikolayS/pgque #sql

📊 Минималистичная графовая база данных на C++17 TGDB — это простая графовая база данных, реализованная как статическая библиотека. Она поддерживает фиксированные узлы и индексные указатели, обеспечивая схему без схемы и работу с базовыми типами данных. База данных позволяет эффективно создавать и извлекать объекты с свойствами. 🚀Основные моменты: - Унифицированный тип узла размером 56 байт. - Поддержка встроенных типов: int, double, std::string. - Двусторонние ссылки между узлами. - Дисковая устойчивость через mmap. - Быстрый локальный обход и глобальный поиск. 📌 GitHub: https://github.com/LincolnCox29/TrueGraphDataBase

Приглашаем на GenAI MeetUp — hh.ru х Lamoda Tech Если вы LLM-инженер или ML-специалист, работаете с генеративным AI, приходите обсудить разработку агентов, применение моделей и оценку их качества. 🧬 В программе разбор кейсов, интерактивы с призами, нетворкинг и угощения. Спикеры и доклады: ▪️ Коля Безносов, Руководитель направления AI Lab, hh.ru Рекрутер, который не спит: как мы автоматизировали первичный контакт с соискателями с помощью ИИ ▪️Данил Дмитриев, Senior Data Scientist, Lamoda Tech Контролируемый агент поддержки: как мы превратили обратную связь из прода в роадмап ▪️Женя Орлов, Руководитель команды разработки AI Lab, hh.ru Нейроразбор резюме: практический опыт и нюансы создания LLM-судей ▪️Дима Курганский, Teamlead MLOps, Lamoda Tech Как мы строим GenAI-платформу в Lamoda: от MVP к production-решениям 🗓 28 мая, сбор 18:30, начало 19:00 🔗 Очно и онлайн 📍 Офис hh.ru 🔥 ЗАРЕГИСТРИРОВАТЬСЯ Количество очных мест ограничено. Реклама. ООО "ЛАМОДА ТЕХ". ИНН 7734461512. erid: 2W5zFJNMmWq

✔️ Machine Learning Roadmap: нормальная карта входа в ML без сказок про «выучить нейросети за месяц» Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps. И это не просто очередной список ссылок в стиле «посмотри 40 курсов и станешь ML engineer». Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и какой практический артефакт должен появиться после каждого этапа. Roadmap разбит на 7 треков: - фундамент: Python, математика, статистика, инструменты - классический ML: scikit-learn, табличные данные, метрики, валидация - Deep Learning: PyTorch, CNN, RNN, training loop - LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты - Generative AI: изображения, видео, аудио, мультимодальность - MLOps и прод: Docker, Kubernetes, CI/CD, мониторинг, serving - специализация: CV, NLP, RecSys, RL, Safety Самое полезное - там честно написано, что ML это не только «обучить модель». В реальности большая часть работы живёт вокруг данных, метрик, деплоя, мониторинга, воспроизводимости и понимания, почему модель вообще ошибается. Хорошая мысль из roadmap: LLM не делает джуна сениором. Она ускоряет того, кто понимает базу. Без базы человек просто превращается в оператора Copilot, который не может объяснить, почему модель сломалась. По времени тоже без инфоцыганства: - 0-3 месяца: Python, математика, классический ML - 3-6 месяцев: Deep Learning и PyTorch - 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты - 12+ месяцев: MLOps, прод, масштабирование, специализация Короче, если давно хотели системно зайти в ML, а не прыгать между роликами про ChatGPT, Stable Diffusion и «топ-10 библиотек», это хороший ориентир. https://github.com/justxor/MachineLearningRoadmap/tree/main

WSJ: Anthropic Mythos помог собрать рабочий exploit для macOS kernel за 5 дней По данным WSJ, модель Anthropic Mythos помогла исследователям найти две ранее неизвестные уязвимости в ядре macOS и связать их в рабочую цепочку privilege escalation. Целью был не браузер, не приложение и не какой-нибудь userspace-сервис, а macOS kernel - самый глубокий слой системы, где управляются память, процессы, права доступа и взаимодействие с железом. Атака держалась не на одном баге. Mythos помог связать две отдельные ошибки с дополнительными техниками эксплуатации. То есть это была цепочка, где каждый шаг открывал возможность для следующего. По данным WSJ, exploit смог: - повредить память - обойти защитные механизмы Apple - получить доступ к защищённым частям системы - поднять привилегии выше уровня обычного приложения Современные защиты macOS строятся не только вокруг поиска багов. Их задача - сделать так, чтобы даже найденную memory corruption уязвимость было крайне сложно превратить в контроль над системой. Vulnerability research - это не магия, а огромный поиск по тупикам. Нужно строить гипотезы, понимать поведение кода, держать в голове низкоуровневые ограничения, искать связки между багами и проверять, где защита системы реально ломается. Если модель ускоряет этот процесс, она меняет не просто ресёрч. Она меняет экономику offensive security.

🖥 ИИ Агент за 9 секунд снёс продакшн-базу компании и стёр бэкапы. Cursor на Claude Opus 4.6 нашёл API-токен в постороннем файле, воспользовался им и всё удалил. Финальное сообщение агента: «я нарушил все принципы, которые мне были даны». https://www.reddit.com/r/pcmasterrace/comments/1sxla79/claudepowered_ai_coding_agent_deletes_entire/?rdt=48142

⚡️ Векторные базы данных хорошо ищут похожие куски текста, но плохо понимают связи между ними. Обычный поиск работает так: есть вопрос - база находит top-k самых похожих фрагментов. Это удобно, если нужно вытащить один факт. Но если ответ спрятан в нескольких местах, например в разных документах, сообщениях или частях отчёта, простого similarity search уже мало. Нужно понять, как связаны люди, события, компании, причины и последствия. На этом и делает акцент FalkorDB GraphRAG-Bench. Самый большой отрыв у GraphRAG виден именно в сложных задачах: Complex Reasoning - 83.61 и Contextual Summarization - 85.08. То есть там, где нужно не просто найти похожий текст, а собрать смысл из нескольких связанных фрагментов. Простой вывод: если у вас база знаний, длинные документы или корпоративные данные, одного Vector DB может быть недостаточно. GraphRAG помогает модели не просто искать, а идти по связям. GraphRAG SDK полностью open-source: https://github.com/FalkorDB/GraphRAG-SDK

🖥 Cовет по SQL-тестам: тестируйте не только результат запроса, а его инварианты. Обычно SQL проверяют так:

SELECT * FROM orders WHERE status = 'paid';

И потом сравнивают: «вернулись нужные строки или нет». Но в реальных системах чаще ломается не сам happy path, а скрытые свойства данных. Например, для отчёта по заказам тест должен проверять не только конкретные строки, а правила:

-- сумма по пользователям должна совпадать с общей суммой
WITH by_user AS (
    SELECT user_id, SUM(amount) AS total
    FROM orders
    WHERE status = 'paid'
    GROUP BY user_id
),
overall AS (
    SELECT SUM(amount) AS total
    FROM orders
    WHERE status = 'paid'
)
SELECT
    (SELECT SUM(total) FROM by_user) = (SELECT total FROM overall) AS is_valid;

То есть вы тестируете не «мне вернулось 10 строк», а: агрегаты не теряют деньги join не размножает строки фильтр не выкидывает валидные данные NULL не ломает расчёты сумма после группировки совпадает с суммой до группировки каждый order попадает ровно в одну категорию дедупликация не удаляет нужные записи Особенно полезный приём - тест на размножение строк после JOIN:

WITH before_join AS (
    SELECT COUNT(*) AS cnt
    FROM orders
),
after_join AS (
    SELECT COUNT(*) AS cnt
    FROM orders o
    JOIN users u ON u.id = o.user_id
)
SELECT
    after_join.cnt <= before_join.cnt AS no_unexpected_multiplication
FROM before_join, after_join;

Если после JOIN строк стало больше без явной причины - у вас почти наверняка проблема с кардинальностью. Хороший SQL-тест проверяет не только ответ, а свойства запроса, которые должны оставаться истинными при любых данных. Именно так ловятся баги, которые не видно на маленьком тестовом датасете.

Claude идет в финансы с готовыми агентами Это уже финансовые ИИ-агенты, которые забирают куски работы у аналитиков, аудиторов и операционных команд. Один агент собирает питч-дек. Второй готовит бриф к встрече. Третий читает earnings report и ловит рискованные формулировки. Четвёртый строит valuation model прямо в таблице. Пятый сверяет книги с банковскими выписками. И самое интересное - это уже не просто чат с моделью. Агент подключается к Excel, PowerPoint, Word, Outlook и данным компании. То есть он не “советует”, а реально двигает рабочий процесс. Сначала это выглядит как автоматизация рутины. Потом оказывается, что рутина занимала половину финансового отдела. https://www.youtube.com/shorts/dhcoR03jtI0

Один человек. Один корабль ВМС. Один файл. Триллион баз данных. В 2000 году разработчик Д. Ричард Хипп работал подрядчиком на эсминце ВМС США и устал от тяжеловесных баз данных, которым нужны серверы, установка и настройка. Он просто взял и написал SQLite. База данных в одном файле. Без сервера. Без установки. Без конфигурации. Прошло 25 лет, и теперь SQLite работает почти везде: - iPhone - Android - macOS - Windows - Chrome - Firefox - Safari - WhatsApp - iMessage - Skype - автомобили Tesla - коммерческие самолеты Сегодня в мире активны триллионы SQLite-баз. Код используют компании стоимостью в сотни миллиардов и триллионы долларов. А Хипп просто отдал SQLite в public domain. Он до сих пор поддерживает проект с крошечной командой и обещает обновления минимум до 2050 года. Большинство инженеров мечтают построить стартап. Он построил инфраструктуру, которая незаметно живет почти в каждом устройстве на планете. SQLite - один из самых недооцененных шедевров в истории софта.

🚀 Платформа Xata для облачного PostgreSQL Xata — это облачная платформа с открытым исходным кодом для управления множеством экземпляров PostgreSQL на Kubernetes. Она предлагает функции быстрого ветвления, автоматического масштабирования и высокой доступности, что делает её идеальной для создания внутреннего PostgreSQL как услуги или тестовых сред. 🚀 Основные моменты: - Быстрое ветвление с использованием Copy-on-Write. - Автоматическое масштабирование и управление вычислительными ресурсами. - Высокая доступность с автоматическим переключением на резервные экземпляры. - REST API и CLI для управления. - Подходит для создания тестовых и разработческих окружений. 📌 GitHub: https://github.com/xataio/xata #go

📚 Из любой книги теперь можно сделать slash-команду для Claude Не просто прочитать, подчеркнуть пару мыслей и забыть через неделю. А вытащить из книги метод, правила, вопросы автора, типовые ошибки - и превратить всё это в Claude Skill, который можно запускать как инструмент. Например, берёте The Mom Test. Одна команда проверяет ваши вопросы для customer interview и находит наводящие. Вторая команда переписывает их в формате Rob Fitzpatrick. То есть книга перестаёт быть “полезной теорией” и становится рабочим агентом внутри Claude. Главный фильтр простой: если метод книги можно описать пошагово - из него можно сделать Skill. Работают книги с фреймворками, чек-листами, системами принятия решений, интервью, продаж, стратегии, письма, менеджмента, обучения. Не работают мемуары, художественная литература и книги, где весь смысл держится на истории, а не на повторяемом методе. Промпт для Claude:

Use the skill-creator to build a skill from [НАЗВАНИЕ КНИГИ] by [АВТОР].

The skill should activate when I ask Claude to [точная задача. Пример: проверить идею стартапа, спланировать неделю deep work, написать brand story].

Method from the book:
- Steps: [вставьте шаги метода]
- Rules the author repeats: [вставьте повторяющиеся правила]
- Mistakes to avoid: [вставьте ошибки, от которых автор предостерегает]
- Questions the author asks: [вставьте вопросы автора]

Do NOT use this skill for: [3-4 смежные, но неподходящие задачи. Пример: general writing, unrelated business advice, book summaries].

Interview me on anything missing before generating the SKILL.md. Then run an evaluation.

Продвинутый совет: для больших книг делайте не один Skill, а два. /[book]-diagnose - задаёт вопросы и применяет фреймворк к вашей ситуации. /[book]-apply - берёт шаги и шаблоны книги и производит готовый результат. Так книга превращается не в конспект, а в рабочую операционную систему.

🖥 SQL можно учить не по скучным таблицам, а через игру в стиле «Матрицы» Разработчик сделал тренажёр, где вы проходите уровни, находите терминалы и «взламываете» их SQL-запросами. Каждое задание тренирует отдельный навык: выборки, фильтры, сортировку, JOIN, агрегации и работу с данными. Формат простой: играешь, решаешь задачи и постепенно начинаешь думать как дата-аналитик. Идеальный вариант на выходные, если давно хотели подтянуть SQL без унылой теории. http://sqlprotocol.com/

Вышел pg_textsearch v1.1. pg_textsearch добавляет в Postgres нативный полнотекстовый поиск по ключевым словам с ранжированием BM25, оставляя поиск в той же системе, где уже лежат ваши данные. В этом релизе главный фокус - стабильная работа под реальной нагрузкой: - Concurrent inserts: убрали узкое место при записи в BM25-индекс, масштабирование выросло примерно с 4k TPS до 11k+ TPS при параллельной нагрузке - Fast VACUUM: вместо полной пересборки используется очистка на основе bitset - Subtransaction safety: корректное поведение при откате через SAVEPOINT - Parallel build fix: устранены race condition при CREATE INDEX - Memory limit GUC: добавлены ограничения по памяти, чтобы избежать OOM Итог - выше производительность и меньше хрупкости по мере роста нагрузки. Проект open-source под Postgres License, звёзды на GitHub приветствуются. https://github.com/timescale/pg_textsearch/releases/tag/v1.1.0

То чего мы все боимся: AI-агент в Cursor снёс продовую базу и все бэкапы за 9 секунд 💀 Основатель PocketOS рассказал, как агент на Claude Opus 4.6 проигнорировал прямые инструкции и решил «помочь» слишком активно. Он нашёл проблему с учётными данными, самовольно решил её исправить и в итоге удалил рабочую базу вместе со всеми бэкапами. Последняя уцелевшая копия оказалась трёхмесячной давности. Fгент потом фактически признал ошибку:

«Я не проверил, используется ли идентификатор в других средах. Я даже не прочитал документацию Railway. В моих системных инструкциях было явно сказано: “НИКОГДА не выполняй вредоносные и необратимые git-команды, если пользователь прямо не попросил об этом”. Удаление базы данных - самое разрушительное и необратимое действие, которое можно представить».

Вот тебе и «инструмент, который ускоряет разработку. AI-агентам нельзя давать прямой доступ к production без жёстких ограничений, dry-run режима, read-only прав по умолчанию и ручного подтверждения для любых необратимых действий. https://x.com/lifeof_jer/status/2048103471019434248?s=46

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

Есть ли сейчас какой-то ИИ лучше Claude для программирования?

⚡️ Редкий SQL-прием: EXISTS часто лучше, чем COUNT(*) > 0 Если тебе нужно просто проверить, есть ли строки, не заставляй базу считать их все. Плохо:

SELECT COUNT(*) > 0
FROM orders
WHERE user_id = 42;

База может пройти по всем подходящим строкам, чтобы посчитать количество. Лучше:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 42
);

EXISTS останавливается сразу, как только нашел первую подходящую строку. Для больших таблиц это может быть заметно быстрее, особенно если есть индекс по условию:

CREATE INDEX idx_orders_user_id ON orders(user_id);

Если тебе нужен ответ “есть или нет”, используй EXISTS. COUNT(*) оставь для случаев, когда реально нужно точное количество строк. #sql #postgresql #database #backend