DuckLabs, разрабатывающая DuckDB, объявила о присоединении к Amazon Web Services — сделка должна вступить в силу в начале сентября этого года. Команда из более чем 30 человек останется вместе, в Амстердаме, а DuckDB, DuckLake и Quack сохранят лицензию MIT под управлением некоммерческого DuckDB Foundation. Сотрудничество с AWS шло уже больше года: продукт активно используется клиентами S3, а теперь стек ляжет в основу нового поколения дата-сервисов Amazon. В отличие от многих сделок, тут AWS покупает команду — а контроль над существующим продуктом разработчики будут постепенно раздавать сообществу. Хороший продукт, кстати, если кто вдруг не знает. https://ducklabs.com/news/2026/08/26/ducklabs-to-join-aws

MetaORM — когда устал от ORM настолько, что написал свою 16 лет в разработке, 10 из них ежедневно с базами данных, и человек спокойно пишет, что путается в уровнях изоляции, не выучил расшифровку ACID и простой запрос с JOIN осиливает только через Гугл. За 7 лет коммерческой разработки сложный SQL-запрос не понадобился ни разу, а больше половины возможностей популярных ORM так и остались нетронутыми. Один и тот же кусок кода перекочёвывал из проекта в проект, пока не превратился в отдельный пакет. Внутри декларативные фильтры, генераторы стандартных CRUD-операций и тонкий слой транзакций через contextvars. Ни unit-of-work, ни identity map, ни ленивых прокси, ни магического отслеживания состояния объектов. Остаётся только то, с чем backend сталкивается каждый день, взять запись по идентификатору, отфильтровать список, обновить пару полей, создать сущность внутри транзакции. Посмотрим, что остаётся от ORM, когда убираешь из неё всё, чем не пользуешься.

Привет! Вас стало больше, так что пора наконец представиться 🙂 Я Даша, давно пишу на Go, но на своем тернистом пути постоянно нахожу интересности во внутренностях языка. Пишу про производительность, работу с бд и свои наблюдения, которыми грех не поделится. Параллельно развиваю свой поисковый движок - fts-engine: https://github.com/dariasmyr/fts-engine Из-за него тут регулярно появляются посты про full-text search, индексы, фильтры, хранение данных и разные эксперименты вокруг темы поисковиков. Пока тут легкий хаос с темами: от рабочих кейсов до иногда странных углублений в исходники и ищьюс ;’) Чтобы во всём этом было чуть проще ориентироваться, я разметила посты тегами:

#go - Go, рантайм, реализации техник и описание внутрянки #perf - производительность, профилирование и бенчи #db - базы данных, оптимизации #fts - поиск, индексы и устройство движка #projects - мои проекты и эксперименты

Пишите, если заинтересовала какая то тема или идея, буду рада обсудить. Welcome!

HNSW: как устроен графовый индекс для векторного поиска One million years later, я наконец добралась до прикручивания в проект семантического поиска. Тащить ради этого отдельную векторную бд максимально не хотелось, поэтому решила пойти классическим путем - попробовать встроить индекс HNSW прямо в движок наравне с остальными индексами. Если кратко, HNSW - это графовый индекс для approximate nearest neighbor поиска по векторам. Вместо того чтобы сравнивать запрос со всеми векторами в индексе, он заранее связывает близкие векторы в многоуровневый граф, а во время поиска двигается по этим связям в сторону все более похожих кандидатов. Как обычно, решила разобраться, как HNSW вообще работает: 1. зачем графу несколько уровней; 2. как выбирается entry point; 3. почему сверху greedy поиск, который расширяется на ниженем уровне; 4. что делают параметры M, efSearch и efConstruction; 5. почему при построении нельзя просто соединить ноду с M ближайшими; 6. и как работают reverse links и pruning. В итоге текста получилось на статью :") Пока без реализации и бенчмарков, а просто разбор внутрянки индекса. Читать тут: https://gist.github.com/dariasmyr/d492c3388feaf0f779571a635a3b493e

Почему монолиту приписывают одну базу данных (БД)? Нет такого требования, что если монолит, то должна быть одна БД. Но любители микросервисов часто приписывают монолитам недостаток в виде одной базы. Монолит может работать с несколькими БД и хранить данные в отдельных базах на одном сервере или даже на разных серверах. У меня в SonyRewards было несколько баз данных: основная пользовательская, банковская, почтовая с маркетингом, сессии, каталог и база для контроля отгрузок. Каждая база может быть настроена по разному на производительность, разные стратегии резервного копирования и безопасности в зависимости от данных, которые там хранятся.

Иммутабельная денормализация Изучение баз данных всегда сопровождается понятием нормализации, а конкретно первыми тремя формами, которые задают нам ограничения, помогающие правильно разложить все по таблицам. И это действительно база, без которой нормально работать не получится. Но есть, как обычно, нюансы. В реальных проектах выясняется, что нормализованные данные сложно соединять и выбирать. При глубоком уровне зависимостей, чтобы добраться до внешней сущности, нужно либо соединять 5 таблиц, либо делать 5 запросов. Пример из Хекслета. У нас есть программа обучения, которая состоит из модулей, в которые входят темы которые состоят из уроков, которые состоят из юнитов (теория, практика, тесты). На это все накручено много логики по прогрессу и отображению. В такой структуре, вопросы типа "какой урок следующий по порядку?" заставляют поломать голову. В таких ситуациях мы начинаем денормализацию данных. В основном она сводится к добавлению внешних ключей на косвенно связанные сущности, например, урок связан с программой обучения через модуль. Здесь мы добавляем ключ на программу прямо из урока, что позволяет выполнять запросы на уроки одной программы без необходимости соединять таблицы. В принципе это довольно базовая концепция с которой знакомы большинство разработчиков, но дальше начинается самое интересное. Как только мы делаем денормализацию, то сразу упираемся в необходимость синхронизировать данные. Если поменялось в одном месте, надо не забыть поменять и в другом месте. Это цена денормализации и ее надо платить. > Кстати есть такой концепт как синхронизирующие триггеры, которые вешают только для того, чтобы синхронизировать подобные данные. Когда-то я его активно использовал, но сейчас не стал бы Но есть и альтернативный подход, который иногда работает лучше. Вместо того, чтобы синхронизировать денормализованные данные, мы можем пересмотреть саму систему и сделать данные иммутабельными (неизменяемыми), чтобы их не нужно было синхронизировать. Например в том же примере с уроками, мы сделали так, что урок принадлежит одной программе и не может перемещаться между программами. А это значит, что мы можем записать в урок все внешние ключи, которые никогда не поменяются. В таком случае цена денормализации это занятое место ключами, чем обычно можно пренебречь. А что касается бизнес-логики? Да, такой подход работает не всегда, но, как показала практика, его можно использовать намного чаще чем кажется. Например в нашем случае это даже наоборот хорошо, иначе получается ситуация, что при переносе урока нужно переносить прогресс, что значительно усложняет логику и создает странное впечатление, когда в середине программы вдруг появляются пройденные уроки. При этом сама процедура довольно редкая, поэтому если кому-то придется пройти два раза один и тот же урок (перенос в нашем случае это копирование), то ничего страшного не случается. Но есть места где без синхронизации данных не обойтись никак. В основном это касается статусов, они могут меняться и за ними нужно следить. Telegram | YouTube | AI Клуб

Designing Data Intensive Applications, 2nd edition by Martin Kleppmann Обзор первого издания книжки с кабанчиком был одним из первых книжных обзоров на моём канале (если кому интересно, как это выглядело почти 3 года назад — вот ссылка на пост). Я эту книгу всегда любил и высоко ценил, перечитывал несколько раз, поэтому после новости о переиздании был очень рад. Конечно, я добрался до неё не сразу, но и затягивать не стал. Мотивацию читать второго кабанчика объяснить очень просто — на мой вкус, это одна из лучших книг по system design (и точно лучшая книга по проектированию приложений с большим потоком данных). ⭐️ О чём книга Книга посвящена построению надёжных, стабильных, отказоустойчивых приложений, которые интенсивно работают с данными. Работа включает в себя чтение, запись, хранение и так далее. Также книга покрывает многие аспекты построения распределённых систем, важные для работы с данными. В книге раскрываются следующие темы: ➡️ Как эффективно хранить и получать данные ➡️ Как обеспечивать сохранность данных (репликация, шардирование) ➡️ Детальный разбор устройства транзакций ➡️ Особенности работы с данными в распределённых системах ➡️ Batch & Stream processing: особенности выстраивания ⭐️ 3 идеи из книги 🟡Сейчас на рынке появляются HTAP-базы данных (гибрид транзакционной и аналитической модели). Но часто оказывается, что «под капотом» у них всё так же две разные системы: одна для транзакционной обработки, а вторая — для аналитической. Это важно понимать при анализе конкретного решения. 🟡Для многих БД непрактично останавливать весь процесс работы с целью резолва конфликта данных, поэтому они сохраняют обе версии и продолжают работать. При следующем запросе этих данных такая база возвращает обе версии клиенту, предоставляя ему самому выбрать метод решения конфликта. 🟡Ошибки сети довольно редки, но приложение должно уметь справляться с ними. Особенно это важно в сложных геораспределённых системах, где сеть будет лагать и отваливаться гораздо чаще, чем в каком-нибудь небольшом кластере кубера, развёрнутом в одном ЦОДе. Этими ошибками часто пренебрегают, из-за чего вылезают неприятные баги. ⭐️ Мои впечатления Второй кабанчик стал намного лучше для меня как для читателя. Во-первых, новая структура книги кажется мне более логичной и последовательной: читать было комфортнее, темы расположены так, чтобы не приходилось забегать вперёд (в первом кабанчике это было частой проблемой). Во-вторых, сам контент был изрядно переписан и стал более «удобоваримым». Мне показалось, что книгу стало проще понимать (особенно в части разных весёлых аномалий). Хотя, может, это я просто стал умнее :) DDIAv2 в моём личном рейтинге стала достойной преемницей первой части и по-прежнему будет занимать место в топе лучших технических книг, которые я когда-либо читал. Рекомендую, даже если вы читали первую часть — вас ждёт много интересных открытий и инсайтов. Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте. А для тех, кто хочет читать с большей пользой, у меня есть статья с описанием моего процесса чтения и упражнениями. ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog 💬 Бэкап канала в Max

Кто-то только что переписал 40 лет PostgreSQL с нуля на Rust. И он уже проходит 100% официальных тестов Postgres. Проект называется pgrust. Это не форк, а полная реализация с нуля, которая уже проходит все 46 066 запросов из официального тестового набора PostgreSQL 18.3. Postgres разрабатывается уже 40 лет, и некоторые архитектурные решения из 80-х до сих пор приводят к сбоям: - один поток на соединение, фактически отдельный OS-процесс на пользователя - 350+ параметров настройки, которыми нужно управлять вручную - один только VACUUM стал причиной тысяч инцидентов pgrust выбрасывает всё это и начинает заново. Что уже работает: - проходит 96% regression suite PostgreSQL - psql подключается из коробки, есть совместимость с wire protocol - query planner, buffer cache, storage engine, B-tree индексы - JSON/JSONB, window functions, foreign keys, EXPLAIN ANALYZE, regex - тот же движок компилируется в WebAssembly и запускается прямо в браузере на pgrust.com 100% open source. https://github.com/malisper/pgrust