Работаешь дата инженером не первый год, а PostgreSQL всё ещё может удивить 😅 Недавно столкнулся с ситуацией, которая, казалось бы, должна быть довольно распространённой. Нужно переименовать таблицу через ALTER TABLE ... RENAME, но ты не OWNER этой таблицы. Права на переименования раздать тоже нельзя Вроде штука достаточно распространненая должна быть, но раньше я как-то не сталкивался с такой задачей. В итоге решение оказалось довольно интересным — SECURITY DEFINER. Можно создать процедуру, которая будет выполняться с правами своего владельца, и дать пользователю доступ только к её вызову.

CREATE PROCEDURE ...
SECURITY DEFINER

В результате пользователь может выполнить нужное переименование, не получая права OWNER на сами таблицы. Я в такие моменты всегда задаюсь вопросом: "А точно ли я все эти годы чем-то занимаюсь, если мне еще не встречались такие вещи?)" А у вас были подобные моменты, когда внезапно узнаёшь что-то новое в технологии, с которой давно работаешь?

Попался анонс новой базы данных - SereneDB, по словам создателей - "the fastest search & analytics database in the world". Как пишут, начался проект в корпорации, потом его свернули, но создатели - Alexander Malandin и Andrey Abramov - продолжили работу и довели до прода. Умеет полнотекстовый, векторный и гибридный поиск. Поддерживает OLAP и озёра данных. Подходит для ИИ-агентов и RAG. Бенчмарки вдохновляющие. Причем, проект опенсорсный. Вот, кстати, они запустились на ProductHunt. Поддержите, если есть аккаунт. Я обычно для аналитики использовал Clickhouse. Но думаю, что надо попробовать и этот вариант. Работает при наличии PostrgeSQL-коннектора. #database #tools

Небольшой постик для тех кому интересно, что сейчас спрашивают на позицию дата инженера Во первых это, конечно, sql и python и как правило (в процентах 80%) будет лайв кодинг. Иногда задачку на собеседовании можно решить не на питоне, а на другом языке Задачки, как правило, не супер сложные и объемные, но в условиях собеседования и ограниченного времени можно не справится По питону задачка например сделать что-то с массивом или словарем. Например вывести первое повторяющееся значение в массиве По SQL задачка например найти сотрудника со второй по величине зарплатой Задачки как правило действительно не очень сложные и можно их натренировать Еще вопросы которые присутствуют почти всегда это вопросы про БД. Например рассказать про индексы или партиции. Часто эти вопросы практические - например рассказать про выбор поля партиции, но часто и больше в теорию - например рассказать про того как джойны могут происходить под капотом И на самом деле эти 3 вещи (бд, sql, python) дают большую часть того что вас спросят (по крайне мере у меня было так) Конечно, спрашивают еще и другие вещи. И про некоторые эти вещи нужно подробно рассказать, но например по Airflow большая часть услышанных мной вопросов было в формате «Расскажи какие операторы знаешь», то есть если работаешь с этим инструментом, то вопросов не возникнет

А чем я вообще занимаюсь? Хоть у меня и нет синдрома самозванца, но я иногда смотрю на свою работу со стороны и такой: «Да чем ты вообще занимаешься целый день?! Твоя задача всего лишь переложить таблички с одного места на другое и потом соеденить их. Что в этом сложного» 🤔 И на словах оно в целом так и есть. И вроде бы в работе с табличками особо ничего сложного нет, но потом работаешь и … Была у меня тут простая на первый взгляд задача - заинсертить (положить) данные в таблицу) Ну то есть что-то типо такого запроса:

insert table1
select * from table2
where id in (ну и тут айдишники отобранные по условию)

Опустим часть о том как именно достать эти айдишники (это тоже не всегда просто, но сейчас не об этом) - это делается с помощью запроса с джойнами у условиями Казалось бы задача решена - просто подставить наше условие в скобки в скрипте выше, но так не всегда работает, так как запрос тяжелый. Не понятно когда отработает, а там таймаут, ресурсов много хочет и тд Пришлось не много помаяться с этим 🤔 Короче в итоге я создал промежуточную таблицу, куда заинсертил нужные мне айдишники. Но и заинсертить было не так просто: сделал ДАГ который берет данные за один день, дальше это один день еще резался на чанки, дальше были вычисления и инсерт 🎉 И вот маленькая задача (даже задачей это сложно назвать), превратилась в целый квест А у вас бывают мысли о том что вы на работе занимаетесь не пойми чем?

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