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 982 підписників, посідаючи 3 620 місце в категорії Технології та додатки та 17 762 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 35 982 підписників.
За останніми даними від 02 вересня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 107, а за останні 24 години на 8, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 6.06%. Протягом перших 24 годин після публікації контент зазвичай збирає 3.50% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 179 переглядів. Протягом першої доби публікація в середньому набирає 1 259 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 9.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як sql, индекс, postgres, index, sqlite.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Завдяки високій частоті оновлень (останні дані отримано 03 вересня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
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