Data Science. SQL hub

✅ ШПАРГАЛКА: Как правильно поднимать БД перед проектом

Главная ошибка новичков - “у всех база разная”.
В итоге миграции ломаются, схема плывёт, на CI одно, у тебя другое, в проде третье.

Правильный старт всегда одинаковый:

1) Поднимай БД через Docker - чтобы у всей команды окружение было идентичным
2) Все параметры (пароль, порт, имя БД) храни в .env
3) Схему меняй ТОЛЬКО через миграции (Flyway/Liquibase/EF/Alembic)
4) Добавь healthcheck - сервис не должен стартовать раньше БД
5) Сделай команды backup/restore - пригодится в любой момент

Так ты гарантируешь:
- у всех одна и та же база
- быстрый старт проекта за 3 минуты
- деплой без сюрпризов

1) Создай .env
cat > .env << 'EOF'
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=app123
POSTGRES_PORT=5432
EOF

2) docker-compose.yml для Postgres + healthcheck
cat > docker-compose.yml << 'EOF'
services:
  postgres:
    image: postgres:16
    container_name: app-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "${POSTGRES_PORT}:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 20

volumes:
  pgdata:
EOF

3) Запуск
docker compose up -d

4) Проверка
docker compose ps

5) Backup
docker exec -t app-postgres pg_dump -U app app > backup.sql

6) Restore
cat backup.sql | docker exec -i app-postgres psql -U app -d app

Отменяем все мемы про дроп базы

🚀 Супербыстрая JSON-библиотека Tachyon v6.0

Tachyon — это высокопроизводительная библиотека JSON на C++20, обеспечивающая скорость парсинга до 4500 MB/s благодаря оптимизациям AVX2 и уникальной архитектуре "Dual-Engine". Она значительно превосходит аналогичные библиотеки, такие как simdjson и nlohmann::json.

🚀 Основные моменты:
- Высокая скорость парсинга до 4500 MB/s
- Поддержка JSON и JSONC с комментариями
- Современный API C++20 с нулевым накладным расходом
- Ленивая индексация и нулевое копирование данных
- Строгая типизация и совместимость с STL

📌 GitHub: https://github.com/wilkolbrzym-coder/Tachyon.JSON

🛠️ Локальная панель для Cloudflare Workers

Localflare — это инструмент для разработки, который упрощает взаимодействие с вашими ресурсами Cloudflare, такими как D1 базы данных, KV пространства и R2 бакеты. Он предлагает интуитивно понятный интерфейс для визуализации и управления данными в процессе разработки.

🚀 Основные моменты:
- Полнофункциональный SQL-редактор для D1 баз данных
- Удобный браузер для работы с KV парами
- Менеджер файлов для R2 бакетов
- Инспектор очередей для тестирования сообщений
- Работает с любыми фреймворками без настройки

📌 GitHub: https://github.com/rohanprasadofficial/localflare

🚀 Timescale выпустил pg-aiguide: практический гайд по ИИ в PostgreSQL

Timescale опубликовал открытый репозиторий pg-aiguide - это собрание лучших практик, примеров и шаблонов по работе с ИИ поверх PostgreSQL (в том числе TimescaleDB).

Что внутри:
- примеры интеграции LLM и AI-функций с БД
- готовые SQL-рецепты и расширения
- семантический поиск и анализ данных
- шаблоны, которые можно сразу использовать в проде

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

👉 https://github.com/timescale/pg-aiguide

@sqlhub

🖥 Большой апдейт для Postgres: нормальный поиск прямо в базе

У Postgres давно есть full-text search, но честно - качество ранжирования часто “так себе”.

Если нужен реально удобный поиск по релевантности, обычно приходилось:
- поднимать Elasticsearch
- или подключать Algolia
- и потом вечно мучаться с синхронизацией данных между системами

Проблема не в том, что Postgres не умеет искать текст.
Проблема в том, что стандартный ts_rank даёт довольно базовое ранжирование и сильно уступает современным поисковикам.

Теперь появилась альтернатива.

Команда TigerDatabase выложила в open-source расширение pg_textsearch - оно приносит BM25 ранжирование прямо в Postgres.

Почему BM25 важно:
BM25 - это алгоритм, который лежит в основе Elasticsearch/Lucene и большинства “нормальных” поисковых движков.
То есть это уже проверенный стандарт качества поиска.

Что даёт pg_textsearch:
- BM25 ранжирование с настройками параметров
- очень простой синтаксис:
ORDER BY content <@> 'search terms'
- работает с multi-language конфигами Postgres
- хорошо сочетается с pgvector для hybrid search (keyword + embeddings)

Для RAG это прям полезно:
можно делать гибридное извлечение в одной базе (Postgres),
без внешнего Elasticsearch и без лишнего glue-кода.

И всё это - open-source под лицензией PostgreSQL.

https://github.com/timescale/pg_textsearch

🖥 Нашёл любопытный проект: `cq` —-SQL query engine для CSV-файлов, написанный на C.

Что умеет:

- выполнять SQL-запросы прямо по CSV
- фильтровать, агрегировать, делать JOIN’ы
- работать быстро и без “тяжёлых” зависимостей
- подходит для логов, датасетов, ETL-скриптов и ад-hoc анализа

То есть вместо Python-скриптов или импорта в БД —
можно просто кинуть SELECT по файлу и получить результат.

⚡️ Репозиторий: https://github.com/baldimario/cq/

🚀🐬 Вышел MySQL 8.4.8 (LTS) - что нового

Доступен релиз MySQL 8.4.8 - это ветка Long-Term Support, то есть лучший выбор для продакшена: стабильность, долгий цикл поддержки и предсказуемые обновления.

Ключевые улучшения:
👉 InnoDB Redo Logging
- сообщения об ошибках стали информативнее
- теперь показывают текущий LSN и детали по redo log capacity
=> проще диагностировать проблемы с redo log и производительностью

👉 OpenSSL обновили до 3.0.18
- важное обновление для безопасности и совместимости

👉 Исправления багов и стабильность
- закрыли race conditions в InnoDB
- починили проблемы с очисткой binary logs (binlog purging)
- в целом релиз направлен на надёжность и производительность

Если ты сидишь на MySQL в проде - LTS 8.4.x выглядит как правильный путь обновления.

https://dev.mysql.com/downloads/mysql/

@sqlhub

⚡️ ИИ для SQL: пусть он объяснит «почему запрос тормозит»

Профессиональный лайфхак:
не проси ИИ «оптимизировать запрос» вслепую.
Вместо этого — давай ему EXPLAIN / EXPLAIN ANALYZE и структуру таблиц.

ИИ отлично умеет:
- разбирать план выполнения
- находить узкие места (Seq Scan, лишние JOIN, сортировки)
- предлагать индексы и переписывание запроса по факту, а не наугад

Алгоритм простой:
1️⃣ запускаешь EXPLAIN ANALYZE
2️⃣ прикладываешь схему таблиц
3️⃣ спрашиваешь: *где bottleneck и что бы ты поменял?*

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

пример «правильного» запроса к ИИ с реальными данными

-- запрос
SELECT *
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
AND c.country = 'US'
ORDER BY o.created_at DESC
LIMIT 100;

-- план выполнения
EXPLAIN ANALYZE
SELECT ...
-- (сюда вставь полный план: Seq Scan / Index Scan / сортировки и т.п.)

-- схема таблиц (важно!)
\d orders
\d customers

-- вопрос ИИ:
"Разбери план выполнения. 
Где узкие места? 
Нужны ли индексы и какие именно? 
Можно ли переписать запрос быстрее, не меняя логику?"

@sqlhub

🧱 Миграции без боли: как обновлять БД безопасно и без простоя

Сохраняй себе: в реальных проектах миграции - это не “ALTER TABLE и поехали”, а зона риска.

Один неверный шаг = даунтайм, блокировки и откат вручную.

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

Рабочая стратегия (2 шага)
1) Сначала добавляй новое, не ломая старое
- добавляй новые колонки/таблицы
- не удаляй и не переименовывай сразу
- не делай NOT NULL без дефолта

2) Потом переключай код
- сначала раскатываешь схему
- потом деплоишь код, который пишет/читает новое
- и только после этого убираешь старое

Это называется “expand → migrate → contract” и это стандарт продакшн-миграций.

Фишки, которые спасают на проде
- всегда делай миграцию идемпотентной (IF EXISTS / IF NOT EXISTS)
- не держи транзакцию долго
- избегай тяжёлых ALTER на больших таблицах
- проверяй количество строк, прежде чем апдейтить
- делай бэкап/дамп перед большим изменением

-- safe-migration.sql

-- 1) EXPAND: добавляем новое, не ломая старое
ALTER TABLE users
ADD COLUMN IF NOT EXISTS email_verified BOOLEAN DEFAULT FALSE;

CREATE INDEX IF NOT EXISTS idx_users_email
ON users(email);

-- 2) MIGRATE: переносим данные маленькими шагами (пример)
-- (в реальности делается батчами на больших таблицах)
UPDATE users
SET email_verified = TRUE
WHERE email IS NOT NULL AND email <> '';

-- 3) CONTRACT: удаляем старое только после деплоя кода
-- (делать отдельной миграцией!)
-- ALTER TABLE users DROP COLUMN old_email_flag;

🖥 SQL-квест: фэнтезийное приключение для аналитиков данных

Представь фэнтези-мир, где заклинания - это SQL-запросы, а древние артефакты спрятаны в таблицах и JSON-документах.

🧙Ты - боевой дата-аналитик, который с помощью SQL, Python, ETL и визуализаций охотится за харизматичным злодеем Архивариусом Пакостусом, что ломает индексы, крадёт данные и готовит “шторм данных” на столицу.🔮

В каждом эпизоде тебя ждут: выборы с последствиями, хитрые задачи от простых SELECT до рекурсивных CTE и BigQuery, юмор, эпик и неожиданные повороты.

Хочешь проверить, сможешь ли ты спасти королевство не мечом, а запросами? Тогда добро пожаловать в SQL-квест.

🪄 Начать квест: https://uproger.com/sql-kvest-fentezijnoe-priklyuchenie-dlya-analitikov-dannyh/

👻 gh-ost - инструмент для миграций схемы MySQL без даунтайма.

Если тебе надо сделать ALTER TABLE на большой продовой таблице и не положить сервис - gh-ost это прям must-have.

Большинство online-schema-change тулов используют триггеры и создают лишнюю нагрузку.
А gh-ost идёт по другому пути:

✅ Triggerless - вообще без триггеров
✅ Читает изменения через binlog stream и асинхронно применяет их к “ghost table”
✅ Даёт полный контроль над процессом миграции:
- пауза/резюм
- throttle (снижение нагрузки)
- аудит и статус
- безопасный cut-over

Как это работает (по-простому):
1) создаётся “ghost table” с новой схемой
2) данные копируются постепенно
3) параллельно изменения ловятся из binlog
4) в конце таблицы меняются местами почти мгновенно

Идеально для:
🔥 таблиц на десятки миллионов строк
🔥 production-систем
🔥 миграций без блокировок

📌 Репо: github.com/github/gh-ost

🛠️ Легкий TUI для работы с SQL базами данных

sqlit - это удобный инструмент для быстрого выполнения запросов к различным SQL базам данных, включая PostgreSQL, MySQL, SQLite и другие. Он предлагает интуитивно понятный интерфейс, позволяя легко управлять соединениями и историей запросов без необходимости в сложных настройках.

🚀Основные моменты:
- Поддержка множества баз данных без дополнительных адаптеров
- Удобный интерфейс для управления соединениями
- Встроенная история запросов с возможностью поиска
- Поддержка SSH туннелей для безопасного подключения
- Редактирование в стиле Vim для терминальных пользователей

📌 GitHub: https://github.com/Maxteabag/sqlit

#python

🎨 TailwindSQL: SQL Queries with Tailwind-style Syntax

TailwindSQL позволяет писать SQL-запросы, используя синтаксис, похожий на классы Tailwind. Просто укажите className в React Server Components, чтобы получать данные из базы данных без лишнего кода на клиенте.

🚀 Основные моменты:
- 🎨 Синтаксис в стиле Tailwind для SQL-запросов
- ⚡ Поддержка React Server Components без клиентского JavaScript
- 🔒 Использует SQLite для быстрого доступа к локальным базам данных
- 🎯 Запросы обрабатываются на этапе сборки/рендеринга
- 🎭 Разнообразные режимы отображения: текст, списки, таблицы или JSON

📌 GitHub: https://github.com/mmarinovic/tailwindsql

#javascript

⚡️ Vector search: Кидать историю чата в векторную БД - это не «память».

Это просто поиск по смыслу. RAG хорошо достаёт документы,
но не держит состояние пользователя.

Здесь может помочь Mem0 - open-source слой памяти между человеком и LLM.

Он учится на диалогах и сохраняет то, что важно.

Что даёт:

- 🧠 помнит предпочтения (не только факты)
- ✂️ сжимает историю — меньше токенов и быстрее ответы
- 🤝 делится знаниями между несколькими агентами


Если система не помнит опыт - это не агент, а поисковик.
Mem0 делает память - живой и адаптивной.

https://github.com/mem0ai/mem0