Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
Больше📈 Аналитический обзор Telegram-канала Data Science. SQL hub
Канал Data Science. SQL hub (@sqlhub) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 35 926 подписчиков, занимая 3 613 место в категории Технологии и приложения и 17 732 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 35 926 подписчиков.
Согласно последним данным от 30 августа, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило 45, а за последние 24 часа — 0, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 6.57%. В первые 24 часа после публикации контент обычно набирает 3.47% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 2 361 просмотров. В течение первых суток публикация набирает 1 246 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 11.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как sql, индекс, postgres, index, sqlite.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Благодаря высокой частоте обновлений (последние данные получены 31 августа, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
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 appts_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_textsearchSELECT по файлу и получить результат.
⚡️ Репозиторий: https://github.com/baldimario/cq/
пример «правильного» запроса к ИИ с реальными данными
-- запрос
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
-- 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;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