Data Science. SQL hub

🤯 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=

без подписи

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.

без подписи

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 лет.

«Сэр… всё кончено. Китайцы выложили веса 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.

без подписи

без подписи

без подписи

✔️ 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-совет: `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 записей для каждой группы. Для больших таблиц это часто быстрее и проще, чем оконная функция по всему набору данных.

Хитрый SQL-совет: осторожнее с `NOT IN` Кажется, что эти запросы делают одно и то же: SELECT * FROM users WHERE id NOT IN ( SELECT user_id FROM banned_users ); Но если banned_users.user_id содержит хотя бы один NULL, запрос может вернуть ноль строк. Надёжнее использовать NOT EXISTS: SELECT u.* FROM users AS u WHERE NOT EXISTS ( SELECT 1 FROM banned_users AS b WHERE b.user_id = u.id ); Причина в трёхзначной логике SQL: сравнение с NULL даёт UNKNOWN, а не TRUE или FALSE. Правило простое: если подзапрос потенциально возвращает NULL, вместо NOT IN почти всегда выбирайте NOT EXISTS. #sql #postgresql #database

без подписи

без подписи

без подписи

🌟 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

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

Рой ИИ-агентов написал аналог SQLite на Rust за несколько часов 🤯 Cursor провела необычный эксперимент: агентам выдали только официальную документацию SQLite объёмом 835 страниц и поручили с нуля реализовать собственный движок базы данных на Rust. Без интернета, готового исходного кода и дополнительной помощи. Уже через четыре часа получившиеся реализации правильно выполняли 73–85% запросов из скрытого теста. После дальнейшей работы некоторым командам удалось довести результат до 100%. Но особенно удивила стоимость: - связка Opus 4.8 и Composer 2.5 потратила около $1 400; - Fable — примерно $20 000. Одинаковая задача, но почти пятнадцатикратная разница в цене. Во время разработки агенты столкнулись с до боли знакомыми командными проблемами: дублировали работу, конфликтовали при изменении одних и тех же файлов и избегали трогать ядро системы, даже когда без этого было невозможно двигаться дальше. Получается, ИИ уже способен за часы собрать сложный системный проект, но митинги, конфликты и страх ответственности он тоже автоматизировал 😂 #ai #rust #sqlite #agents #programming https://cursor.com/blog/agent-swarm-model-economics @rust_code