Data Science. SQL hub

🐘 Slonik — проверенный клиент PostgreSQL для Node.js с строгой типизацией и детальным логированием. Этот инструмент решает проблему безопасности и предсказуемости работы с SQL-запросами: вместо ручного формирования запросов проект заставляет использовать литералы с автоматическим экранированием параметров. Интересна встроенная интеграция с Zod для валидации результатов запросов, она предотвращает ошибки при изменении схемы БД без обновления кода. Также Slonik умеет логировать стектрейсы вызовов запросов и перезапускать упавшие транзакции. 🤖 GitHub @sqlhub

Изучите секреты самых популярных open source key-value СУБД – Redis и Valkey В высоко-нагруженных сервисах Redis — не просто кэш, а важная подсистема, на которой строится значимая часть бизнес-логики. От его стабильности, масштабируемости и отказоустойчивости зависит производительность всего сервиса. Valkey - это современный производительный форк Redis с открытым исходным кодом, поддерживаемый сообществом и рядом крупных компаний. Valkey набирает популярность, поддержан крупными облачными провайдерами, и вполне возможно потеснит или вовсе заменит Redis со временем. Наш курс — для тех, кто хочет держать свой стэк и знания актуальными и глубоко разбираться, как устроен Redis и Valkey. 🌐 В программе курса: 🤩 Как эффективно использовать базовые и продвинутые структуры данных: HyperLogLog, Bitmaps и Bisields, Streams, Geospatial-индексы, Bloom Filters 🤩 Как проектировать in-memory системы, которые не разваливаются под нагрузкой, что влияет на отказоустойчивость и как её добиться 🤩 Как работает репликация и кластеризация на практике (режимы Sentinel и Cluster) 🤩 Как встроить Redis/Valkey в реальный прод с учётом безопасности, интеграций и современных практик мониторинга. 🥸 Кто мы: R&D-центр Devhands. Автор курса — Константин Ратвин — преподаватель МФТИ на кафедре БИТ (совместно со СберТех), эксперт по распределённым системам и банковским ИТ, автор курсов по СУБД и инфраструктуре, спикер HighLoad++ и PGConf. 🗓 Старт курса: 9 июня, 6 недель обучения. Изучить программу и записаться можно здесь. Ждем вас! Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqwXctGc

🦦 Walrus — удобная обёртка над Redis для Python-разработчиков. Этот проект расширяет стандартный клиент redis-py, добавляя к нему набор полезных абстракций для работы с Redis. Вместо того чтобы заставлять изучать новый API, Walrus предлагает привычный интерфейс с дополнительными возможностями. При этом проект остаётся лёгковесным и сохраняет совместимость с альтернативными Redis-подобными базами вроде rlite. 🤖 GitHub @sqlhub

Если вы размышляете, как усилить своё резюме, наш совет — освойте SQL. Это язык, который помогает извлекать ценную информацию из массивов данных. Познакомиться с инструментом можно на бесплатном курсе «Введение в SQL и работу с базой данных». За 5 занятий вы научитесь создавать, редактировать и обновлять базы данных, сделаете свои первые запросы и отчёты. Курс будет полезен даже тем, кто пока не собирается становиться аналитиком. Научитесь применять SQL в своих задачах — с ним вы сможете больше – https://netolo.gy Реклама. ООО "Нетология". ИНН 7726464125 Erid: 2VSb5y1d224

🧠 SQL-задача с подвохом: “Самый активный — или самый невидимый?” 📘 Условие У тебя есть две таблицы:

users(id, name)
posts(id, user_id, title)

Вопрос: Выведи всех пользователей, у которых нет ни одного поста, а также пользователя, у которого больше всего постов. 📌 Но — в одном запросе. ❓ Попробуй решить задачу таким SQL:

SELECT u.name, COUNT(p.id) AS post_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
GROUP BY u.name
HAVING COUNT(p.id) = 0 OR COUNT(p.id) = (
    SELECT MAX(cnt)
    FROM (
        SELECT COUNT(*) AS cnt
        FROM posts
        GROUP BY user_id
    ) t
);

🔍 Вопрос: 1) Почему он может вернуть неправильный результат? 2) В чём разница между COUNT(*) и COUNT(p.id)? 3) Как переписать его правильно? ✅ Разбор подвоха 💣 Подвох 1: COUNT(p.id) пропускает NULL Когда ты делаешь LEFT JOIN, для пользователей без постов p.id = NULL. • COUNT(*) считает все строки (включая NULL) • COUNT(p.id) не считает строки, где p.id IS NULL 👉 Это может привести к тому, что: • COUNT(p.id) = 0 — действительно "нет постов" • но в подзапросе SELECT COUNT(*) считает иначе и даёт искаженную MAX(cnt) 🔁 Как правильно: 1) Подзапрос должен использовать COUNT(p.id), чтобы сравнение было честным 2) Либо использовать JOIN вместо LEFT JOIN в подзапросе, чтобы не попасть на "нулевых" пользователей ✅ Финальный корректный запрос:

SELECT u.name, COUNT(p.id) AS post_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
GROUP BY u.name
HAVING COUNT(p.id) = 0
   OR COUNT(p.id) = (
       SELECT MAX(cnt)
       FROM (
           SELECT user_id, COUNT(p.id) AS cnt
           FROM posts
           GROUP BY user_id
       ) AS ranked
   );

🎯 Такой запрос честно покажет: • Всех “молчунов” (0 постов) • И самого активного автора (макс постов) 📌 Отлично подходит для собеседования или тех, кто считает, что "GROUP BY — это просто". @sqlhub

🧠 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 или status — NULL? 🔍 Подвох: На первый взгляд запрос правильный: мы группируем по клиентам и суммируем их заказы. Но вот критичные моменты: 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-обработки, позволяющий описывать весь 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 и 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‑86 → SQL‑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 и решить возникающие проблемы. 📗 На вебинаре 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` Предположим что у нас есть два коннекта к базе (одной или нескольким, это не важно). Далее используя 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! 🔋 Экономия памяти: по сравнению с 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 мая.

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