Data Science. SQL hub

Ваши дашборды грузятся по минуте? SQL-запросы «падают» на продакшене, а бизнес требует отчеты «еще вчера»?

Руководители команд аналитики и senior-разработчики знают: узкое место — не мощность сервера, а эффективность кода и архитектуры запросов.

Прокачайте скорость - получите бесплатно урок «Аналитика без тормозов» от Георгия Семенова, руководителя команды Analytics Engineering в Яндексе с 14-летним опытом (экс-VK, Wildberries, ВТБ).

Вы узнаете:
🔸Тактические и стратегические методы ускорения запросов и дашбордов, применимые к любой СУБД
🔸Специфические нюансы оптимизации, которые отличают middle от senior.

Но это не всё. Мы понимаем: результат дает прокачка всей команды и внедрение знаний в конкретные рабочие задачи.

Для руководителей отделов аналитики: хотите масштабировать этот эффект?
Симулейтив предлагает корпоративное обучение под ключ:

🔸Преподаватели-практики из “биг-теха” адаптируют программу под ваши бизнес-задачи
🔸Индивидуальный итоговый проект каждого сотрудника строится на его реальной рабочей задаче
🔸Бессрочная поддержка преподавателей и доступ к закрытым мастер-классам
🔸Выгода до 30% при пакетном обучении команды

Примените практику из бесплатного урока уже сегодня, а затем внедрите её в работу всего отдела аналитики - сделайте шаг, чтобы ваши процессы полетели: ТРЕНИНГ ПО SQL

🚀 SQLite, у которой недавно вышел новый релиз, имеет один из самых необычных Code of Ethics во всей индустрии.

История появления документа довольно забавная. Некоторым компаниям, использующим SQLite, требовалось указывать ссылку на Code of Conduct в своих внутренних политиках. Тогда разработчики SQLite просто решили сделать собственный кодекс, но очень нестандартным способом.

Вместо привычного корпоративного CoC они взяли «Правило святого Бенедикта» - монашеский свод принципов VI века и сделали его основой своего кодекса.

Вот несколько первых пунктов:

- Прежде всего возлюби Господа Бога всем своим сердцем, всей душой и всей силой
- Затем возлюби ближнего своего как самого себя
- Не убивай
- Не прелюбодействуй
- Не кради
- Не желай чужого
- Не лжесвидетельствуй
- Почитай всех людей
- Не делай другим того, чего не хотел бы для себя

Всего таких правил - 72, и читаются они скорее как философские или духовные принципы, чем как стандартный документ для open-source проекта.

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

В мире, где Code of Conduct обычно выглядит как длинный юридический документ, SQLite выбрала… правила монастыря VI века.

sqlite.org/codeofethics.html

В основе любого сильного проекта стоит сильный специалист.

В IT-мире сложно представить востребованного специалиста, который не разбирается в том, как работают: архитектура, API, базы данных, алгоритмы.

Без этого никуда.

И не страшно, если вы пока плохо разбираетесь в каких-то современных системах. Хуже, если продолжаете игнорировать свои пробелы в hard skills.

Начните с бесплатных уроков по архитектуре и интеграциям:

▪️мощный инструмент — SOAP UI
▪️подробное описание процесса загрузки сайта
▪️модель TCP/IP и устройства
▪️XML — это вам не ХSD

Присоединяйтесь в чат-боте по ссылке:
👇
@studyit_help_bot

🚀 Скидка на полный курс от канала — 1 500 ₽ на Stepik по промокоду SQLHUB до конца февраля.

🔥 Zero-cost поиск для AI-приложений — идея из turbopuffer

Большинство систем поиска и векторных БД сегодня очень дорогие.
Причина простая, они хранят данные в RAM или реплицированных SSD, где стоимость может доходить до $600–$3600 за TB в месяц.

Но turbopuffer предлагает другой подход.

Хранить данные не в памяти серверов, а в object storage (например S3 или GCS).

Стоимость:

- RAM + SSD инфраструктура - до $3600/TB
- SSD-кластеры - около $600/TB
- Object storage (S3) - примерно $20/TB
-
Разница может достигать до 100× дешевле для холодных данных.

📌 Архитектура turbopuffer:

Client
↓
Query layer
↓
SSD / memory cache (горячие данные)
↓
Object storage (источник истины)

То есть:

- холодные данные хранятся дешево в object storage
- часто используемые попадают в SSD или RAM cache
- запросы остаются быстрыми (<100ms), но стоимость инфраструктуры падает на порядок

Vector search становится ключевой частью AI-систем:

- RAG
- AI-ассистенты
- semantic search
- recommendation systems

Но именно retrieval слой часто становится самой дорогой частью AI-инфраструктуры.

Архитектура turbopuffer показывает, что:
> дешевый storage + умный cache
> может заменить дорогие memory-based search системы.

Будущее AI-поиска может выглядеть так:

- object storage как источник данных
- stateless compute
- дешёвый storage
- кэш для hot data

И тогда поиск по миллиардам документов становится почти “zero-cost” инфраструктурой.

Подробнее:
https://turbopuffer.com/blog/zero-cost

Модель с триллионом параметров буквально «удалила половину своего мозга» и стала умнее.

Yuan3.0 Ultra**-— новая open-source мультимодальная **MoE-модель от Yuan Lab.
Всего 1010 млрд параметров, но при инференсе активны только 68.8 млрд.

На бенчмарках RAG она обошла GPT-5.2, Gemini 3.1 Pro и Claude Opus 4.6 с заметным отрывом.

Например:

- 67.4% на Docmatix против 56.8% у GPT-4o

Что умеет модель:

- Enterprise RAG - 68.2% средней точности на 10 задачах поиска
- Анализ сложных таблиц - 62.3% на бенчмарке MMTab
- Text-to-SQL - 83.9% на Spider 1.0
- Мультимодальный анализ документов с контекстом 64K

Ключевая инновация — Layer-Adaptive Expert Pruning (LAEP).

Во время предобучения у MoE возникает сильный дисбаланс:
некоторые эксперты получают в 500 раз больше токенов, чем другие.

LAEP постепенно удаляет малоиспользуемых экспертов слой за слоем,
что позволяет:

- сократить 33% параметров
- увеличить эффективность обучения на 49%

Также исследователи улучшили метод “fast-thinking” RL.

Теперь система больше награждает ответы, которые:

- правильные
- используют меньше шагов рассуждения

Это позволило:

- уменьшить количество выходных токенов на 14.38%
- повысить точность на 16.33%

Главный сигнал из этого исследования:

MoE-модели начинают сжимать себя прямо во время обучения, а не после.

Если pruning станет частью pretraining, стоимость обучения триллионных моделей может резко снизиться.

https://github.com/Yuan-lab-LLM/Yuan3.0-Ultra

ReadySet — это прозрачный кэш базы данных для Postgres и MySQL, который обеспечивает производительность и масштабируемость хранилища «ключ-значение» в оперативной памяти, не требуя от вас переписывать приложение или вручную обрабатывать аннулирование кэша.

https://github.com/readysettech/readyset

UPDATE без WHERE -
самый быстрый способ обновить резюме.

@sqlhub

👣 Большинство изучают Go ради синтаксиса.

Ты научишься писать сервисы, которые работают в продакшене.

Это не про «Hello, World» и горутины ради галочки.
Это про бэкенд на Go, который:

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

Ты начнёшь видеть Go не как язык, а как инструмент для построения систем.

В итоге ты сможешь:

* писать высоконагруженные API
* создавать микросервисы
* работать с базами данных и очередями
* разбираться в конкурентности и производительности
* брать коммерческие backend-проекты

Это навык, который ценится на рынке.
Не «знаю Go», а умею делать быстрые и надёжные сервисы.

🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/274119/

Как правильно установить и использовать браузер в Linux.

Если браузер работает медленно или ломается после обновлений - проблема часто не в Linux, а в установке. Многие ставят браузер из случайных источников или вручную скачивают архивы, из-за чего нет автообновлений, слетают зависимости и появляются ошибки.

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

Для примера установим Google Chrome официальным способом.

Установка Google Chrome (Ubuntu / Debian)
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -y ./google-chrome-stable_current_amd64.deb

Запуск браузера
google-chrome

Обновление системы (включая браузер)
sudo apt update && sudo apt upgrade -y

Проверка версии
google-chrome --version

📊 Real-time SQL Traffic Viewer

sql-tap — это прокси-демон, который перехватывает SQL-запросы между вашим приложением и базой данных (PostgreSQL или MySQL), отображая их в интерактивном терминальном интерфейсе. Позволяет анализировать запросы и транзакции без изменения кода приложения.

🚀Основные моменты:
- Перехват SQL-запросов в реальном времени
- Поддержка PostgreSQL и MySQL
- Интерактивный интерфейс для анализа запросов
- Возможность использования EXPLAIN для оптимизации запросов

📌 GitHub: https://github.com/mickamy/sql-tap

#go

Создатель Linux
— обычный стол, минимум техники, ничего лишнего.

Обычный «тех-бро»
— три монитора, RGB, мощный ПК, студийный свет, полный сетап.

Иногда разница между «легендой» и «тех-инфлюенсером» - не в железе, а в том, что у тебя в голове.

🖥 Большинство “парсеров” умирают через 2 дня.
Ты научишься делать те, которые живут в проде.

Это не про BeautifulSoup ради галочки.
Это про системы сбора данных, которые:

• не падают от мелких правок на сайте
• собирают данные в разы быстрее
• обновляют всё сами по расписанию
• обходят ограничения и баны
• выглядят как сервис, а не хаос из файлов

Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться.

В итоге ты сможешь:

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

Это навык, который напрямую превращается в деньги.
Не “знаю Python”, а умею добывать данные из интернета профессионально.

🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/

DeepSeek готовится выпустить новую модель V4 - релиз ожидается в ближайшее время (по данным CNBC).

И рынок уже нервничает.

NASDAQ находится под давлением — инвесторы закладывают сценарий, при котором новый релиз может резко усилить конкуренцию и изменить расклад в AI-индустрии.

Почему такая реакция?

DeepSeek V4, по слухам, должен стать серьёзным скачком вперёд:
- более сильное reasoning
- лучшая эффективность
- более низкая стоимость

Если это подтвердится, давление на американские AI-компании и их оценки может усилиться.

Контекст становится ещё интереснее на фоне недавнего заявления Anthropic, где компания сообщила о масштабных попытках distillation через API.

Во времени это выглядит как совпадение:
- готовится крупный релиз DeepSeek
- рынок нервничает
- и одновременно звучат обвинения в копировании возможностей моделей

Если V4 действительно окажется сильным, это может означать новую фазу AI-гонки.

Ответ узнаем очень скоро.

Следующий релиз может повлиять не только на технологии -
но и на рынок.

https://www.cnbc.com/2026/02/23/deepseek-to-release-new-ai-model-a-rough-period-for-nasdaq-stocks-could-follow.html

🎯Продвинутая миграция в SQL, которая спасает продакшен от падения

Самая частая проблема при миграциях - блокировки.

Обычный CREATE INDEX или ALTER TABLE на большой таблице может:
остановить записи
заморозить сервис
создать очередь запросов
и положить базу.

Продвинутый подход - выполнять изменения без блокировки.

В PostgreSQL для этого есть режим CONCURRENTLY.

Он создаёт индекс в фоне,
не блокирует INSERT и UPDATE,
и позволяет делать миграции без даунтайма.

Если таблица большая - это не оптимизация.
Это обязательная практика.

-- Создание индекса без блокировки таблицы
CREATE INDEX CONCURRENTLY idx_payments_user_id
ON payments(user_id);

-- Удаление индекса без блокировки
DROP INDEX CONCURRENTLY idx_payments_user_id;

В Python 3.14 появилось решение, которое помогает избавиться от SQL-инъекций - t-strings 🔒

Проблема

Когда вы используете f-strings для SQL:

query = f"SELECT * FROM users WHERE name = '{user_input}'"

пользовательский ввод напрямую попадает в запрос.

Если злоумышленник передаст:

admin'; DROP TABLE users; --

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

Это классическая SQL injection.

Почему это неудобно сейчас

Безопасный способ — параметризованные запросы:

cursor.execute(
    "SELECT * FROM users WHERE name = %s",
    (user_input,)
)

Но приходится:

• запускать шаблон отдельно
• передавать значения отдельно
• поддерживать две структуры

Что изменилось в Python 3.14

Появились template string literals (t-strings).

В отличие от f-strings, они:

• не возвращают готовую строку

• возвращают объект Template

• отдельно хранят текст и подставленные значения

Пример:

query = t"SELECT * FROM users WHERE name = {user_input}"

Теперь можно:

• получить все интерполяции
• проверить значения
• экранировать или валидировать их
• и только потом собрать финальный SQL

safe = safe_sql(query)

Результат:

• вредоносный ввод очищается
• SQL-инъекции блокируются
• таблицы остаются на месте

Почему это важно

f-strings - быстрые, но опасные для SQL.

t-strings позволяют сохранить удобство шаблонов и добавить контроль безопасности.

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

📌 EXISTS РАБОТАЕТ БЫСТРЕЕ COUNT

SQL-совет: перестаньте считать всё через COUNT(*)

Многие пишут так:

SELECT COUNT(*)
FROM orders
WHERE user_id = 123;

Чтобы проверить — есть ли записи.

Проблема:
COUNT(*) считает все строки, даже если нужна просто проверка существования.
На больших таблицах это лишняя нагрузка и медленный запрос.

Правильнее использовать EXISTS.

Почему это лучше:
- База останавливается на первой найденной строке
- Меньше чтения данных
- Быстрее на больших таблицах
- Использует индексы эффективнее

Пример:

-- Плохо
SELECT COUNT(*)
FROM orders
WHERE user_id = 123;

-- Хорошо
SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 123
);

-- Или в условии
SELECT *
FROM users u
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.id
);

📌 UI-TARS-desktop — открытое приложение-агент с GUI, которое превращает ваш компьютер в **интерактивного AI-ассистента** с визуальным восприятием и управлением интерфейсом.

Что это и зачем:

🤖 AI-агент, который видит и кликает
Проект основан на модели UI-TARS (User Interface — Task Automation & Reasoning System). Агент реально *видит экран*, распознаёт элементы интерфейса и может управлять мышью, клавиатурой и браузером по простым естественным командам.

🖥️ Контроль компьютера на естественном языке
Вместо интеграций через API вы пишете команды, а модель сама ищет кнопки, поля ввода и прочие UI-элементы, затем *выполняет действия*. Это работает с приложениями, браузером и элементами рабочего стола.

⚙️ Open-source и кросс-платформа
Проект распространяется под Apache-лицензией, есть релизы, активная история версий и документация для запуска на Windows и macOS. :

📦 Цели проекта
UI-TARS-desktop — это не просто демонстрация: это полноценный мультимодальный AI-агентный стек, который можно использовать для автоматизации повседневных задач без ручного вмешательства.

Страница репозитория: github.com/bytedance/UI-TARS-desktop

🖥 Большие таблицы в SQL - сначала план, потом запрос

Самый полезный апгрейд, который реально экономит часы: не "оптимизировать запрос на глаз", а заставить базу самой показать, что она делает.

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

Железное правило: прежде чем трогать код, запускают EXPLAIN ANALYZE и смотрят две красные зоны - Seq Scan на большой таблице и огромные строки после JOIN. Если видишь Seq Scan - значит фильтр не поддержан индексом или условие написано так, что индекс не используется. Если после JOIN получаются миллионы строк - значит нужно сначала отфильтровать и/или агрегировать, а потом соединять.

Самый мощный прием для больших таблиц: сначала выбрать маленький набор ключей (CTE или подзапрос), и только потом JOIN к тяжелой таблице. Это резко уменьшает работу базы, потому что она перестает "перемножать" всё со всем.

ПЛОХО: тяжелый JOIN сразу, база тащит миллионы строк
SELECT u.id, COUNT(e.*) AS events_30d
FROM users u
JOIN events e ON e.user_id = u.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
  AND u.country = 'TH'
GROUP BY u.id;

-- ХОРОШО: сначала сузить пользователей до маленького набора, потом JOIN
WITH target_users AS (
  SELECT id
  FROM users
  WHERE country = 'TH'
)
SELECT tu.id, COUNT(*) AS events_30d
FROM target_users tu
JOIN events e ON e.user_id = tu.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
GROUP BY tu.id;

-- Индексы, которые реально помогают этому паттерну
CREATE INDEX IF NOT EXISTS idx_users_country_id ON users (country, id);
CREATE INDEX IF NOT EXISTS idx_events_user_time ON events (user_id, created_at);

-- Всегда проверяй, что база использует индекс, а не Seq Scan
EXPLAIN (ANALYZE, BUFFERS)
WITH target_users AS (
  SELECT id FROM users WHERE country = 'TH'
)
SELECT tu.id, COUNT(*)
FROM target_users tu
JOIN events e ON e.user_id = tu.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
GROUP BY tu.id;