Украл текст из "соседней беседки". Автор мне разрешил 🤝

Делюсь с вами! 🖐 🍧

Эволюция PostgreSQL: 1986–2025
От исследовательской базы данных до корпоративной и готовой к ИИ платформе

Путь PostgreSQL — одна из самых выдающихся историй успеха в истории баз данных.

Изначально разработанная Майклом Стоунбрейкером в рамках проекта POSTGRES в 1986 году, она развилась из более ранней системы баз данных Ingres в Калифорнийском университете в Беркли. То, что начиналось как академическая исследовательская инициатива, превратилось в одну из самых мощных, расширяемых и готовых для корпоративных открытых баз данных в мире.

Вот краткий обзор его основных этапов:
1986 — Начало проекта POSTGRES (UC Berkeley)
1994 – POSTGRES95 – добавлена поддержка SQL
1996 – версия 6.0 – Переименована в PostgreSQL и Глобальная группа разработки PostgreSQL (PGDG)
2000 – версия 7.0 – улучшения MVCC и WAL
2005 – версия 8.0 – поддержка Windows, PITR, Tablespaces
2008 – версия 8.3 – Полнотекстовый поиск, интегрированный в ядро
2010 – версия 9.0 – Потоковое воспроизведение
2011 – версия 9.1 – Синхронная репликация
2013 – версия 9.3 – Материализированные просмотры, JSON
2016 – версия 9.6 – Параллельный запрос
2017 – версия 10 – Логическая репликация, декларативное разбиение
2018 – версия 11 – Улучшенное разбиение и параллелизм
2019 – версия 12 – Сгенерированные столбцы, РЕИНДЕКС ОДНОВРЕМЕННО
2020 – версия 13 – дедупликация B-дерева, прирост производительности VACUUM
2021 – версия 14 – Параллелизм и улучшения индексации
2022 – версия 15 – команда MERGE, улучшения логической репликации
2023 – версия 16 – Улучшения производительности, мониторинг, логическое декодирование в режиме ожидания
2024 – версия 17 – Высокая доступность, производительность и улучшения VACUUM
2025 – версия 18 – Улучшенная логическая репликация, зрелость экосистемы векторного поиска, ИИ и корпоративный фокус

От академических исследований до поддержки финансовых систем, SaaS-платформ, правительств и рабочих нагрузок, управляемых искусственным интеллектом — PostgreSQL продолжает доказать, почему его часто называют:

«Самая продвинутая в мире реляционная база данных с открытым исходным кодом.»

Как DBA и разработчики, мы стали свидетелями того, как PostgreSQL стал полнофункциональной альтернативой настоящей корпоративной, облачной и поддержкой искусственного интеллекта платформы.

Эволюция продолжается.

📚 Сообщество MySQL призывает к обсуждению будущего экосистемы

Если кратко, то сообщество MySQL обзавидоволось PostgeSQL 🥲 и хочется так же бурно развиваться как последние. Но... Oracle вставляет палки в колеса и не дает расти🤬. Товарищи предложили создать независимый некоммерческий фонд развития MySQL и передать этому фонду все права на MySQL. Это даст возможность забустить 100500 доработок в проект и потеснить PostgreSQL на пьедестале самого динамично развивающейся OSS СУБД 🥋.

Срок ответа 31 марта. Осталось недолго ждать финальной развязки ✌️.

Я очень жду профессию из разряда ИИ-психолог. Человек, который на "серьезных щах" будет копаться в обученных моделях и корректировать их поведение. А может такие специалисты уже есть?

С пятницей!

#mems

Наткнулся на статью по проектированию реляционных баз данных, а затем на его видеоролик на ютубе 🎦 .

Весь курс по сути пересказ книги: "Grokking Relational Database Design".

Удовольствие на 6 часов🥱. Нууу, дай думаю всё-таки посмотрю и послушаю 👂. Вдруг что-то интересное скажут. Интересно, чему учат иностранцы других иностранцев 🤺.

В целом, материал хороший, но всё это уже было рассказано 100500 раз. Никаких откровений или нового взгляда. Почему-то автор даже JSON игнорирует в своем курсе 🤔.

Получается, что с одно стороны - это хороший базовый, вводный учебник по проектированию. А с другой, он оторвал от современных реалий 🤯.

Я бы в книгах/курсах по проектированию хотел бы видеть такие темы:

1. Партиционирование, шардинг
2. Влияние репликаций на модель данных
3. Правила эволюции схемы данных
4. Полуструктурные данные (JSON/XML), гибридное моделирование "в реляционное" vs "в документ".
5. Хотя бы кратенько про моделирование схем для OLAP нагрузок(dimensional modeling: star/snowflake, SCD, витрины/слои)
6. Практики по безопасности/комплаенса на уровне схемы: (row-level security аудит, политики хранения/удаления)
7. Правила проектирования распределенных схем данных

Тогда бы курс выглядел более практичным и полезным .

А как вы думайте❔

🚶‍♂️‍➡️В продолжении темы проектирования схем баз данных.
Недавно была статья на Хабре
25 железных правил проектирования баз данных в PostgreSQL

Она собрала более 95+ лайков и свыше 190 комментов.

На мой взгляд - это успех автора 😎! Если учесть, что это "из песочницы", то еще больший успех 🎰!

Однако, во всех чатах, где я состою, статью откровенно "зас***и" 💩.

Написал сплошной бред, который почти никогда не бьется с продакшн системами. Все эти правила валидны для "школьной скамьи" и т.п.

Комментарии довольно жесткие 👊.

Примечательно, что опровержения или развернутого комментария "почему какое-то правило не работает" никто не дал 🫤. Ответ на претензию "почему" ответ такой:

"лень писать", "эти знания за которые люди платят деньги на мастер-классах/воркшопах".

Получается забавная проблема 🙁. "Кривая" и откровенно ложная статья набирает огромную популярность у сообщества, а потом мы на проде ловим такое 🔥... от чего челюсть не может встать на место несколько часов 😱.

Очередной раз ловлю себя на мысли, что надо написать статью или серию статей по проектированию схем данных для современных систем 📝. Причем видимо надо вводить какую-то классификацию этих систем и набор правил под каждую.

Повод посидеть, подумать на тему кому бы делегировать эту задачу? 😎

Есть желающие? 😉

📚Хочу поделиться образовательным сайтом от коллеги, Александра Поломодова.

Довольно интересная история создания этого сайта 😊

Если не вдаваться в подробности, то это электронная вариация его потенциальной книги, которую он прогнал через сервис lovable и в итоге получился сайт.

Для меня и для вас самым интересным и полезным должен стать раздел 8 Базы Данных.

🚧 p.s. всё информация о базах данных там должна подвергаться сомнению!🫤 Автор книги "Путеводитель по базам данных" в комментариях к посту уже изложил своё мнение.

Я часто вижу непонимание в глазах слушателей, когда речь заходит о терминах «структура», «полуструктура» и «неструктурированные данные». Поэтому решил написать короткий пост

Представьте: База данных - это огромный ресторан, а мы - повара, которым нужно быстро находить ингредиенты.

🍏 Структурированные данные — «идеальный холодильник»

Всё разложено по полкам и контейнерам, у каждого продукта своя ячейка и подпись. Нужно "все огурцы за вчера" - открыли нужную полку (таблицу) и мгновенно нашли.

🤔 SQL (PostgreSQL, MySQL и т.д.)
➕ быстрый поиск, строгая логика
➖ менять схему больнее, т.к. нужно перестраивать полки

🍕 Полуструктурированные данные — «коробка с заказом»

Вы заказали пиццу. В коробке лежит сама пицца, пакетик с соусом, перец, салфетки и рекламка. Есть общая логика и ярлыки, но набор и форма могут меняться. Сегодня есть оливки - завтра нет.
Это как JSON/XML, ключи есть, но структура может быть какой угодно.

🤔 NoSQL, JSON/XML/YAML
➕ легко добавлять новые поля
➖ без дисциплины начинается хаос 🪬

📦 Неструктурированные данные — «склад с коробками без подписей»

Это когда на складе ресторана стоит гора коробок и пакетов без нормальных наклеек и сортировки. Внутри может быть что угодно: мешок специй, куча чеков от поставщиков, распечатки меню, записки от шефа, фото блюда, инструкции к оборудованию. Хранилище знает только внешнее (размер/дата), а смысл приходится "доставать" отдельно (поиск, разметка, ML/LLM).

🤔 Data Lakes, облачные хранилища, векторные БД
➕ можно хранить всё
➖ чтобы найти смысл, нужно отдельно индексировать/анализировать

Архитектурные "премудрости" 🧙‍♂️:
Структура - это дорого строить, но дешево искать.
Неструктура - дешево хранить, но дорого понимать 😏.

Видео вчерашнего стрима с Никитой Кречетовым, Avito:

https://www.youtube.com/watch?v=bJnDkDAoOUw

Некоторое «мясо» по темам интервью (в видео на самом деле ещё больше инсайтов).

Масштаб: ~2700 хранилищ Redis, среди них сотни шардированных инсталляций. Это “внутреннее облако”: продуктовые команды не думают про жизненный цикл БД (создание, окружения, секреты, аккаунты, доступы) — это делает платформенная команда.

Почему исторически не Redis Cluster. Присматривались к Redis Cluster пробовали с Redis 5 → 7, но считали технологию незрелой для больших масштабов, требовалось перепилить компоненты платформы, клиентские библиотеки созрели не сразу.

Выбор Valkey vs KeyDB vs Dragonfly
• Лицензию Redis “закрыли” в марте 2024.
• Valkey: первый стабильный релиз — апрель 2024; форк Redis, бинарно близкий, но вначале было неясно, “взлетит ли” комьюнити.
• Dragonfly не тестировали: не подошла лицензия.
• KeyDB рассматривали всерьёз (развивался с 2019, поддержка/участие Snapchat), интересен master-master / active replication (идея распределять write-нагрузку без шардирования данных) + честная “многопоточность” через несколько event loop (условно “несколько Redis в потоках”), давала выигрыш на 3–4 потоках.
• Но в процессе выяснилось, что KeyDB фактически не поддерживается/не развивается, и примерно в 2025 приняли окончательное решение перейти на Valkey.

Производительность: конкретные цифры
• Оптимальная конфигурация по тестам: 3–4 потока.
• На тестах Valkey 8.x давал: до +50% к максимальному RPS/пропускной способности относительно Redis 7.2.8 (при одинаковом CPU-лимите, “CPU под завязку”), относительно KeyDB — ещё несколько процентов выигрыша.
• Узкое место часто было не CPU, а количество соединений и “пиковые” коннекты: Valkey 8.x держал их более линейно и предсказуемо (за счёт переработки многопоточности).

“Неожиданность” с обновлением версий
• Тестировали на 8.0.2 (стабильно, хороший выигрыш).
• Попробовали обновить часть кластеров на 8.1.0: на синтетике “норм”, но на реальных данных хуже latency (в среднем до ~1.5×), быстро откатились обратно на 8.0.2.
• Реальные паттерны нагрузки сложно воспроизвести на стенде, часть проблем проявляется только в проде.

Почему поверх Cluster построили ещё один “кластер” (sidecar + Raft)
Valkey/Redis Cluster “умный”, но для платформы не хватает критичных функций:
• Авто-учётки/доступы, интеграции с безопасностью.
• Автоматический решардинг при изменении топологии (добавление/удаление узлов).
• Умная поддержка зон доступности (AZ): важно равномерно держать master-ноды по зонам, кластер не умеет “умный фейловер” с учётом AZ.

🔥 спасибо за интересный платформенный кейс
👍 из полей доносится налей valkey!

—
Обучение Devhands Redis/Valkey: https://devhands.io/rv
Канал Алексея Рыбака: https://t.me/rybakalexey
Канал Avito Tech: https://t.me/avitotech
Канал Avito Data Tech: https://t.me/avitotech

Книга: «Архитектуры данных: современные решения для любых задач»

Свежий перевод западной литературу Orelly от нашего издательства Питер.

Примечательно, что книгу рецензировали в клубе рецензентов ИТ-литературы ReadITClub.

Судя по сайту данный клуб принадлежи КРОКу и получает дополнительную поддержку от российских издательств технической литературы.

Здорово, что у нас существует подобный клуб 💪! Я до того, как открыл книгу ничего об этом не знал.

❇️ Коротко про книгу.
В ней 288 страниц — надеюсь, прочитаю быстро 😁
Состоит из 4-х частей:

Часть I. Основные понятия
Часть II. Общие понятия архитектуры данных
Часть III. Архитектуры данных
Часть IV. Люди, процессы и технологии

Сегодня — Часть I, в ней 3 главы и 3 ключевые мысли:

1️⃣ Ценность важнее “объёмов”.
Big Data — это не “очень много данных”, а любые данные, которые дают эффект. Автор объясняет 6V: Volume, Variety, Velocity, Veracity, Variability и главное — Value. Остальные V важны ровно настолько, насколько помогают (или мешают) получить ценность.

2️⃣ Универсальной архитектуры нет.
Показывается “ландшафт” подходов: RDW → Data Lake → MDW → Fabric / Lakehouse / Mesh. Выбор зависит от нагрузок, типов данных, SLA, безопасности, доступности и того, как данные будут потребляться (в т.ч. self-service).

3️⃣ Выбор архитектуры — это процесс.
Предлагается ADS (architecture design session): собрать бизнес + ИТ и зафиксировать цели/ограничения (latency, объёмы, HA/DR, источники, ML и т.д.). По опыту: без практики и фасилитатора/ментора такую сессию легко "запороть". Было бы интересно на таких сессиях поприсутвовать...

❇️ Итоговая мысль
Сначала формулируем какую ценность хотим получить и фиксируем реальные требования/ограничения. Затем проводим дизайн-сессию со стейкхолдерами, чтобы осознанно выбрать архитектурный подход согласно задаче.

⚠️ Забавный исторический факт.
Data Lake появились в 2010-х годах. Самые яркие представители это Hadoop, Cloudera, Hortonworks и MapR. Однако, все эти решения (кроме Hadoop) провались в коммерческом плане. Причина банальная, неудобный и сложный инструментарий для извлечения данных (создание отчетов). Последним гвоздем стало то, что все любят SQL, транзакции и так нужный в корпоративной среде аудит.
В 2020-х случился "Ренессанс" с пришествием табличных форматов/транзакционными слоями вроде Delta Lake (и аналогов Iceberg/Hudi). Были добавлены transaction log, операции MERGE/UPDATE/DELETE, контроль схемы и версионирование (time travel). Таким образом, озеро стали гораздо ближе к требованиям BI и аналитики.

Очередное подтверждение того, что от SQL и реляционной теории нам не избавиться никогда 😈😈😈

И такое бывает 🙂

С пятницей!

#mems

📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».

Поговорим про Часть II. Общие понятия архитектуры данных.

Если часть I отвечает на вопрос "зачем нам архитектура", то часть II — это набор базовых кирпичей, из которых потом собираются любые современные платформы данных. Например, где хранить, как обрабатывать, как моделировать и как доставлять данные.

4️⃣ Хранение: RDW и Data Lake — это разные режимы работы

RDW - про управляемую отчётность и "единую версию правды", Data Lake — про гибкость и schema-on-read. На практике все определяют требования, где-то RDW вполне достаточно.

5️⃣ Lake без структуры быстро превращается в swamp → нужны уровни

Озеро надо организовывать слоями (raw → conformed → cleansed и т.д.). Это прямо перекликается с популярной сегодня medallion-логикой (bronze/silver/gold).

Иногда хочется почитать про то как люди превращают "светлую и чистую" идею с озером данных во что-то "мерзкое" и дурно пахнующее с явным юмористическим акцентом😁. Эх, статей по Data Swamp очень мало и почти все скучные...

6️⃣ "Платформа данных" — это не только хранилище

Кроме RDW/Lake нужны вещи, которые в реальных проектах постоянно всплывают: витрины (data marts), ODS для оперативной отчётности, data hub для интеграций, а ещё обязательные процессы вроде MDM, виртуализации и каталогов.

Помнится СУБД Tarantool от VK считает себя платформой данных. Обладает ли она этим свойствами? Надо покопать...

7️⃣ OLTP/OLAP, SMP/MPP, streaming, polyglot persistence

Глава является связующей между "проектирование данных" и архитектурным решением. Разделение транзакционных и аналитических контуров, выбор масштаба (SMP vs MPP), паттерны лямбда/каппа под batch+stream и идея polyglot persistence (под разные типы данных — разные хранилища).

8️⃣ Моделирование никуда не делось — просто стало "прагматичнее"

Реляционная модель, "звезда/снежинка", CDM, Data Vault, Kimball vs Inmon — это не просто академические идеи, а способы договориться, как бизнес будет потреблять данные (особенно в BI).

9️⃣ Ingestion: ETL/ELT — не религия, плюс появился reverse ETL

ETL vs ELT - это баланс под заданные ограничения. Мне очень понравилась идея reverse ETL - возвращать подготовленные данные из хранилища обратно в операционные системы, чтобы данные реально работали "в поле". Очень хочется посмотреть на такой процесс в продакшн среде. Жаль, что сейчас я немного далек от этого.

Небольшой вывод: без управления данными (качество, безопасность, комплаенс, ответственность) любая архитектура деградирует — особенно озёра и ELT-пайплайны.

Реальность как всегда иная 🧪. Исходя из моего опыта, заказчику всегда нужно всё и без ограничений и за недорого. Поэтому запускается процесс гибридизации ежа🦔, ужа🐍 и прочих зверят🦈🐗🦜. В итоге получается "платформа данных", которая уникальна для каждого заказчика 🌈.

Занавес

📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».

Сегодня про Часть III. Общие понятия архитектуры данных.

Теперь, когда базовые понятия освоены, можно переходить к мясу 🥩. Цветочки закончились — начинаются ягодки 🙂

Часть III можно представить как дорожную карту эволюции платформы данных: MDW → Data Fabric → Lakehouse → Data Mesh. Главный вывод здесь простой:

Архитектура - это не "выбор раз и навсегда", а наращивание способностей под меняющиеся со временем требования.

🔟 MDW (modern data warehouse) - уровень по умолчанию для большинства компаний: сочетание озера (гибкость, разные типы данных, data science) и warehouse/DWH (управляемый BI, "единственная версия правды"). На практике это компромисс между скоростью внедрения и качеством потребления.

1️⃣1️⃣Data Fabric - эволюция MDW для повышения доступности и безопасности данных. Обычно сюда относят: политики доступа, каталог/метаданные, MDM, виртуализацию, real-time, API.
Идея в том, чтобы данные были не просто "где-то там лежащими", а находимыми, безопасными и пригодными к использованию в масштабе организации. Не надо делать отчеты только для себя любимого, надо думать о других 😊

1️⃣2️⃣Lakehouse - попытка уйти от связки lake + DWH и сделать ставку на одно хранилище: оставить озеро, но добавить таблично-транзакционный слой (Delta Lake / Iceberg / Hudi), чтобы появились нормальные обновления, версионирование, контроль схемы и более предсказуемая эксплуатация.
Да, копий данных меньше, следовательно, контур проще 😉. Но governance и дисциплина никуда не исчезают🤨.

1️⃣3️⃣Data Mesh - это скорее организационная модель, чем технология: домены владеют данными, данные как продукт, self-service платформа и федеративное governance. Похоже чем-то на DevOps, концепция культурны и всё такое. Поэтому трактую ее по принципу: "я так вижу…" 💃👀

По книге: mesh подходит не всем и чаще всего внедряется постепенно (hub-and-spoke), а не "с наскока" в новый мир, минуя предыдущие стадии.

1️⃣4️⃣Практический takeaway: в современных проектах чаще выигрывает гибрид: MDW как основа + "fabric-capabilities" как зрелость, lakehouse - там, где оправдан "single storage", а mesh — только если компания реально готова к DDD и понимает цену изменений.

📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».

Наконец-то финальная 😮‍💨 Часть IV: Люди, процессы и технологии.

Этот тот раздел, где становится неловко всем, кто хотел “просто выбрать стек и поехать” 😅

1️⃣5️⃣ Люди и процессы - это главный "ускоритель" 🚀 и главный "тормоз" 🌪

Книга честно говорит, платформа данных рушится не из-за отсутствия очередного инструмента, а из-за нестыковки ролей, ожиданий и ответственности. Люди - иррациональные существа. Где-то они помогают проекту, а где-то его саботируют.

Что стоит зафиксировать:
👉 Данные — это продукт. Нужен владелец (product/data owner), понятные пользователи, SLA и критерии “готово”.

👉 Governance — это работа, а не слайд. Качество, доступы, комплаенс и lineage должны быть встроены в процесс, иначе любой lake превращается в swamp.

👉 Итеративность > “идеальный проект”. Прототипы, короткие релизы, постоянная обратная связь от потребителей — иначе получится “витрина в вакууме”.

👉 Знания нельзя “аутсорсить насовсем”. Если команда не забирает экспертизу и ответственность внутрь — проект будет вечной миграцией.

1️⃣6️⃣ Ядро технологий осталось прежним, но обёртка и интерфейс взаимодействия с ним уже другие в 2026.

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

🆕 Open table formats стали нормой. Вопрос чаще звучит не “какой warehouse”, а “какой формат таблиц + какой каталог + какие движки поверх”.

🆕 Каталог/политики - центр архитектуры. Governance всё больше переезжает в “платформенный слой”: единые правила доступа, семантика, контракты данных. Думаю коллеги из Аренадаты моя поддержат.

🆕 AI встраивается прямо в data-платформы. Не только " ML снаружи", но и внутри. Обработка неструктурированных данных, эмбеддинги, RAG-контуры - всё это влияет на выбор, где живут данные и как контролируется доступ.

🆕 Единые платформы (unified analytics) стали сильнее. Особенно там, где важна скорость внедрения и консолидация инструментов (инженерия данных + BI + governance + AI).

❗️Финальный вывод по Части IV❗️

Архитектура данных в 2026 уже не про то, чтобы "выбрать технологии и жить счастливо" 👨‍👨‍👦‍👦. Это про то, чтобы делать платформу как продукт. С пользователями, приоритетами и бесконечными правками 🛞.

Люди и процессы задают направление. Технологии просто помогают ехать быстрее 🏎. Или красиво буксовать 🚜.

А потом приходит реальность и тихо шепчет заклинание 🪄

“Хочу всё. Без ограничений. И за недорого”.

И в вашем озере данных 🏖 заводятся единороги 🦄, а в бэклоге начинает шевелиться химера из ежа 🦔 и ужа 🐍.

Иногда мир ровно такой каким его описывали в "древних" текстах.

С пятницей!

#mems

Сейчас отсматриваю видео с прошедшей на этой неделе конференции Monster SCALE Summit.

К сожалению, не получилось посмотреть её в онлайне, т.к. у меня были лекции в ВУЗах. Поэтому смотрю сейчас 👀.

В одном из выступлений мне безумно понравилась фраза спикера:

Those who would trade safety for performance, deserve neither safety nor performance.

Вольный перевод:

Те, кто выбирают между безопасностью и производительностью не заслуживаются ни того, ни другого.

Думаю, как круто звучит 🔥! Обязательно надо взять её на вооружение 😎 . Ждите этой отсылки на моих лекциях 😏

Пару слов про формат Monster SCALE Summit.
Это онлайн-конференция.

❇️Идея

👉 Организаторы собрали программу на 2 дня.
👉 Затем записали ВСЕ выступления на видео.
👉 Сделали по каждому видео рекламный short (клип).
👉 За неделю до старта выложили все шортсы на youtube канале. 👉 Во время конференции на платформе согласно графику открывали доступ к видео.
👉 Все зрители смотрели записанное заранее выступление! Далее в чате вели обсуждение доклада и задавали какие-то вопросы спикеру (если тот о был чате).

Согласитесь, формат крайне необычный! Я в прошлом году не придал этому значения, а в этом бросилось в глаза. Мне кажется такой формат довольно неплох.