Data Science. SQL hub

PostgreSQL: архитектура и тюнинг SQL-запросов Погрузись в архитектуру и прокачай оптимизацию запросов одной из самых популярных open source СУБД – PostgreSQL. 🌐 В программе курса: 🤩 Разберём, как работают СУБД вообще и PostgreSQL в частности: что такое MVCC, ACID, WAL, LRU, PPC/TPC и другие фундаментальные понятия архитектуры баз данных 🤩 Получишь теорию и практику EXPLAIN и EXPLAIN ANALYZE на разных типа запросов: без индексов, с индексами, index only, нормализованные и документ-ориентированные данные и json-поля, изменение параметров сессии/конфигурации для ускорения запросов 🤩 Изучишь архитектуру хранения данных в PostgreSQL, типы и особенности индексов, а также полезные советы и трюки оптимизации БД 🤩 Получишь свой собственный выделенный облачный PostgreSQL-сервер (8 vCPU, 12G RAM, 100G NVMe) – предоставляется БЕСПЛАТНО на время обучения + готовый e-commerce датасет TPC-H (миллион пользователей, несколько миллионов заказов на десятки гигабайт) 🗓 Старт курса: 3 сентября. 5 недель обучения. Изучить программу и записаться можно здесь. 🤩Кто мы: R&D-центр Devhands, автор курса Николай Ихалайнен, эксперт по СУБД (ex-Percona), со-основатель MyDB, энтузиаст открытого ПО. Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquuHE37

🔥 Одна строка в конфиге ускорила production-ответ с 126–230 мс до менее чем 9 мс Paweł Urbanek собрал очень практичный гайд по профилированию Rust, где оптимизации идут не по принципу «что интереснее», а по реальной отдаче. Из кейсов: N+1 SQL → 21 запрос превратили в один JOIN, функция ускорилась со 104 до 70 мкс. Три последовательных HTTP-вызова → tokio::try_join!, итоговое время почти вдвое меньше. Неправильно настроенный Brotli в maplibre/martin → скорость была всего 27,9 KB/s. Одна правка конфига дала примерно 57x ускорение, а latency упала до <9 мс. Ещё жёстче кейс с write lock, который держали на всём HTTP round trip. После переноса блокировки P95 для читателей рухнул с 1,11 секунды до 9,42 мкс. И отдельная классика Tokio: unbounded channel молча накопил 73 сообщения, потому что consumer не успевал. Никакой ошибки, просто медленное движение к OOM. Полезный порядок из гайда: сначала SQL и HTTP, потом locks и channels, и только после этого CPU profiling. Потому что один лишний поход в базу обычно стоит дороже, чем сотни мелких оптимизаций внутри hot loop. 🔗 hotpath.rs/blog/profiling-rust-guide #Rust #Performance #Profiling #Tokio #Backend

🌟 Cohere Labs выложила компактную зрительно-языковую модель North Micro Vision Модель на 2,4 млрд параметров стала самой маленькой в линейке VLM компании. От большинства таких моделей она отличается тем, что работает с изображением в исходном разрешении.

Обычно картинку перед подачей в модель сжимают, и мелкий текст, разметка таблицы и подписи на графике при этом теряются. Здесь пропорции сохраняются, а верхняя планка соответствует странице A4, отсканированной при 200 dpi.

Отсюда и заявленная область применения - документы, таблицы, графики, скриншоты, формы. Компактный размер удобен для дообучения под свою предметную область, а квантованные сборки, по словам Cohere, пойдут не только на сервере, но и на ноутбуке или устройстве мобильного класса. 🟡Архитектура Зрительный энкодер на 400 млн параметров вырос из SigLIP 2 и держит исходное разрешение за счёт двумерного RoPE вместе с обученными одномерными позиционными эмбеддингами. Языковая часть - собственная North Micro LLM на 2 млрд параметров, повторяющая архитектуру Command A+: три слоя внимания со скользящим окном и RoPE чередуются с одним глобальным слоем, который работает вообще без позиционных эмбеддингов.

Получается разделение труда - окна с RoPE держат локальный контекст, глобальный слой смотрит на всё сразу и в разметке позиций не нуждается.

Между ними проектор, и здесь изюминка. Вместо того чтобы отдать языковой модели один готовый набор признаков, Cohere подмешивает эмбеддинги патчей с нескольких уровней зрительного энкодера в соответствующие ранние слои языковой модели. Так модель видит картинку сразу на разных степенях обобщения. Принцип взят из DeepStack. 🟡Тесты Замеры проводили через VLMEvalKit, сравнивая с восемью моделями размером от 1,6 до 5,1 млрд параметров. Сильнее всего North Micro Vision выглядит там, куда её и целили.

На DocVQA 0,921, на ChartQA 0,808, на AI2D 0,775, на RefCOCO 0,732 (втрое выше, чем у Ministral и Qwen3-VL).

Общий язык и рассуждение даются слабее.

На MMMU 0,329, худший результат в таблице; на MMLU и MMLU-Pro модель тоже уступает большинству соседей.

📌Лицензирование: Apache 2.0 License. 🟡Статья 🟡Модель 🟡Демо @ai_machinelearning_big_data #AI #ML #VLM #NorthMicroVision #Cohere

🐘 SQL-совет, который многие игнорируют: не используй `COUNT(*)`, если тебе нужно только проверить существование строки. Часто пишут так:

SELECT COUNT(*)
FROM orders
WHERE user_id = 42;

А потом проверяют, больше ли результат нуля. Но базе приходится посчитать все совпадения, хотя тебе нужна всего одна информация: есть хотя бы одна строка или нет. Лучше использовать:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 42
);

EXISTS может остановить поиск сразу после первого совпадения. На маленькой таблице разницы почти не заметишь. На миллионах строк и частых проверках это уже может серьёзно экономить ресурсы. Если нужен ответ «да/нет» — не заставляй SQL считать всё.

🔥 Tailscale полгода ловила «невозможную» порчу SQLite. В итоге нашли баг, который жил в базе минимум 16 лет В production у Tailscale начали случайно повреждаться SQLite-базы. Никакой стабильной причины: разные шарды, разная нагрузка, иногда между инцидентами проходили недели. За шесть месяцев компания поймала 19 случаев corruption. После месяцев форензики вместе с core-разработчиками SQLite нашли причину: редкий race condition между записью и WAL checkpoint. При очень точном совпадении по времени SQLite мог решить, что страницы уже перенесены из WAL в основной файл, хотя этого не происходило. Часть данных исчезала, а база становилась повреждённой. Баг получил название WAL-Reset. По оценке разработчиков SQLite, он существовал минимум 16 лет и был настолько редким, что для тестов пришлось специально писать код, который провоцирует нужную гонку. Tailscale ловила его чаще из-за агрессивного ручного checkpointing. А дальше стало ещё веселее: версия SQLite 3.52.0 с исправлением обнаружила вторую проблему со stale expression indexes и начала выдавать ложные сообщения о corruption. Релиз отозвали, а фикс WAL-Reset перевыпустили в SQLite 3.51.3. Редкий пример расследования, где компания полезла искать баг в одной из самых проверенных баз данных мира и действительно нашла его. 🔗 tailscale.com/blog/sqlite-wal-reset-bug #SQLite #Database #Linux #Backend #Engineering

🔥 PPT Master делает презентации из PDF, DOCX и сайтов прямо внутри Claude Code и Cursor. И на выходе это настоящий редактируемый PowerPoint ppt-master работает как skill для AI-IDE. Можно просто написать: «сделай презентацию из этого PDF», после чего агент сам разбирает материал, продумывает структуру, собирает дизайн и экспортирует .pptx. Поддерживаются PDF, DOCX, URL и Markdown. Самая сильная часть проекта в том, что слайды не превращаются в набор картинок. Текст, фигуры, таблицы и графики экспортируются как нативные объекты PowerPoint, которые можно открыть и вручную отредактировать. Есть шаблоны, live preview, анимации, speaker notes и даже генерация озвучки с последующим встраиванием аудио в PPTX. Работает с Claude Code, Cursor, VS Code + Copilot и другими agent harness. Сам пайплайн выполняется локально, кроме обращений к выбранной AI-модели. По сути: PDF / DOCX / URL → AI-agent → структура → дизайн → настоящий editable .pptx Автор отдельно пишет, что цель не заменить финальную ручную полировку, а убрать примерно 90% работы с пустого листа. 🔗 github.com/hugohe3/ppt-master #AI #ClaudeCode #PowerPoint #Agents #OpenSource

Как SQLite выжимает скорость: байткод, VM и goto Некрасивый код, который делает SQLite быстрым

⚡ В SQLite есть кусок кода, который выглядит «грязно», но оставлен таким специально ради скорости. Каждый SQL-запрос SQLite сначала компилируется в байткод, а затем выполняется собственной виртуальной машиной VDBE. Внутри — большой цикл диспетчеризации с почти 200 opcode. И вот интересный момент: SQLite использует обычные goto, чтобы быстро прыгать между общими ветками выполнения. В исходниках прямо написано: «Код использует неструктурированные goto и выглядит не очень чисто. Но это сделано не из-за плохого стиля, так быстрее». По замерам разработчиков, такой подход ускоряет sqlite3_step() примерно на 1,5%. То есть здесь читаемость сознательно пожертвовали ради производительности. Хорошее напоминание: в системном коде «красивее» не всегда значит «быстрее». #SQLite #C #Databases #Performance #SystemsProgramming

⚡️ Редкий SQL-приём: `GROUPING SETS` может заменить несколько тяжёлых `GROUP BY` + `UNION ALL`. Допустим, нужно одновременно получить статистику: - по стране и городу; - только по стране; - общий итог. Часто пишут так:

SELECT country, city, SUM(revenue)
FROM sales
GROUP BY country, city

UNION ALL

SELECT country, NULL, SUM(revenue)
FROM sales
GROUP BY country

UNION ALL

SELECT NULL, NULL, SUM(revenue)
FROM sales;

Но SQL умеет это нативно:

SELECT
    country,
    city,
    SUM(revenue) AS revenue
FROM sales
GROUP BY GROUPING SETS (
    (country, city),
    (country),
    ()
);

() означает grand total. А если нужно понять, настоящий ли NULL лежит в данных или это строка итогов:

GROUPING(country)
GROUPING(city)

вернут 1 для колонок, которые были свернуты агрегированием. 🔥 Особенно полезно для: OLAP-запросов; аналитических отчётов; дашбордов; многоуровневых итогов; запросов, где иначе появляется несколько почти одинаковых GROUP BY. Ещё есть:

ROLLUP(...)
CUBE(...)

ROLLUP строит иерархические итоги, а CUBE - все комбинации измерений. Если в аналитическом SQL у вас появляется цепочка из GROUP BY + UNION ALL, возможно, вы просто забыли про GROUPING SETS. #SQL #PostgreSQL #DataEngineering #Analytics

🚀 ИИ-агент ускорил SQLite до 59% меньше чем за 8 часов Ускорить SQLite хотя бы на 5% уже было бы серьёзным результатом. Это один из самых зрелых и оптимизированных проектов в мире - его команда почти 20 лет выжимает из кода каждую долю производительности. Но AI-агент KISS Sorcar менее чем за 8 часов и с затратами меньше $150 добился заметного ускорения сразу в нескольких типах нагрузки. Результаты: - 2,06× быстрее в официальном speedtest1 (~30 тыс. операций) - 1,90× в TATP — транзакционная OLTP-нагрузка - 1,30× в Star Schema Benchmark — аналитические запросы - 1,25× в kvtest — работа с BLOB и дисковым I/O Агент нашёл места, где стандартная конфигурация SQLite несла лишние расходы — особенно при записи транзакций на диск. После этого он: - изменил код и настройки - прогнал бенчмарки - проверил свои же изменения на ошибки - сохранил совместимость с существующими тестами Более миллиона тестов SQLite продолжают проходить. анализ зрелой кодовой базы → поиск узких мест → изменение реализации → бенчмарки → проверка собственных решений. GitHub: https://github.com/ksenxx/sqlite-optimized/ Blog: https://kisssorcar.github.io/blog/sqlite-optimization-blog.html #AI #SQLite #Programming #CodingAgents #Performance #OpenSource

💡 SQL-трюк: сравнивайте `NULL` без костылей В PostgreSQL обычное сравнение может неожиданно сломать условие:

SELECT NULL = NULL;

Результат:

NULL

Потому что NULL означает «неизвестное значение», а не конкретное значение. Из-за этого часто пишут громоздкие условия:

WHERE a = b
   OR (a IS NULL AND b IS NULL)

Но есть оператор, о котором многие забывают:

a IS NOT DISTINCT FROM b

Он работает как NULL-safe equality:

SELECT NULL IS NOT DISTINCT FROM NULL; -- true
SELECT 10   IS NOT DISTINCT FROM 10;   -- true
SELECT 10   IS NOT DISTINCT FROM NULL; -- false

Есть и обратный вариант:

a IS DISTINCT FROM b

Например, удобно искать реально изменившиеся значения:

SELECT *
FROM old_data o
JOIN new_data n USING (id)
WHERE o.email IS DISTINCT FROM n.email;

Если оба email = NULL, строка не считается изменённой. Без этого обычное:

o.email <> n.email

может просто вернуть NULL и пропустить изменение. Особенно полезно при синхронизации данных, аудите изменений, ETL и UPSERT-логике. #SQL #PostgreSQL #Database

🚀 Neo4j без сервера: GraphForge запускает полноценный Cypher прямо внутри Python-скрипта GraphForge занимает редкую нишу между NetworkX и серверными графовыми БД. Вы получаете встроенный графовый движок на Rust, полный openCypher и хранение проекта в обычной директории. Что внутри: - четыре независимых слоя на Rust: parser → IR → planning → execution; - результаты сразу возвращаются как Apache Arrow Table; - данные легко передаются в Pandas и Polars; - постоянное хранение построено на Parquet; - встроены PageRank, Louvain и гибридный текстово-векторный поиск; - Python- и Node.js-биндинги работают поверх одного движка.

from graphforge import GraphForge

graph = GraphForge("research/")

result = graph.execute("""
    MATCH (a)-[:CITES]->(b)
    RETURN a.title, b.title
""")

print(result.to_pandas())

При этом GraphForge честно позиционируется как инструмент исследовательского и notebook-масштаба. Для миллиардных графов, высокой нагрузки и многопользовательского доступа по-прежнему нужна серверная БД. Python и Node.js доступны сейчас, Swift и Kotlin находятся в планах. Лицензия — Apache 2.0. https://github.com/CurateLabs/graphforge #RustLang #Python #OpenSource #GraphDatabase #DataScience #KnowledgeGraph

SQL-совет: `LATERAL` вместо тяжёлого оконного запроса Нужно получить последнюю операцию каждого пользователя? В PostgreSQL можно не ранжировать всю таблицу через ROW_NUMBER().

SELECT
    u.id,
    last_order.id,
    last_order.created_at
FROM users AS u
LEFT JOIN LATERAL (
    SELECT id, created_at
    FROM orders
    WHERE user_id = u.id
    ORDER BY created_at DESC
    LIMIT 1
) AS last_order ON true;

LATERAL запускает подзапрос отдельно для каждой строки слева и разрешает обращаться к u.id. Добавьте индекс:

CREATE INDEX ON orders (user_id, created_at DESC);

Тогда PostgreSQL сможет брать последнюю запись прямо из индекса, не сортируя все заказы пользователя. Такой приём особенно полезен для задач: - последняя операция пользователя; - актуальный статус заказа; - последнее событие устройства; - последние N записей для каждой группы. Для больших таблиц это часто быстрее и проще, чем оконная функция по всему набору данных.

🌟 WASTE: запускаем полную Kimi K3 на MacBook Pro с 64 ГБ памяти SQLite AI собрала движок на 6000 строк C, который гоняет полновесную K3 без BLAS, CUDA и Python в рантайме. Kimi K3 после предварительной конвертации из safetensors в формат, который движок умеет читать, занимает 982 ГиБ (диск бы назвал это 1,05 ТБ). В оперативную память она не влезает даже приблизительно. WASTE держит в RAM только резидентную часть на 27,28 ГБ, а экспертов подтягивает с SSD ровно тогда, когда они понадобились. Скорость генерации выходит 0,49-0,54 токена в секунду. Веса при этом полные, без дистилляции и обрезки слоёв. 🟡Расчёт строится на устройстве MoE На каждый токен K3 включает около 4% собственных весов - 16 экспертов в каждом из 92 слоёв. Простаивающему весу незачем сидеть в памяти, ему достаточно успеть подгрузиться вовремя. Контейнер с моделью устроен так, что один эксперт стоит ровно одного чтения с диска - матрицы gate, up и down лежат вплотную, а сами эксперты хранятся в остаточном векторном квантовании (3 ступени кодбуков по 256 записей, 3 бита на вес), и матрица никогда не разворачивается целиком. 🟡Скорость диска На один токен движок вычитывает 17 ГБ. Внутренний NVMe в MacBook выдаёт 12,78 ГБ/с, и модель успевает читать. Внешний бокс по USB даёт 0,94 ГБ/с, и тот же токен считается 13 секунд. Вариант для очень терпеливых. 🟡Работа с памятью Раздувать кэш экспертов выше 46 ГБ бесполезно и вредно - на 52 ГБ скорость падает втрое, на 58 ГБ в 8 раз.

Причина в том, что движок остаётся внутри своего бюджета, а система уже нет - macOS вытесняет кэш на диск, и попадание в память оборачивается обращением к подкачке. Поэтому по умолчанию WASTE не забирает все доступные ресурсы, а берёт на один рабочий набор экспертов меньше, чем мог бы.

Полтокена в секунду - это 30 секунд на одно предложение, но модели вчетверо меньше до сих пор запускают на серверах с терабайтом DDR5, а здесь почти 3 триллиона параметров отвечают без сети. Если триллионы параметров не нужны, тот же движок крутит Kimi-Linear 48B из контейнера на 19 ГБ и выдаёт 10,7 токена в секунду - с этого проще начать знакомство.

Для K3 придётся освободить терабайт на диске и потратить около 5 часов на M5 Pro в три процесса, почти сутки - если гонять конвертацию чистым торчем.

Авторы, кстати, завели файл с опровергнутыми гипотезами и записали туда всё, что померили и выбросили. 📌Лицензирование: Apache 2.0 License. 🖥Github @ai_machinelearning_big_data #AI #ML #Inference #KimiK3 #WASTE #SQLiteAI

🤯 OPUS 5 ЗА 10 МИНУТ УДАЛИЛ ВСЮ БАЗУ ДАННЫХ, А ПОТОМ ВЕЖЛИВО ПРИЗНАЛ ОШИБКУ Пользователь Reddit решил протестировать Claude Code. После одного запроса агент уничтожил базу проекта и сообщил: «Это моя вина, и я должен немедленно вам об этом сказать». Позже Gemini 3.6 помог восстановить 96 страниц, ещё 21 пришлось пересоздавать. Автор уточнил, что это был тестовый проект с небольшим числом пользователей, поэтому последствия оказались не критичными. Самое показательное: модель получила режим Always Allow, доступ к данным и возможность выполнять разрушительные команды без подтверждения. Историяпро разработчика, который дал автономному агенту права администратора без нормальных бэкапов и ограничений. ИИ-агенту в проде нужны минимальные права, отдельное окружение, снапшоты и ручное подтверждение любых DROP, DELETE и миграций. Иначе вайб-кодинг быстро превращается в вайб-восстановление базы. https://www.reddit.com/r/Anthropic/comments/1v9iurd/and_just_like_that_opus_5_ultracode_wipes_the/?solution=44899d8f83b98cbf44899d8f83b98cbf&js_challenge=1&token=7afd7253fec22262ff1c52b1703fe9ec98100ded527c5fb6747eed7511fb37a6&jsc_orig_r=

«Сэр… всё кончено. Китайцы выложили веса Kimi K3 в открытый доступ» Moonshot AI опубликовала Kimi K3 на Hugging Face — мультимодальную MoE-модель с 2,8 трлн параметров, из которых на токен активируются около 104 млрд. Что внутри: контекст до 1 млн токенов; работа с текстом и изображениями; длительные агентные задачи и вызов инструментов; программирование, исследование репозиториев и работа с терминалом; нативная квантизация MXFP4. На Terminal-Bench 2.1 авторы заявляют 88,3 балла, а на FrontierSWE — 81,2. Результаты получены в собственном агентном окружении Kimi Code, поэтому сравнивать их нужно с учётом harness. Веса доступны по лицензии Kimi K3 License. Это уже не экспериментальная модель «для посмотреть», а открытый 3T-класс, который можно разворачивать через vLLM или SGLang.

SQLite установлен практически везде. Но отправить туда обычный pull request у вас не получится. SQLite работает на каждом iPhone и Android, в Chrome, Firefox, Safari, Windows, телевизорах, автомобилях и миллиардах других устройств. По оценке самого проекта, сейчас активно используется больше триллиона SQLite-баз. И при этом SQLite принципиально остаётся проектом с очень маленькой командой разработчиков. На официальном сайте это сформулировано прямо: Open source, but not open-contribution. Проект не принимает случайные pull request'ы и патчи из интернета. Чтобы код вообще мог попасть в SQLite, автор должен юридически передать свой вклад в public domain. Для этого существует отдельный подписываемый документ. Причина не в высокомерии разработчиков. Так они защищают одну из главных особенностей SQLite: весь основной код должен оставаться свободным от чужих copyright-претензий. Получился довольно редкий парадокс: одна из самых распространённых технологий на планете стала настолько успешной не благодаря тысячам контрибьюторов, а благодаря жёсткому контролю над тем, кто вообще может менять её код. И эта модель работает уже больше 25 лет.

SQLite установлен практически везде. Но отправить туда обычный pull request у вас не получится. SQLite работает на каждом iPhone и Android, в Chrome, Firefox, Safari, Windows, телевизорах, автомобилях и миллиардах других устройств. По оценке самого проекта, сейчас активно используется больше триллиона SQLite-баз. И при этом SQLite принципиально остаётся проектом с очень маленькой командой разработчиков. На официальном сайте это сформулировано прямо: Open source, but not open-contribution. Проект не принимает случайные pull request'ы и патчи из интернета. Чтобы код вообще мог попасть в SQLite, автор должен юридически передать свой вклад в public domain. Для этого существует отдельный подписываемый документ. Причина не в высокомерии разработчиков. Так они защищают одну из главных особенностей SQLite: весь основной код должен оставаться свободным от чужих copyright-претензий. Получился довольно редкий парадокс: одна из самых распространённых технологий на планете стала настолько успешной не благодаря тысячам контрибьюторов, а благодаря жёсткому контролю над тем, кто вообще может менять её код. И эта модель работает уже больше 25 лет.

✔️ Constella: локальная память для файлов, заметок и AI-агентов Constella — open-source desktop-приложение, которое индексирует локальные файлы и превращает их в единую базу знаний для поиска и AI-агентов. Данные хранятся на устройстве: LanceDB используется для векторов, SQLite — для метаданных и knowledge graph. Что умеет: - индексировать Obsidian, Documents, Downloads и любые выбранные папки; - извлекать текст из PDF, DOCX, Markdown и изображений; - строить семантический поиск по локальным данным; - автоматически связывать заметки, темы и концепты; - работать с локальными и облачными LLM; - отдавать базу знаний через MCP в Claude Code; - использовать агентов и переиспользуемые workflows. Схема примерно такая:

Файлы
  ↓
chunks + embeddings
  ↓
LanceDB + SQLite
  ↓
Knowledge Graph
  ↓
поиск / агенты / MCP

https://github.com/Constella-OS/constella-desktop

SQL-совет: сравнивайте `NULL` через `IS NOT DISTINCT FROM` Обычное сравнение ломается на NULL:

SELECT NULL = NULL;
-- NULL

Поэтому условие:

WHERE old_value = new_value

не считает два NULL равными. В PostgreSQL используйте:

WHERE old_value IS NOT DISTINCT FROM new_value

Оператор работает как безопасный аналог =:

1 IS NOT DISTINCT FROM 1       -- true
NULL IS NOT DISTINCT FROM NULL -- true
1 IS NOT DISTINCT FROM NULL    -- false

Полезно при сравнении версий строк, поиске изменений и синхронизации таблиц:

SELECT *
FROM old_data o
JOIN new_data n USING (id)
WHERE o.email IS DISTINCT FROM n.email;

Запрос вернёт строки, где значение действительно изменилось, включая переходы NULL → значение и значение → NULL.