Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
Mostrar más📈 Análisis del canal de Telegram Data Science. SQL hub
El canal Data Science. SQL hub (@sqlhub) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 35 926 suscriptores, ocupando la posición 3 613 en la categoría Tecnologías y Aplicaciones y el puesto 17 732 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 35 926 suscriptores.
Según los últimos datos del 30 agosto, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 45, y en las últimas 24 horas de 0, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 6.57%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 3.47% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 361 visualizaciones. En el primer día suele acumular 1 246 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 11.
- Intereses temáticos: El contenido se centra en temas clave como sql, индекс, postgres, index, sqlite.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 31 agosto, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
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