Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Data Science. SQL hub
تُعد قناة Data Science. SQL hub (@sqlhub) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 35 981 مشتركاً، محتلاً المرتبة 3 626 في فئة التكنولوجيات والتطبيقات والمرتبة 17 779 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 35 981 مشتركاً.
بحسب آخر البيانات بتاريخ 01 سبتمبر, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 100، وفي آخر 24 ساعة بمقدار 31، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 6.16%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 3.44% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 2 216 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 237 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 10.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل sql, индекс, postgres, index, sqlite.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 02 سبتمبر, 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