🚀 Обрабатывайте данные больше объёма RAM с автоматическим spillover в DuckDB
Обычно, когда датасет превышает доступную память, инструменты падают или требуют ручного чанкинга и дорогого железа.
DuckDB решает проблему иначе:
он автоматически сбрасывает промежуточные данные на диск, если памяти не хватает.
Пример:
Итог:
- у вас 10GB Parquet
- оперативка только 500MB
- DuckDB сам делает чанки + сбрасывает overflow на диск
- запрос успешно выполняется ✔
Так вы работаете с большими данными без сложных пайплайнов и апгрейда железа.
Обычно, когда датасет превышает доступную память, инструменты падают или требуют ручного чанкинга и дорогого железа.
DuckDB решает проблему иначе:
он автоматически сбрасывает промежуточные данные на диск, если памяти не хватает.
Пример:
duckdb.sql("SET memory_limit = '500MB'")
duckdb.sql("SET temp_directory = '/tmp/duckdb_temp'")
result = duckdb.sql(f"SELECT * FROM '{parquet_path}'").df()
Итог:
- у вас 10GB Parquet
- оперативка только 500MB
- DuckDB сам делает чанки + сбрасывает overflow на диск
- запрос успешно выполняется ✔
Так вы работаете с большими данными без сложных пайплайнов и апгрейда железа.
❤3🥰1
⚡️ SQL-совет:
Используйте filtered indexes (условные индексы) - они ускоряют выборки на больших таблицах, но мало кто о них знает.
Пример для таблицы заказов, где статус "active" запрашивается чаще всего:
Плюсы:
- индекс меньше → быстрее в памяти,
- оптимизатор выбирает его при типичных запросах,
- запросы по активным записям работают значительно быстрее.
Мало кто использует условные индексы, а зря. Они умеют избавлять от лишних full scan почти бесплатно.
Используйте filtered indexes (условные индексы) - они ускоряют выборки на больших таблицах, но мало кто о них знает.
Пример для таблицы заказов, где статус "active" запрашивается чаще всего:
CREATE INDEX idx_orders_active
ON orders(status)
WHERE status = 'active';
Плюсы:
- индекс меньше → быстрее в памяти,
- оптимизатор выбирает его при типичных запросах,
- запросы по активным записям работают значительно быстрее.
Мало кто использует условные индексы, а зря. Они умеют избавлять от лишних full scan почти бесплатно.
👍9❤4🔥4
This media is not supported in your browser
VIEW IN TELEGRAM
16 декабря пройдёт третья конференция Arch.Conf by Sber, где мы говорим об ИТ-архитектуре вместе с большим сообществом.
Вас ждёт keynote-доклад от топ-менеджеров Сбера, 2 стрима, 10 докладов от лидеров отрасли, дискуссии и детальный разбор актуальных вопросов.
▪️ «Архитектура AI-native» — обсудим паттерны построения мультиагентных систем, технологии построения агентов, подходы к работе с эмпатией и борьбу с галлюцинациями агентов.
▪️ «Архитектура — двигатель бизнеса» — поговорим о конкретных архитектурных практиках, которые позволяют откликаться на вызовы рынка быстрее всех.
Участвовать — проще простого:
✔️ Выбрать удобный формат.
✔️ Зарегистрироваться по ссылке!
Вас ждёт keynote-доклад от топ-менеджеров Сбера, 2 стрима, 10 докладов от лидеров отрасли, дискуссии и детальный разбор актуальных вопросов.
▪️ «Архитектура AI-native» — обсудим паттерны построения мультиагентных систем, технологии построения агентов, подходы к работе с эмпатией и борьбу с галлюцинациями агентов.
▪️ «Архитектура — двигатель бизнеса» — поговорим о конкретных архитектурных практиках, которые позволяют откликаться на вызовы рынка быстрее всех.
Участвовать — проще простого:
✔️ Выбрать удобный формат.
✔️ Зарегистрироваться по ссылке!
❤3👍2🔥2
🎯 SQL хитрый трюк, который реально экономит время
Когда выбираешь строки с максимумом/минимумом - не делай два запроса.
Получай значение и саму строку одной командой с оконной функцией:
Что это даёт?
Не нужно сначала находить MAX(amount), а потом искать строку с этим значением.
Один запрос — меньше нагрузки, быстрее читается.
Работает для любых ранжирований: топ-N, bottom-N, лидеры, фильтрации по метрикам.
Меняешь DESC → ASC и получаешь минимум.
А если нужен топ-5 — просто ROW_NUMBER заменяешь на RANK или ограничиваешь < 5.
Быстро, чисто, без лишних подзапросов.
Когда выбираешь строки с максимумом/минимумом - не делай два запроса.
Получай значение и саму строку одной командой с оконной функцией:
SELECT *
FROM sales
QUALIFY ROW_NUMBER() OVER (ORDER BY amount DESC) = 1;
Что это даёт?
Не нужно сначала находить MAX(amount), а потом искать строку с этим значением.
Один запрос — меньше нагрузки, быстрее читается.
Работает для любых ранжирований: топ-N, bottom-N, лидеры, фильтрации по метрикам.
Меняешь DESC → ASC и получаешь минимум.
А если нужен топ-5 — просто ROW_NUMBER заменяешь на RANK или ограничиваешь < 5.
Быстро, чисто, без лишних подзапросов.
🔥18👍5❤2👀2
Forwarded from Machinelearning
Media is too big
VIEW IN TELEGRAM
Компания опубликовала отчет «The state of enterprise AI», который указывает на масштабную трансформацию бизнес-процессов под влиянием ИИ. База корпоративных клиентов превысила 1 миллион организаций, а число Enterprise-мест за год выросло в 9 раз.
Главным трендом стало качественное изменение сценариев использования: потребление ризонинг-токенов подскочило на 320%. Это говорит о том, что бизнес перешел от простых чат-ботов к решению многоступенчатых инженерных и аналитических задач.
Статистика выявила четкую корреляцию между глубиной погружения в технологии и продуктивностью. Сотрудники, использующие GPT-5 Thinking и Deep Research, экономят более 10 часов в неделю, при этом потребляя в 8 раз больше ресурсов модели, чем обычные пользователи. Особенно заметен разрыв в разработке: там генерируют код через ИИ в 17 раз активнее.
openai.com
Model Context Protocol передан организации Agentic AI Foundation, действующей в структуре Linux Foundation. Это стратегический шаг: технология универсального стандарта для подключения ИИ-моделей к внешним базам данных и инструментам, теперь гарантированно останется нейтральной и открытой. Соучредителями нового фонда вместе с Anthropic выступили OpenAI и Block, а поддержку инициативе оказывают Google, Microsoft и AWS.
За год существования MCP добился массовости: протокол используют ChatGPT, Gemini, Claude и VS Code, а число загрузок SDK превысило 97 млн. Переход под эгиду Linux Foundation ставит MCP в один ряд с Kubernetes и PyTorch. Теперь развитие стандарта будет определяться сообществом, что важно для создания совместимой экосистемы ИИ-агентов.
anthropic.com
Власти КНР планируют ввести строгие ограничения на доступ и эксплуатацию Nvidia H200. Это решение готовится на фоне одобрения экспорта данных чипов со стороны администрации США. Несмотря на неожиданный «зеленый свет» из Вашингтона, Пекин демонстрирует осторожность в вопросах использования зарубежного железа.
Конкретные детали и механизмы новых барьеров пока не обнародованы. МИД Китая в ответ на запросы ограничился стандартным заявлением о важности взаимовыгодного сотрудничества, не прояснив судьбу поставок.
ft.com
Google официально подтвердила планы по запуску линейки смарт-очков с ИИ в 2026 году. Техногигант намерен потеснить Марка Цукерберга на этом рынке, объединив усилия с Samsung, Warby Parker и корейским фешн-брендом Gentle Monster.
В разработке находятся 2 типа устройств. Первый вариант - оправа с аудиосистемой для голосового взаимодействия с ИИ, второй - модель с встроенными дисплеями для навигации и перевода в реальном времени. Чтобы сохранить вес и габариты на уровне обычных очков, инженеры решили перенести основную вычислительную нагрузку на сопряженный смартфон.
cnbc.com
В EPFL предложили неожиданное решение для робототехники: использование пищевых отходов в качестве готовых экзоскелетов. В рамках концепции, которую авторы назвали «робототехникой мертвой материи», панцири лобстеров перерабатываются в функциональные механические узлы.
Процесс создания био-гибридов состоит из заполнения оболочки мягким эластомером, установку приводов и покрытия конструкции силиконом, а природная структура панциря обеспечивает идеальный баланс прочности и гибкости. Опытные образцы смогли поднимать вес до 500 граммов и выполнять захват помидора без повреждений.
Инновация решает сразу две задачи: снижает стоимость производства и уменьшает углеродный след, превращая отходы в ресурсы.
news.epfl.ch
@ai_machinelearning_big_data
#news #ai #ml
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🤓2👍1
⚠️ SQL-совет по безопасности, который игнорируют даже опытные разработчики
Никогда не собирайте SQL-запросы через конкатенацию строк
(особенно когда добавляете параметры типа WHERE name = '" + user + "'").
Так вы открываете дверь для SQL-инъекций, даже если “данные вроде чистые”.
✔ Всегда используйте параметризованные запросы или prepared statements —
они экранируют данные, а движок БД понимает структуру отдельно от значений.
Пример безопасного подхода:
передаете значение отдельно.
🧠 Бонус: параметризация улучшает кеширование запросов и часто ускоряет работу БД.
Никогда не собирайте SQL-запросы через конкатенацию строк
(особенно когда добавляете параметры типа WHERE name = '" + user + "'").
Так вы открываете дверь для SQL-инъекций, даже если “данные вроде чистые”.
✔ Всегда используйте параметризованные запросы или prepared statements —
они экранируют данные, а движок БД понимает структуру отдельно от значений.
Пример безопасного подхода:
SELECT * FROM users WHERE email = ?
передаете значение отдельно.
🧠 Бонус: параметризация улучшает кеширование запросов и часто ускоряет работу БД.
👍11❤2💊2🔥1
Что возвращает функция pg_backend_pid()?
Anonymous Quiz
9%
A) Идентификатор текущего пользователя
79%
B) Идентификатор процесса сервера, обслуживающего сессию
7%
C) Версию PostgreSQL
4%
D) Имя базы данных
В этом руководстве мы рассмотрим ключевые аспекты работы с SQL на практике. Начнём с сравнения популярных СУБД, затем перейдём к продвинутым приёмам аналитического SQL, оптимизации запросов, администрированию баз данных, и закончится всё интеграцией SQL с Python (SQLAlchemy, pandas и т.д.).
Для каждого раздела приведены примеры на реальных сценариях (интернет-магазин, CRM, аналитика продаж), код и полезные советы.
👉 Читать гайд
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3🔥1
usql — это интерактивный SQL-клиент, который объединяет работу с разными СУБД в одном инструменте. По ощущениям он похож на psql, но поддерживает сразу множество баз данных и не привязывает тебя к одному движку.
Главная идея usql — один клиент для всех SQL-баз.
Что умеет usql:
- Подключение к PostgreSQL, MySQL, SQLite, MSSQL, Oracle, ClickHouse, CockroachDB, MariaDB и другим СУБД
- Единый интерфейс и одинаковые команды для разных движков
- Интерактивный режим с историей команд и автодополнением
- Удобный табличный вывод результатов
- Запуск SQL-скриптов из файлов
- Гибкая настройка цветов, форматов и pager’а
Почему это удобно:
- Не нужно держать десяток разных клиентов
- Не нужно переключать мышление между psql, mysql и sqlcmd
- Один привычный REPL для аналитики и администрирования
- Отлично подходит для работы сразу с несколькими базами
Кому особенно полезен usql:
- backend-разработчикам
- аналитикам данных
- DevOps-инженерам
- всем, кто регулярно работает с разными СУБД
Если ты живёшь в терминале и часто общаешься с SQL-базами, usql быстро становится инструментом по умолчанию.
github.com/xo/usql/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤3
💡Полезный SQL-совет
Если тебе нужно быстро проверить существование строк - никогда не используй `COUNT(*)`.
❌ Плохо:
✅ Правильно:
Меньше I/O, меньше CPU, быстрее запрос.
Если тебе нужно быстро проверить существование строк - никогда не используй `COUNT(*)`.
❌ Плохо:
SELECT COUNT(*) FROM orders WHERE user_id = 42;
✅ Правильно:
SELECT 1 FROM orders WHERE user_id = 42 LIMIT 1;
Почему:
- `COUNT(*)` считает все строки
- `EXISTS` / `LIMIT 1` останавливаются на первом совпадении
- На больших таблицах разница — кратная
Лучший вариант:
SELECT EXISTS (
SELECT 1 FROM orders WHERE user_id = 42
);
Меньше I/O, меньше CPU, быстрее запрос.
👍13❤7💊1
This media is not supported in your browser
VIEW IN TELEGRAM
🛠️ Легкий TUI для работы с SQL базами данных
sqlit - это удобный инструмент для быстрого выполнения запросов к различным SQL базам данных, включая PostgreSQL, MySQL, SQLite и другие. Он предлагает интуитивно понятный интерфейс, позволяя легко управлять соединениями и историей запросов без необходимости в сложных настройках.
🚀Основные моменты:
- Поддержка множества баз данных без дополнительных адаптеров
- Удобный интерфейс для управления соединениями
- Встроенная история запросов с возможностью поиска
- Поддержка SSH туннелей для безопасного подключения
- Редактирование в стиле Vim для терминальных пользователей
📌 GitHub: https://github.com/Maxteabag/sqlit
#python
sqlit - это удобный инструмент для быстрого выполнения запросов к различным SQL базам данных, включая PostgreSQL, MySQL, SQLite и другие. Он предлагает интуитивно понятный интерфейс, позволяя легко управлять соединениями и историей запросов без необходимости в сложных настройках.
🚀Основные моменты:
- Поддержка множества баз данных без дополнительных адаптеров
- Удобный интерфейс для управления соединениями
- Встроенная история запросов с возможностью поиска
- Поддержка SSH туннелей для безопасного подключения
- Редактирование в стиле Vim для терминальных пользователей
📌 GitHub: https://github.com/Maxteabag/sqlit
#python
❤2👍2🔥1
DISTINCT ON часто недооценивают, но в PostgreSQL это один из самых быстрых способов выбрать «последнюю запись на группу» без подзапросов и оконных функций.
Проблема
Нужно получить, например, последнюю запись по каждому user_id, отсортированную по created_at.
Типичное (медленное) решение
- оконная функция ROW_NUMBER()
- подзапрос с GROUP BY + JOIN
Редкое и очень быстрое решение
DISTINCT ON + индекс, совпадающий с ORDER BY.
Пример
Получаем последнюю сессию каждого пользователя.
SELECT DISTINCT ON (user_id)
user_id,
session_id,
created_at
FROM user_sessions
ORDER BY user_id, created_at DESC;
Почему это быстро
PostgreSQL берет первую строку на каждую группу user_id согласно ORDER BY и сразу останавливается - без сортировки всего результата и без оконных функций.
Ключевой момент оптимизации
Нужен правильный индекс, иначе магия не сработает.
CREATE INDEX idx_user_sessions_distinct
ON user_sessions (user_id, created_at DESC);
Что дает такой индекс
- Index Scan вместо Seq Scan
- Нет дополнительной сортировки
- Очень быстрый выбор «последней записи на группу» даже на миллионах строк
Где особенно полезно
- логины пользователей
- события
- статусы
- версии сущностей
- time-series данные
DISTINCT ON - это PostgreSQL-специфичная оптимизация, но если ты работаешь с Postgres, это один из самых мощных и редких трюков.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤3👍3
Одна из самых коварных SQL-ошибок возникает при использовании LEFT JOIN вместе с условиями в WHERE.
Типичная ситуация:
Ты делаешь LEFT JOIN, чтобы сохранить строки из основной таблицы,
а потом незаметно превращаешь его в INNER JOIN.
Почему так происходит
Если в WHERE есть условие на колонку из присоединенной таблицы,
строки с NULL автоматически отфильтровываются.
В итоге:
- LEFT JOIN есть
- но результат как у INNER JOIN
- данные «пропадают», и баг сложно заметить
Правильное правило
Все условия для таблицы из LEFT JOIN:
- должны быть в ON
- а не в WHERE
Иначе ты теряешь строки, где JOIN не сработал.
Когда это особенно опасно
- отчеты и аналитика
- подсчет метрик
- поиск «отсутствующих» данных
- антиджойны
Эта ошибка не ломает запрос.
Она ломает доверие к данным.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍8❤1
Представь фэнтези-мир, где заклинания - это SQL-запросы, а древние артефакты спрятаны в таблицах и JSON-документах.
🧙Ты - боевой дата-аналитик, который с помощью SQL, Python, ETL и визуализаций охотится за харизматичным злодеем Архивариусом Пакостусом, что ломает индексы, крадёт данные и готовит “шторм данных” на столицу.🔮
В каждом эпизоде тебя ждут: выборы с последствиями, хитрые задачи от простых SELECT до рекурсивных CTE и BigQuery, юмор, эпик и неожиданные повороты.
Хочешь проверить, сможешь ли ты спасти королевство не мечом, а запросами? Тогда добро пожаловать в SQL-квест.
🪄 Начать квест: https://uproger.com/sql-kvest-fentezijnoe-priklyuchenie-dlya-analitikov-dannyh/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥7👍2⚡1