ru
Feedback
Data Science. SQL hub

Data Science. SQL hub

Открыть в Telegram

По всем вопросам- @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 839 подписчиков, занимая 3 835 место в категории Технологии и приложения и 18 129 место в регионе Россия.

📊 Показатели аудитории и динамика

С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 35 839 подписчиков.

Согласно последним данным от 13 июня, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -8, а за последние 24 часа — -11, при этом общий охват остаётся высоким.

  • Статус верификации: Не верифицирован
  • Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 9.82%. В первые 24 часа после публикации контент обычно набирает 4.08% реакций от общего числа подписчиков.
  • Охват публикаций: В среднем каждый пост получает 3 522 просмотров. В течение первых суток публикация набирает 1 461 просмотров.
  • Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 13.
  • Тематические интересы: Контент сосредоточен на ключевых темах, таких как sql, индекс, postgres, index, sqlite.

📝 Описание и контентная политика

Автор описывает ресурс как площадку для выражения субъективного мнения:
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ

Благодаря высокой частоте обновлений (последние данные получены 14 июня, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.

35 839
Подписчики
-1124 часа
-317 дней
-830 день
Архив постов
🧠 SQL-задача с подвохом (Oracle) Тема: оконные функции, группировка, ловушка в агрегатах 📌 Задача: Есть таблица SALES со следующей структурой:

CREATE TABLE SALES (
  ID         NUMBER,
  REGION     VARCHAR2(20),
  SALE_DATE  DATE,
  AMOUNT     NUMBER
);
Пример данных: | ID | REGION | SALE_DATE | AMOUNT | |----|--------|-----------|--------| | 1 | North | 01-JAN-24 | 100 | | 2 | North | 02-JAN-24 | 120 | | 3 | South | 01-JAN-24 | 90 | | 4 | South | 03-JAN-24 | 200 | | 5 | East | 01-JAN-24 | 150 | | 6 | East | 02-JAN-24 | 100 | 🧩 Найти: Для каждого региона — ту дату, в которую была вторая по величине сумма продаж. Если в регионе меньше двух дат — не выводить его вовсе. 🎯 Подвох: - нельзя использовать LIMIT, FETCH FIRST, QUALIFY и подзапросы с ROWNUM напрямую (нужно решение через оконные функции Oracle) - многие пытаются взять MAX(AMOUNT) с OFFSET 1, но в Oracle это не так просто ✅ Ожидаемый результат: | REGION | SALE_DATE | AMOUNT | |--------|-----------|--------| | North | 01-JAN-24 | 100 | | South | 01-JAN-24 | 90 | | East | 02-JAN-24 | 100 | 🔍 Решение: ```sql SELECT REGION, SALE_DATE, AMOUNT FROM ( SELECT REGION, SALE_DATE, AMOUNT, DENSE_RANK() OVER (PARTITION BY REGION ORDER BY AMOUNT DESC) AS rnk, COUNT(DISTINCT SALE_DATE) OVER (PARTITION BY REGION) AS cnt FROM SALES ) WHERE rnk = 2 AND cnt >= 2; ``` 📌 **Объяснение подвоха:** - `DENSE_RANK` гарантирует, что если есть одинаковые суммы, они получат один и тот же ранг - `COUNT(DISTINCT SALE_DATE)` проверяет, что у региона хотя бы две разные даты (иначе регион исключается) - Работает чисто на оконных функциях, без подзапросов с ROWNUM — идеально для Oracle 🧪 Проверь результат и попробуй адаптировать под похожие задачи с TOP-N логикой. @sqlhub

🛢️ SQL-задача с подвохом: GROUP BY и скрытая ловушка Условие: Есть таблица orders: | id | customer_id | amount | status | |-----|-------------|--------|-----------| | 1 | 101 | 200 | completed | | 2 | 102 | 150 | NULL | | 3 | 101 | 300 | completed | | 4 | 103 | NULL | completed | | 5 | 102 | 100 | completed | | 6 | 101 | 250 | NULL | Задача: найти всех клиентов, у которых сумма заказов больше 500. Ты пишешь запрос:

SELECT customer_id, SUM(amount) as total
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 500;
Вопрос: Какие клиенты вернутся? Есть ли тут подвох? Что произойдёт с заказами, где amount или statusNULL? 🔍 Подвох: На первый взгляд запрос правильный: мы группируем по клиентам и суммируем их заказы. Но вот критичные моменты: 1️⃣ Что происходит с NULL в `amount`? В SQL агрегатные функции (например, SUM) игнорируют NULL значения. Это значит: - Заказ id=4 (`amount = NULL`) не участвует в суммировании. - Заказ id=6 (`amount = 250`) участвует, потому что amount не NULL. 2️⃣ Считаем по каждому клиенту: - customer_id=101: - id=1: 200 - id=3: 300 - id=6: 250 Итого: 200 + 300 + 250 = 750 - customer_id=102: - id=2: 150 - id=5: 100 Итого: 150 + 100 = 250 - customer_id=103: - id=4: NULL (игнорируется) Итого: 0 3️⃣ Кто попадёт в результат: Только customer_id=101 (с суммой 750 > 500). --- ✅ Результат: | customer_id | total | |-------------|--------| | 101 | 750 | --- 💥 Подвох #2: Допустим ты случайно написал:

HAVING SUM(amount) IS NOT NULL AND SUM(amount) > 500;
Кажется логичным? А вот нет: SUM всегда возвращает 0 (не NULL), даже если у клиента нет заказов с ненулевой суммой. ➡️ Даже клиент с только NULL значениями (например, customer_id=103) получит SUM(amount) = 0, а не NULL. Это частая ловушка: COUNT, SUM, AVG игнорируют NULL внутри, но результат НЕ NULL (обычно 0 или NULL в зависимости от агрегата). --- 🛠 Что ещё важно: • Если хочешь учитывать только выполненные заказы (status = 'completed'), нужно добавить:

WHERE status = 'completed'
⚠️ Не пиши условие в HAVING для фильтрации строк — лучше фильтровать через WHERE до группировки.Вывод: - ✅ Агрегатные функции типа SUM игнорируют NULL внутри группы. - ✅ SUM возвращает 0, даже если все значения NULL (НЕ NULL, как думают многие). - ✅ HAVING применяется ПОСЛЕ группировки, а WHERE — ДО. - ✅ Ошибки часто возникают, если условие на фильтр пишут в HAVING вместо WHERE. 💡 Бонус-вопрос: Что будет, если заменить SUM(amount) на COUNT(amount) в SELECT и HAVING? И как это повлияет на клиентов с NULL значениями? @sqlhub

🖥 SQL Flow SQL Flow позиционируется как «DuckDB для потоковых данных» — лёгковесный движок stream-обработки, позволяющий опи
🖥 SQL Flow SQL Flow позиционируется как «DuckDB для потоковых данных» — лёгковесный движок stream-обработки, позволяющий описывать весь pipeline единственным языком SQL и служащий компактной альтернативой Apache Flink. 🔍 Ключевые возможности: - Источники (Sources): Kafka, WebSocket-стримы, HTTP-webhooks и др. - Приёмники (Sinks): Kafka, PostgreSQL, локальные и S3-подобные хранилища, любые форматы, которые поддерживает DuckDB (JSON, Parquet, Iceberg и т.д.). - SQL-обработчик (Handler): встраивает DuckDB + Apache Arrow; поддерживает агрегаты, оконные функции, UDF и динамический вывод схемы. - Управление окнами: in-memory tumbling-windows, буферные таблицы. - Наблюдаемость: встроенные Prometheus-метрики (с релиза v0.6.0). 🔗 Архитектура Конвейер описывается YAML-файлом с блоками `source → handler → sink`. Во время выполнения: 1. Source считывает поток (Kafka, WebSocket …). 2. Handler выполняет SQL-логику в DuckDB. 3. Sink сохраняет результаты в выбранное хранилище. ✅ Быстрый старт (≈ 5 минут)

# получить образ
docker pull turbolytics/sql-flow:latest

# тестовая проверка конфигурации
docker run -v $(pwd)/dev:/tmp/conf \
           -v /tmp/sqlflow:/tmp/sqlflow \
           turbolytics/sql-flow:latest \
           dev invoke /tmp/conf/config/examples/basic.agg.yml /tmp/conf/fixtures/simple.json

# запуск против Kafka
docker-compose -f dev/kafka-single.yml up -d      # поднять Kafka

docker run -v $(pwd)/dev:/tmp/conf \
           -e SQLFLOW_KAFKA_BROKERS=host.docker.internal:29092 \
           turbolytics/sql-flow:latest \
           run /tmp/conf/config/examples/basic.agg.mem.yml --max-msgs-to-process=10000
Github @sqlhub

💫 GlueSQL — SQL-движок, превращающий любые данные в полноценную базу данных. Этот инструмент умеет выполнять JOIN между CSV
💫 GlueSQL — SQL-движок, превращающий любые данные в полноценную базу данных. Этот инструмент умеет выполнять JOIN между CSV и MongoDB, работать с Git как с хранилищем данных и даже запускать SQL-запросы прямо в браузере через WebAssembly. Что отличает GlueSQL от классических СУБД? - Поддержка schemaless-данных - Встроенные адаптеры для 10+ форматов - Возможность добавлять свои хранилища через реализацию двух traits на Rust Проект активно развивается: недавно добавили поддержку транзакций в Sled-бэкенде и анонсировали облачную версию. Для теста достаточно cargo add gluesql и уже можно писать SQL-запросы к данным в памяти. 🤖 GitHub @sqlhub

# 🧩 Задача для SQL-аналитиков: "Пропавшие продажи" 📖 Описание задачи У вас есть таблица sales, где хранятся данные о продажах:

CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    product_id INT,
    quantity INT,
    price DECIMAL(10,2)
);

INSERT INTO sales (sale_id, sale_date, product_id, quantity, price) VALUES
(1, '2024-01-01', 101, 1, 100.00),
(2, '2024-01-02', 102, 2, 150.00),
-- ...
-- остальные данные
;
Каждый день формируется отчёт, где суммируются продажи по дням:

SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;
Вчера сумма в отчёте была 1,000,000. Сегодня — 980,000, хотя новых записей не удаляли. 📝 Ваша задача: 1. Найти, какие записи "исчезли" из отчёта, если данных в таблице sales фактически не удаляли. 2. Определить, почему эти записи больше не попадают в итоговый запрос. 3. Исправить отчёт, чтобы сумма снова стала 1,000,000. Ограничения: - Таблица не изменилась по количеству строк. - Никто не менял код запроса. - sale_date, quantity, price остались без изменений. Подсказка: возможно, дело в NULL, JOIN или неправильной агрегации. 🕵️ Что проверяет задача: - Знание SQL-агрегации - Понимание NULL и работы SUM - Умение анализировать запросы «не через код», а через их результат - Навык находить «скрытые» ошибки данных (например, sale_date стал NULL) 💡 Решение: При проверке выяснится, что часть записей имеет `sale_date = NULL` (например, кто-то обновил поле sale_date на NULL). Итоговый запрос: ```sql SELECT sale_date, SUM(quantity * price) AS total_sales FROM sales GROUP BY sale_date; ``` не учитывает строки, где `sale_date IS NULL`, потому что GROUP BY игнорирует NULL как отдельную группу (не попадает ни в один существующий `sale_date`). Чтобы увидеть эти записи: ```sql SELECT sale_date, COUNT(*), SUM(quantity * price) FROM sales GROUP BY sale_date; ``` Для восстановления суммы нужно добавить обработку NULL, например: ```sql SELECT COALESCE(sale_date, 'unknown') AS sale_date, SUM(quantity * price) AS total_sales FROM sales GROUP BY COALESCE(sale_date, 'unknown'); ``` ✅ Теперь сумма снова будет 1,000,000, а "пропавшие" продажи попадут в отдельную категорию unknown. 🎯 Эта задача учит: ✅ Всегда думать о данных, а не только о коде ✅ Проверять поля на NULL даже там, где их не ожидаешь ✅ Уметь объяснять ошибки «бизнес-заказчику», а не только исправлять запрос 🔥 Отличная тренировка внимательности и понимания нюансов SQL-агрегации! @sqlhub

📜 История SQL — от лабораторной идеи до «языка данных» № 1 Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках. 1. Всё началось с таблицы на бумаге - 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*. - В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl). - Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике. 2. SEQUEL — «английский» запрос к таблицам - 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R. - Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL. - Ключевая фишка — запросы выглядят почти как английские предложения:

    SELECT name, salary
      FROM employees
     WHERE dept = 'R&D';
    
- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге. 3. Почему SEQUEL стал SQL - Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*. - IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language). - *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».* 4. Коммерческий взлёт - 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий | - 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок - 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется - 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке 5. Стандартизация и эволюция - ANSI SQL‑86SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs). - Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х. 6. Забавные факты, которые украсят small talk 🍸 1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры. 2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах. 3. Команда `GO` в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql. 4. В Oracle долго не было `LIMIT`, а в MySQL — `RIGHT JOIN`. Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`». 5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000. 6. SQL — декларативный язык, но внутри СУБД каждый SELECT превращается в процедурный план. 7. `DROP DATABASE` придумали позже, чем `CREATE`. Сначала удалять целую БД казалось слишком опасным. 7. Почему SQL живёт дольше модных NoSQL‑наследников - Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией. - Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB. - Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект. - Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер SELECT …. Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в FROM.

📕MySQL для администраторов, разработчиков, архитекторов и специалистов баз данных Как грамотно оптимизировать производительн
📕MySQL для администраторов, разработчиков, архитекторов и специалистов баз данных Как грамотно оптимизировать производительность в MySQL и решить возникающие проблемы. 📗 На вебинаре 6 мая в 19:00 разберём: 1. Практические методы оптимизации производительности, диагностику нагрузки и анализ "узких мест" MySQL; 2. Оптимизацию запросов: от простых до сложных. 📘 В результате будете знать всё о настройке ключевых параметров конфигурации, уметь самостоятельно диагностировать и решать проблемы производительности MySQL. 👉 Регистрация и подробности о курсе Базы данных: https://otus.pw/5iMh/?erid=2W5zFGeaQTA Все участники открытого урока получат скидку на курс Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

## 7 полезных приёмов для Oracle SQL Простые советы для Oracle SQL, которые помогут аналитикам данных прокачать свои запросы. 1) Фильтрованные (partial) индексы В Oracle можно создавать индексы только для подмножества строк, чтобы ускорить выборку по популярным условиям.

CREATE INDEX idx_orders_high_value
  ON orders(order_date)
  WHERE total_amount > 1000;
2) Функциональные (function-based) индексы Если фильтруете или джойните по функции, создайте индекс прямо по выражению:

CREATE INDEX idx_orders_year
  ON orders (EXTRACT(YEAR FROM order_date));
3) GROUPING SETS, ROLLUP, CUBE Для одновременной агрегации по нескольким группировкам без UNION ALL:

SELECT region, category, SUM(sales) AS total
FROM sales
GROUP BY ROLLUP (region, category);
4) Материализованные представления с QUERY REWRITE В Oracle можно сделать автоматическую подмену сложного запроса предрасчитанным результатом (материализованным представлением):

CREATE MATERIALIZED VIEW mv_sales_by_month
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
ENABLE QUERY REWRITE
AS
SELECT TRUNC(order_date, 'MM') AS month, SUM(total_amount) AS total
FROM orders
GROUP BY TRUNC(order_date, 'MM');
Теперь запрос SELECT month, SUM(total_amount) FROM orders GROUP BY month; автоматически будет использовать mv_sales_by_month. 5) WITH PL/SQL FUNCTION RESULT CACHE Кэшируйте результат функции, чтобы при одинаковых входных данных не пересчитывать:

CREATE OR REPLACE FUNCTION get_tax_rate(p_region VARCHAR2)
RETURN NUMBER RESULT_CACHE RELIES_ON (tax_table) IS
  v_rate NUMBER;
BEGIN
  SELECT rate INTO v_rate FROM tax_table WHERE region = p_region;
  RETURN v_rate;
END;
6) PARALLEL HINT для ускорения запросов Явно указывайте параллельное выполнение запроса, чтобы задействовать несколько процессов:

SELECT /*+ PARALLEL(orders, 4) */ customer_id, SUM(total_amount)
FROM orders
GROUP BY customer_id;
7) DBMS_STATS.AUTO_SAMPLE_SIZE для сбора статистики Используйте автоматический подбор размера выборки для более точной оптимизации плана выполнения:

EXEC DBMS_STATS.GATHER_TABLE_STATS('HR', 'ORDERS', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE);
Совет: проверяйте планы выполнения через DBMS_XPLAN.DISPLAY_CURSOR, чтобы видеть реальные шаги запроса, а не только предполагаемые. @sqlhub

👣 Небольшой пример как копировать данные между базами данных используя `go`, `pgx`, и `copy` Предположим что у нас есть два
👣 Небольшой пример как копировать данные между базами данных используя `go`, `pgx`, и `copy` Предположим что у нас есть два коннекта к базе (одной или нескольким, это не важно). Далее используя io.Pipe() создаём Reader и Writer, и используя CopyTo() и CopyFrom() переносим данные.
  r, w := io.Pipe()

  doneChan := make(chan struct{}, 1)

  go func() {
      defer close(doneChan)

      _, err := db1.PgConn().CopyTo(ctx, w, `copy table1 to stdin binary`)
      if err != nil {
          slog.Error("error", "error", err)
          return
      }
      _ = w.Close()
      doneChan <- struct{}{}
  }()

  _, err = db2.PgConn().CopyFrom(ctx, r, `copy table1 from stdout binary`)
  _ = r.Close()

  select {
  case <-doneChan:
  case <-ctx.Done():
  }
Вся прелесть тут в том что используем наиболее быстрый способ с точки зрения PostgreSQL. Используя `copy (select * from where ... order by ... limit ...) to stdout `можем регулировать нагрузку на чтение, следить за прогрессом и управлять копированием данных. В качестве Reader может выступать что угодно, хоть файл csv, хоть другая СУБД, но тогда данные придётся дополнительно конвертировать в формат понимаемый PostgreSQL - csv или tsv, и использовать copy ... from stdin (format csv). Нюанс: copy ... from stdin binary , binary обязывает использовать одинаковые типы данных, нельзя будет integer колонку перенести в колонку smallint, если такое требуется, то параметр binary надо опустить. Весь код тут. И ещё немного кода для вдохновения. @Golang_google

🔥 Qwen2.5-Omni-3B — оптимизированная, компактная Omni модель(3B), доступная для запуска на обычных потребительских GPU! 🔋 Э
🔥 Qwen2.5-Omni-3B — оптимизированная, компактная Omni модель(3B), доступная для запуска на обычных потребительских GPU! 🔋 Экономия памяти: по сравнению с 7B-версией модель потребляет на 50 % меньше VRAM при обработке длинного контекста (~25 000 токенов). 📺 Мультимодальные режим: поддержка 30-секундных аудио- и видео«из коробки» на 24 GB видеокартах. 🤖 Высокое качество: модель сохраняет свыше 90 % точности ответов и обеспечивает естественный, стабильный синтез речи на уровне 7B-модели. 🔜 Репозиторий GitHub: https://github.com/QwenLM/Qwen2.5-Omni 🔜Hugging Face: https://huggingface.co/Qwen/Qwen2.5-Omni-3B 🔜ModelScope: https://modelscope.cn/models/Qwen/Qwen2.5-Omni-3B #Qwen #omni #opensource @ai_machinelearning_big_data

Столкнулись с падением производительности базы данных? Не делайте резких движений: вы можете ухудшить ситуацию. Сначала нужно
Столкнулись с падением производительности базы данных? Не делайте резких движений: вы можете ухудшить ситуацию. Сначала нужно верно диагностировать причину проблемы. Возможно вы неправильно выбрали индексы, а быть может дело вообще в самой архитектуре БД – вариантов масса! На открытом вебинаре «Как ускорить работу и повысить надёжность PostgreSQL» вы узнаете: 🎯как обеспечить высокую производительность и отказоустойчивость базы данных 🎯как вовремя выявить деградацию производительности с помощью диагностики Вебинар проведёт Дмитрий Золотов, Kotlin-разработчик в «Яндексе». Приглашаем технических руководителей, админов БД, девопсов и разработчиков. Все участники получат в подарок видеоурок «Безопасность в PostgreSQL: защита данных, управление доступом и аудит» и скидку 7% на любой курс OTUS. 6 мая, 19:00 МСК Бесплатно Записаться - https://otus.pw/sWHl/ Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: 2W5zFG8vzDn

NotebookLM теперь умеет делать подкасты на русском и других славянских языках Новая функция позволяет превращать документы в аудио — можно генерировать как полезные, так и совсем абсурдные подкасты (пример в посте). Идеально, чтобы слушать вместо чтения, например, во время пробежки. Озвучка на русском немного уступает английской, но звучит достойно. 🎧 Бесплатно, пробуем

Приглашаем студентов на бесплатный студкемп Яндекс Образования и ИТМО по управлению данными Готовы попробовать свои силы в ре
Приглашаем студентов на бесплатный студкемп Яндекс Образования и ИТМО по управлению данными Готовы попробовать свои силы в решении реальных задач? Бесплатный студкемп Яндекса и ИТМО — ваш шанс погрузиться в востребованное IT-направление и открыть новые профессиональные горизонты! Во время интенсива вы изучите принципы микросервисных архитектур, освоите системы распределённого хранения и разберётесь с DataOps и MLOps. А ещё будете участвовать в разработке комплексных пайплайнов: от автоматического сбора до визуализации данных. Студкемп пройдёт с 30 июня по 12 июля в Санкт-Петербурге на базе ИТМО. Приглашают студентов со всей России и каждому, кто пройдёт отбор, оплатят проезд и проживание. Успейте подать заявку до 4 мая.

+3
🖥 Крутая подборка шпаргалок по SQL Внутри — SQL для data analysis; — SQL Joins; — Оконные функции; — Основы SQL. @sqlhub

Стартовал набор в ШАД — успейте подать заявку! Технологии меняют нашу реальность, но за их развитием стоят люди, которые умею
Стартовал набор в ШАД — успейте подать заявку! Технологии меняют нашу реальность, но за их развитием стоят люди, которые умеют находить нестандартные решения. И именно в Школе анализа данных Яндекса готовят таких специалистов! Здесь амбициозные и увлечённые студенты: погружаются в машинное обучение, Data Science и искусственный интеллект; перенимают опыт экспертов из индустрии; учатся решать задачи, стоящие перед ведущими IT-компаниями и исследовательскими центрами. Учёба в ШАДе — это серьёзный вызов даже для тех, кто уже знаком с анализом данных. Поступить непросто, но если вы готовы к интенсивной нагрузке, нестандартным кейсам и полной пересборке своего мышления — это место для вас! За 2 года обучения вы получите инструменты и навыки, которые позволят работать над сложнейшими задачами индустрии, запускать собственные проекты и двигать науку вперёд. Занятия полностью бесплатны и проходят по вечерам. Если в вашем городе нет филиала, можно учиться онлайн. Готовы бросить вызов данности? Тогда подавайте заявку до 4 мая!

🔍 Milvus — масштабируемая высокопроизводительная векторная БД для AI-приложений с нативной интеграцией с Kubernetes. Проект
🔍 Milvus — масштабируемая высокопроизводительная векторная БД для AI-приложений с нативной интеграцией с Kubernetes. Проект написан на Go и C++ и оптимизирован для работы с миллиардами векторов в реальном времени. Помимо классических dense-векторов, Milvus поддерживает sparse-модели для полнотекстового поиска и гибридные запросы. Для локального тестирования есть облегченная версия, устанавливаемая через pip. 🤖 GitHub @sqlhub

🖥 Задача: Анализ пользовательского поведения с аномалиями в SQL ## Условие задачи: Дана таблица 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

⚡️Легкий способ получать свежие обновления и следить за трендами в разработке на вашем языке. Находите свой стек и подписывайтесь: Python: t.me/pythonl Linux: t.me/linuxacademiya Собеседования DS: t.me/machinelearning_interview Нерйросети t.me/ai_machinelearning_big_data C++ t.me/cpluspluc Docker: t.me/DevopsDocker Хакинг: t.me/linuxkalii Devops: t.me/DevOPSitsec Data Science: t.me/data_analysis_ml Javascript: t.me/javascriptv C#: t.me/csharp_ci Java: t.me/javatg Базы данных: t.me/sqlhub Python собеседования: t.me/python_job_interview Мобильная разработка: t.me/mobdevelop Golang: t.me/Golang_google React: t.me/react_tg Rust: t.me/rust_code ИИ: t.me/vistehno PHP: t.me/phpshka Android: t.me/android_its Frontend: t.me/front Big Data: t.me/bigdatai МАТЕМАТИКА: t.me/data_math Kubernets: t.me/kubernetc Разработка игр: https://t.me/gamedev Haskell: t.me/haskell_tg Физика: t.me/fizmat 💼 Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка FRONTEND: https://t.me/addlist/mzMMG3RPZhY2M2Iy 😆ИТ-Мемы: t.me/memes_prog 🇬🇧Английский: t.me/english_forprogrammers 🧠ИИ: t.me/vistehno 🎓954ГБ ОПЕНСОРС КУРСОВ: @courses 📕Ит-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy

✔️ Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки
✔️ Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки формат JSON. Возможности - Прослушивание изменений в PostgreSQL в режиме реального времени. - Поддержка нескольких слотов репликации. - Удобный вывод в формате JSON. - Готов к использованию в качестве сервиса. Пример использования 1. Создаём слот репликации:

   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 @sqlhub

Нашел лучший сайт для изучения SQL Хороший ресурс для освоения SQL — SQL Academy! Это интерактивная платформа с практическими заданиями от ведущих российских компаний: ВКонтакте, Альфа-Банка, Сбера и других. Здесь найдётся всё, что нужно разработчикам, аналитикам, тестировщикам и студентам, интересующимся базами данных.интересующихся студентов. Попробовать здесь @sqlhub