Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
Ko'proq ko'rsatish📈 Telegram kanali Data Science. SQL hub analitikasi
Data Science. SQL hub (@sqlhub) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 36 025 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 3 735-o'rinni va Rossiya mintaqasida 17 602-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 36 025 obunachiga ega bo‘ldi.
09 Noyabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 33 ga, so‘nggi 24 soatda esa -8 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 8.83% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 3.95% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 3 181 marta ko‘riladi; birinchi sutkada odatda 1 422 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 8 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent sql, индекс, postgres, index, sqlite kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 10 Noyabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
user_events со следующей структурой:
CREATE TABLE user_events (
user_id INT,
event_time TIMESTAMP,
event_type VARCHAR(50),
platform VARCHAR(50)
);
🎯 Каждая строка описывает событие пользователя:
- user_id — идентификатор пользователя,
- event_time — время события,
- event_type — тип события (`login`, purchase, logout, error и т.д.),
- platform — платформа (`iOS`, Android, `Web`).
Требуется:
1. Найти пользователей, которые:
- Выполнили покупку (`purchase`),
- Но не заходили в систему (`login`) в течение последних 7 дней перед покупкой.
2. Найти пользователей, у которых:
- Более 30% всех событий за последний месяц составляют события типа error.
3. Рассчитать для каждого пользователя:
- Среднее время между входом (`login`) и следующим выходом (`logout`).
- Если logout отсутствует после login — игнорировать такую сессию.
---
## Дополнительные условия:
- Считайте, что данные могут быть объемными: миллионы строк.
- Решение должно быть оптимизировано: избегайте подзапросов в подзапросах без индексов, старайтесь минимизировать количество проходов по данным.
- Можно использовать оконные функции (`WINDOW FUNCTIONS`) и временные таблицы (`CTE`) для упрощения запросов.
- Платформу можно игнорировать в расчетах.
---
## Что оценивается:
- Умение использовать оконные функции и агрегаты.
- Умение правильно интерпретировать условия задачи в SQL-операции.
- Оптимизация запросов под большие объемы данных.
- Чистота, читаемость и структурированность кода SQL-запросов.
---
Примечание:
Эта задача проверяет как технические навыки работы с SQL, так и внимательность к деталям формулировки задачи. Небрежная реализация может дать неверные результаты, особенно на больших данных.
🔥 Подсказки и намёки для решения задачи
## Задание 1: Найти пользователей с покупками без логина за последние 7 дней
**Намёк:**
- Используйте оконную функцию LAG() или MAX() с фильтрацией событий login.
- Для каждой покупки проверяйте, был ли login в пределах 7 дней до события purchase.
- Можно применить LEFT JOIN событий login к событиям purchase.
## Задание 2: Найти пользователей с долей ошибок > 30%
**Намёк:**
- Используйте оконные функции COUNT(*) и SUM(CASE WHEN event_type = 'error' THEN 1 ELSE 0 END).
- Постройте долю ошибок на основе всех событий пользователя за последние 30 дней (`WHERE event_time >= CURRENT_DATE - INTERVAL '30 days'`).
## Задание 3: Рассчитать среднее время между login и следующим logout
**Намёк:**
- Используйте оконную функцию LEAD() для поиска следующего события после login.
- Пара login -> logout должна иметь корректный порядок по времени.
- Отбрасывайте случаи, где следующего logout нет или это событие другого типа.
@sqlhub
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
2. Запускаем wal-listener:
wal-listener --dsn "host=localhost port=5432 user=postgres dbname=test" --slot test_slot
3. Получаем JSON-объекты при изменениях в базе данных.
https://github.com/ihippik/wal-listener
#devops #девопс #PostgreSQL #sql
@sqlhubusers:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT,
deleted_at TIMESTAMP
);
Вы выполняете:
SELECT COUNT(*) FROM users WHERE deleted_at = NULL;
✔️ И получаете... 0. Хотя вы уверены, что есть пользователи, у которых deleted_at не задано.
Вопрос:
Что не так с запросом? Как правильно получить количество “неудалённых” пользователей?
Вопрос: В чем ошибка? И как надо правильно писать такой фильтр?
✔️ Правильный запрос будет выглядеть так:
Чтобы проверить, является ли значение NULL, нужно использовать специальный оператор IS NULL.
SELECT COUNT(*) FROM users WHERE deleted_at IS NULL;
Этот запрос корректно найдёт все строки, где в столбце deleted_at действительно отсутствует значение (т.е. он равен NULL), и посчитает их количество.
Итог:
Не используйте = или != для сравнения с NULL.
Используйте IS NULL для проверки на NULL.
Используйте IS NOT NULL для проверки на не NULL (если бы вам понадобилось посчитать удалённых пользователей, у которых deleted_at заполнено).
@sqlhub
func (vs nodeStore) ReadBytes(...) ...
Этот метод использовал приёмник по значению (vs nodeStore). Это значит, что вся структура копировалась при каждом вызове метода, даже если она большая.
🚑 Как пофиксили
Просто поменяли на приёмник по указателю:
func (vs *nodeStore) ReadBytes(...) ...
Вуаля — аллокейшны исчезли, производительность восстановилась.
🧠 Вывод
❗ Методы с приёмником по значению = риск лишнего копирования и аллокаций
🛠 Даже один маленький метод может резко замедлить ваш код
🔍 Профилировка в Go — мощный инструмент. Используй pprof!
Полный разбор в блоге DoltHub
Подробнее про Dolt
@golang_google