📚 Как мы работаем со студентами: дипломы, которые становятся частью YDB
Привлекать студентов к написанию кода для opensource продуктам - отличные кейс. Все в выигрыше. У студента есть тема НИР, а у владельца продукта, готовый pull request. Win-Win.
Коллеги из YDB рассказали, как студенческие работы можно делать не «в стол», а на реальных задачах промышленной СУБД: от OpenTelemetry и SDK до интеграций со Spring и инструментов импорта данных.
В результате получается не только ВКР, но и вполне осязаемый инженерный проект для портфолио! Это крайне ценное дополнение.
В общем, хорош пытать бедного преподавателя на предмет тем для НИР. Сами ищите интересные вам открытые проекты и развивайте их 😎
А я отдохну🏖️ 🏖 🌊
Привлекать студентов к написанию кода для opensource продуктам - отличные кейс. Все в выигрыше. У студента есть тема НИР, а у владельца продукта, готовый pull request. Win-Win.
Коллеги из YDB рассказали, как студенческие работы можно делать не «в стол», а на реальных задачах промышленной СУБД: от OpenTelemetry и SDK до интеграций со Spring и инструментов импорта данных.
В результате получается не только ВКР, но и вполне осязаемый инженерный проект для портфолио! Это крайне ценное дополнение.
В общем, хорош пытать бедного преподавателя на предмет тем для НИР. Сами ищите интересные вам открытые проекты и развивайте их 😎
А я отдохну
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🤪1
📚 Redis Restarted in 4 Seconds. Postgres Died for 40 Minutes.
Интересный production-кейс про Redis и PostgreSQL.
Redis перезапустился всего за 4 секунды. Казалось бы, ничего страшного; сервис поднялся, kubernetes считает его здоровым (зелененьким). Но кэш после рестарта оказался пустым и вся нагрузка практически мгновенно пошла в PostgreSQL. Кто-то не позаботился о персистентности кэша 🤨.
Дальше классическая цепочка:
В результате Redis восстановился за секунды, а PostgreSQL пришлось восстанавливать почти 40 минут.
Важная мысль. Если база данных выдерживает production-нагрузку только благодаря высокому cache hit rate, то Redis уже не просто "глупый кэш". Он становится частью capacity planning всей системы.
Помочь могут постепенный "прогрев кэша", ограничение числа одновременных запросов к базе, защита от повторного вычисления одних и тех же данных и запас производительности PostgreSQL.
Вообще терминологии вида "прогрев кластера" или "прогрев кеша" очень привлекательны. По крайне мере подстегивают фантазии в уме🍬 . Но насколько это все применимо в реальных средах, тем более в продакшне, вопрос открытый 🤷♂️.
Надо будет "заИИшить" эту тему 😊
Интересный production-кейс про Redis и PostgreSQL.
Redis перезапустился всего за 4 секунды. Казалось бы, ничего страшного; сервис поднялся, kubernetes считает его здоровым (зелененьким). Но кэш после рестарта оказался пустым и вся нагрузка практически мгновенно пошла в PostgreSQL. Кто-то не позаботился о персистентности кэша 🤨.
Дальше классическая цепочка:
cold cache → cache misses → PostgreSQL → connection pool exhaustion → timeouts → retries → ещё больше нагрузкиВ результате Redis восстановился за секунды, а PostgreSQL пришлось восстанавливать почти 40 минут.
Важная мысль. Если база данных выдерживает production-нагрузку только благодаря высокому cache hit rate, то Redis уже не просто "глупый кэш". Он становится частью capacity planning всей системы.
Помочь могут постепенный "прогрев кэша", ограничение числа одновременных запросов к базе, защита от повторного вычисления одних и тех же данных и запас производительности PostgreSQL.
Вообще терминологии вида "прогрев кластера" или "прогрев кеша" очень привлекательны. По крайне мере подстегивают фантазии в уме
Надо будет "заИИшить" эту тему 😊
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
Redis Restarted in 4 Seconds. Postgres Died for 40 Minutes.
When persistence is off — and a routine deploy becomes a cold-cache stampede.
❤2
📚 SQL injection isn't dead
Очень прикольная статья с неожиданным выводом в конце. Постараюсь кратко разобрать.
SQL Injection (
Главное правило при этом не изменилось:
Поэтому основа защиты - parameterized queries / prepared statements. А code review, SAST, pentest, WAF и runtime protection это уже дополнительные уровни defense in depth.
И самое сладкое:
ИИшка код генерит как сумасшедшая, но насколько этот код безопасен большой вопрос.
Очень прикольная статья с неожиданным выводом в конце. Постараюсь кратко разобрать.
SQL Injection (
SQLi) - это уязвимость, которой уже несколько десятилетий. Казалось бы, ORM, prepared statements и современные фреймворки давно должны были её похоронить. Но SQLi по-прежнему регулярно находят в production-системах. Почему?👉 legacy-код всё ещё собирает SQL через конкатенацию строк;
👉 использование ORM не гарантирует безопасность;
👉 SAST и WAF не способны поймать абсолютно все сценарии;
👉 AI coding assistants тоже могут генерировать небезопасный SQL-код.
Главное правило при этом не изменилось:
Пользовательские данные должны оставаться данными, а не становиться частью SQL-команды.
Поэтому основа защиты - parameterized queries / prepared statements. А code review, SAST, pentest, WAF и runtime protection это уже дополнительные уровни defense in depth.
И самое сладкое:
AI не устраняет старые классы уязвимостей. Он способен масштабировать как хороший, так и плохой код.
ИИшка код генерит как сумасшедшая, но насколько этот код безопасен большой вопрос.
Доверяете ли клоду настолько, что готовы воспринимать его код как "безопасный"? Ммм?
www.aikido.dev
SQL injections (and Little Bobby Tables) aren't dead
The fix for SQL injection is decades old and still works. So why did WordPress core just need an emergency patch for one? The data, and how to defend against it.
❤2
📚 Database Trends and Applications Magazine: June/July 2026 Issue
❗️Тема номера: перестройка корпоративных данных и инфраструктуры под практический AI.
➡️Semantic Layers Are Rising to the Top of the Data Agenda, Survey Shows
Честно, у меня на работе как раз внедряются такие агенты. Всё надо очень подробно описать, чтобы агент тебя понял. Точнее не так, чтобы агент сделал то, что тебе нужно. С одной стороны это отчасти прикольно, но меня почему-то раздражает 😡. Без объяснений 🧐
➡️ The Speed of Insight: Enabling the Next Frontier of Real-Time AI
Такие AI агенты мне почему-то больше нравятся😊. Тоже столкнулся с таким в работе.
1 - Приходит запрос от клиента.
2 - ИИ уже проанализировал его. Может быть даже в логи залез и уже пришел ко мне с некими выводами по проблеме.
3 - От меня "кожаного мешка" осталось только перепроверить за ним и подтвердить выводы или опровергнуть их. Удобненько ☺️.
➡️ The Cost of "Good Enough" SQL in a High-Volume Database Environment
Я как-то работал с софтом одного популярного банковского вендора ПО. Так у него в сервер приложений был встроен механизм генерации отчета обо всех исходящих запросах БД. Можно было выставить фильтр по датам и увидеть очень подробную статистику. Что за запрос, сколько раз за период он выполнялся, какое среднее время выполнения и т.д. Безумного удобная штука 👍! Больше такого не видел ни у кого 😟.
❗️Тема номера: перестройка корпоративных данных и инфраструктуры под практический AI.
➡️Semantic Layers Are Rising to the Top of the Data Agenda, Survey Shows
AI-агентов недостаточно просто дать доступ к данным. Им нужно однозначно понимать (разжевать), что именно означают "выручка", "маржа", "клиент" и другие бизнес-понятия. Поэтому semantic layer постепенно превращается из вспомогательного инструмента BI в инфраструктуру доверия для AI.
Честно, у меня на работе как раз внедряются такие агенты. Всё надо очень подробно описать, чтобы агент тебя понял. Точнее не так, чтобы агент сделал то, что тебе нужно. С одной стороны это отчасти прикольно, но меня почему-то раздражает 😡. Без объяснений 🧐
➡️ The Speed of Insight: Enabling the Next Frontier of Real-Time AI
Real-Time AI - это не отдельная технология, а перестройка всей data-инфраструктуры так, чтобы AI мог реагировать на события практически в момент их возникновения.
Такие AI агенты мне почему-то больше нравятся😊. Тоже столкнулся с таким в работе.
1 - Приходит запрос от клиента.
2 - ИИ уже проанализировал его. Может быть даже в логи залез и уже пришел ко мне с некими выводами по проблеме.
3 - От меня "кожаного мешка" осталось только перепроверить за ним и подтвердить выводы или опровергнуть их. Удобненько ☺️.
➡️ The Cost of "Good Enough" SQL in a High-Volume Database Environment
В больших системах "достаточно хороший" SQL уже недостаточно хорош - небольшая неэффективность запроса умножается на объём и частоту его выполнения и превращается в реальные деньги и проблемы производительности.
Я как-то работал с софтом одного популярного банковского вендора ПО. Так у него в сервер приложений был встроен механизм генерации отчета обо всех исходящих запросах БД. Можно было выставить фильтр по датам и увидеть очень подробную статистику. Что за запрос, сколько раз за период он выполнялся, какое среднее время выполнения и т.д. Безумного удобная штука 👍! Больше такого не видел ни у кого 😟.
Database Trends and Applications
Database Trends and Applications Magazine: June/July 2026 Issue
The June/July 2026 issue of DBTA showcases the annual 'DBTA 100' list.
❤2👍1
📚 Database Per Service vs. Shared Database — A Real Trade-off from Banking Architecture
Классический выбор в микросервисной архитектуре. Одна общая БД или отдельная база на каждый сервис?
Shared Database гораздо проще. Используется обычные JOIN, foreign keys, ACID-транзакции и накладных расходов меньше на инфраструктуру. Но сервисы быстро начинают зависеть от общей схемы, мешают друг другу при изменениях и могут конкурировать за ресурсы.
Database per Service даёт автономность, изоляцию и независимое масштабирование. Сервис владеет своими данными, независимо развивается и масштабируется. Цена - distributed systems во всей красе: eventual consistency, Saga, Outbox, CQRS/read models и отсутствие простых cross-service JOIN.
Итого:
❇️ post scriptum
Отдельно интересно посмотреть на это через призму современных распределённых СУБД. Они позволяют держать несколько сервисов в одном распределённом кластере, сохраняя логические границы данных.
Получается своего рода
Но есть соблазн нарушить святые правила архитектурного паттерна. Если сервисы начинают напрямую ходить в таблицы друг друга, делать cross-domain JOIN и связывать всё глобальными транзакциями, то перед нами снова Shared Database, хоть и распределённая.
Мне это напоминает вечный хейт MongoDB из-за того, что там нет схемы. Вставляй данные какие-то хочешь. Мол это сильно развращает разработчиков. Почему-то никто не вспоминает о том, что в MongoDB есть JSON Schema validation, которая пришла с версии 3.6 в далеком 2017 году.
Но всем как будто пофиг...😔
Классический выбор в микросервисной архитектуре. Одна общая БД или отдельная база на каждый сервис?
Я где-то читал, если ты в микросервисной архитектуре используешь одну общую БД, то это фуууу, позор 🤬. Это нарушение! У каждого сервиса должна быть своя БД 🧐.
Shared Database гораздо проще. Используется обычные JOIN, foreign keys, ACID-транзакции и накладных расходов меньше на инфраструктуру. Но сервисы быстро начинают зависеть от общей схемы, мешают друг другу при изменениях и могут конкурировать за ресурсы.
Database per Service даёт автономность, изоляцию и независимое масштабирование. Сервис владеет своими данными, независимо развивается и масштабируется. Цена - distributed systems во всей красе: eventual consistency, Saga, Outbox, CQRS/read models и отсутствие простых cross-service JOIN.
Итого:
Автор для своего банковского приложения выбрал Database per Service и не пожалел. Да, кодить стало сложнее, но получил сверхгибкое масштабирование, что потенциально избавило команду от множества проблем.
Database per Service — это не бесплатная "правильная архитектура", а обмен связанности на операционную сложность.
❇️ post scriptum
Отдельно интересно посмотреть на это через призму современных распределённых СУБД. Они позволяют держать несколько сервисов в одном распределённом кластере, сохраняя логические границы данных.
Получается своего рода
shared infrastructure + isolated ownership, т.е. попытка получить часть удобства Shared Database и часть автономности Database per Service.Но есть соблазн нарушить святые правила архитектурного паттерна. Если сервисы начинают напрямую ходить в таблицы друг друга, делать cross-domain JOIN и связывать всё глобальными транзакциями, то перед нами снова Shared Database, хоть и распределённая.
Мне это напоминает вечный хейт MongoDB из-за того, что там нет схемы. Вставляй данные какие-то хочешь. Мол это сильно развращает разработчиков. Почему-то никто не вспоминает о том, что в MongoDB есть JSON Schema validation, которая пришла с версии 3.6 в далеком 2017 году.
Но всем как будто пофиг...😔
Medium
Database Per Service vs. Shared Database — A Real Trade-off from Banking Architecture
We debated this for three weeks on a retail banking platform migration. Here’s every argument, every concern, and the decision that shaped…
❤4👍1
⚡️⚡️Amazon покупает DuckDB Labs ⚡️⚡️
Официальная формулировка:
Но давайте будем реалистами. Мы уже проходили это. Никто не мешает через пару лет сменить лицензию, когда проект станет критически важным для инфраструктуры.
И знаете, это идеально иллюстрирует мой главный тезис на курсах:
Раньше корпорации стеснялись пожирать друг друга. Сейчас правила игры просты, если стартап выстрелил, то его покупают. Не выстрелил? Тоже покупают, просто чтобы убрать потенциальную угрозу. Денег у гигантов вагон и маленькая тележка.
А разработчики или фаундеры... Называйте их как хотите. Все любят деньги 💰. Жизнь такая. Хочется проснуться однажды с мыслью, что счет в банке закрывает все вопросы и тревоги🧘♂ . Особенно когда за спиной семья👩👩👧👧
Идея идей, а жизнь нужна, чтобы кайфовать!🏄♂️
Официальная формулировка:
"DuckDB останется Open Source".
Но давайте будем реалистами. Мы уже проходили это. Никто не мешает через пару лет сменить лицензию, когда проект станет критически важным для инфраструктуры.
И знаете, это идеально иллюстрирует мой главный тезис на курсах:
сегодняшний капитализм победил окончательно и бесповоротно.
Раньше корпорации стеснялись пожирать друг друга. Сейчас правила игры просты, если стартап выстрелил, то его покупают. Не выстрелил? Тоже покупают, просто чтобы убрать потенциальную угрозу. Денег у гигантов вагон и маленькая тележка.
А разработчики или фаундеры... Называйте их как хотите. Все любят деньги 💰. Жизнь такая. Хочется проснуться однажды с мыслью, что счет в банке закрывает все вопросы и тревоги
Идея идей, а жизнь нужна, чтобы кайфовать!
Please open Telegram to view this post
VIEW IN TELEGRAM
MotherDuck
DuckDB outgrows its nest | MotherDuck
Today Duck Labs, the developers of DuckDB, announced they are being acquired by Amazon. This is big news in the duck-iverse, and many people are wondering what this will mean for everyone’s favorite duck-powered database, MotherDuck.
🐳4
🎦 Are your agents on ACID? ft. Mike Stonebraker, creator of Postgres, and DBOS CEO Qian Li
Посмотрел колоборационный вебинар Cockroach Labs и DBOS с Майклом Стоунбрейкером, создателем Postgres
Майкл Стоунбрейкер - фактический живой символ всей науки о СУБД в Мире! Приятно было его послушать. Человек-легенда 😊
А значит, возникает классическая проблема: что делать, если агент выполнил 8 шагов из 10, затем вызвал несколько LLM, сходил в API, изменил данные и... упал.⬆️
Начинать всё сначала это дорого и иногда опасно. LLM недетерминированы, а некоторые действия вообще нельзя повторять дважды: например, оплату.
Поэтому каждый шаг нужно делать durable:
👉 сохранять состояние после выполнения
👉 после сбоя продолжать с последнего checkpoint
👉 для отката использовать механизмы компенсации / Saga
👉 для внешних API нужны idempotency keys
Интересная идея DBOS: не поднимать отдельный тяжелый оркестратор, а хранить состояние workflow прямо в транзакционной БД. Тогда сама БД становится фундаментом durable execution.
Майкл топит за то, что сервер баз данных должен превратиться в Workflow Server. Понимайте как хотите 😊
Кажется, архитектура AI-приложений постепенно приходит к довольно знакомым проблемам распределенных систем.
❇️ Послесловие. Перед просмотром видео, у меня в голове засела высказывание одного из спикеров конференции по образованию. Речь шла о предпринимательстве и студенческих стартапах.
Если автор стартапа является студент без опыта, экспертизы и каких-либо достижений в этой области, то для инвестора это повышенный риск. Но если проект запускает, например, преподаватель или исследователь с серьезным научным бэкграундом именно в этой сфере, картина уже совсем другая. Это "зеленый флажок"🏳️ в пользу проекта.
С DBOS у меня возникла похожая ассоциация.
Конечно, громкое имя само по себе не гарантирует успех. Но в данном случае экспертиза людей за проектом это хороший повод как минимум внимательно за ним следить.
Посмотрел колоборационный вебинар Cockroach Labs и DBOS с Майклом Стоунбрейкером, создателем Postgres
Майкл Стоунбрейкер - фактический живой символ всей науки о СУБД в Мире! Приятно было его послушать. Человек-легенда 😊
Главная мысль: современные AI-агенты все больше похожи на долгоживущие transactional workflows.
А значит, возникает классическая проблема: что делать, если агент выполнил 8 шагов из 10, затем вызвал несколько LLM, сходил в API, изменил данные и... упал.
Начинать всё сначала это дорого и иногда опасно. LLM недетерминированы, а некоторые действия вообще нельзя повторять дважды: например, оплату.
Поэтому каждый шаг нужно делать durable:
👉 сохранять состояние после выполнения
👉 после сбоя продолжать с последнего checkpoint
👉 для отката использовать механизмы компенсации / Saga
👉 для внешних API нужны idempotency keys
Интересная идея DBOS: не поднимать отдельный тяжелый оркестратор, а хранить состояние workflow прямо в транзакционной БД. Тогда сама БД становится фундаментом durable execution.
Майкл топит за то, что сервер баз данных должен превратиться в Workflow Server. Понимайте как хотите 😊
Кажется, архитектура AI-приложений постепенно приходит к довольно знакомым проблемам распределенных систем.
❇️ Послесловие. Перед просмотром видео, у меня в голове засела высказывание одного из спикеров конференции по образованию. Речь шла о предпринимательстве и студенческих стартапах.
Вопрос, как инвесторы выбирают стартапы в которые стоит вложиться?
Ответ был довольно простым: важно смотреть не только на идею, но и на то, кто за ней стоит.
Если автор стартапа является студент без опыта, экспертизы и каких-либо достижений в этой области, то для инвестора это повышенный риск. Но если проект запускает, например, преподаватель или исследователь с серьезным научным бэкграундом именно в этой сфере, картина уже совсем другая. Это "зеленый флажок"
С DBOS у меня возникла похожая ассоциация.
Конечно, громкое имя само по себе не гарантирует успех. Но в данном случае экспертиза людей за проектом это хороший повод как минимум внимательно за ним следить.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Are your agents on ACID? ft. Mike Stonebraker, creator of Postgres, and DBOS CEO Qian Li
Modern software is composed of long-running, multi-step workflows spanning AI agents, microservices, databases, APIs, and humans. As applications become more distributed and autonomous, workflow orchestration and durability are becoming dominant architectural…
❤1
В этом году помимо моих двух курсов я написал третий курс "Проектирование распределенных схем базы данных". Пока я его еще полирую, но думаю провести небольшой открытый урок уже в октябре 🍂🍁. Следите на анонсами 😉
Так же начинается новый цикл митапов, форумов и конференций - а это значит нам ждет океан нового контента 🌊, интересный инсайдов
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉9
📚 The Mighty Duck
После покупки AWS компании DuckDB Lab будет выходить еще целый ряд статей, где авторы будут рассуждать о причинах и последствиях данной покупки. Вот одна из них.
Ранее архитектура данных была такая
Современная модная вариация выглядит так
В этой модели Amazon не нравится, что её инфраструктуру используют как S3. Все "дорогие" вычисления проходят на платформах Snowflake, Databricks или еще где-то. Это потеря прибыли 💸.
Как же тут поможет DuckDB🐥 ? Автор предполагает, что Amazon попытается создать следующую модель взаимодействия:
Особенно интересен здесь протокол Quack. Разработчик может управлять запросом локально, но само вычисление выполнять на машине рядом с данными в S3, вместо того чтобы тащить терабайты на ноутбук.
❇️ В целом, идея то интересная. Будет ли так покажет время.
После покупки AWS компании DuckDB Lab будет выходить еще целый ряд статей, где авторы будут рассуждать о причинах и последствиях данной покупки. Вот одна из них.
Ранее архитектура данных была такая
storage➕ query engine➕ interface
Современная модная вариация выглядит так
S3 / object storage🤩 отдельный table format/catalog🤩 отдельный query engine🤩 интерфейс, который всё чаще может быть AI/agent.
В этой модели Amazon не нравится, что её инфраструктуру используют как S3. Все "дорогие" вычисления проходят на платформах Snowflake, Databricks или еще где-то. Это потеря прибыли 💸.
Как же тут поможет DuckDB
ноутбук➡️ DuckDB➡️ S3➡️ вычисления в AWS
Особенно интересен здесь протокол Quack. Разработчик может управлять запросом локально, но само вычисление выполнять на машине рядом с данными в S3, вместо того чтобы тащить терабайты на ноутбук.
Quack - протокол, позволяющий нескольким экземплярам DuckDB взаимодействовать и выносить вычисления ближе к данным.
❇️ В целом, идея то интересная. Будет ли так покажет время.
Please open Telegram to view this post
VIEW IN TELEGRAM
Alt + E S V
The Mighty Duck
DuckLabs, the company behind the beloved developer database DuckDB, is being acquired by Amazon Web Services (AWS). The August 26, 2026 announcement stated DuckLabs will join AWS as a subsidiary in September 2026. There are no planned changes to the MIT license…
❤3
Какие были раньше времена! Что только не делали чтобы заслужить твою преданность и доверие!
С пятницей!
#mems
С пятницей!
#mems
👍3
📚 CAP Theorem: The One Rule That Explains Why Your Bank Uses SQL and Instagram Does Not
Очередная статья про CAP и PACELK натолкнула на одну интересную мысль. В реальных системах бизнес редко выбирает между "строго правильно" или "нельзя".
Гораздо чаще появляется третий вариант:
👉 Банкомат может выдать ограниченную сумму без связи с банком (ограниченная автономия).
👉 Платёжная сеть может одобрить транзакцию без ответа банка владельца карты (небольшие суммы) .
👉Авиакомпания может продать больше билетов, чем мест (овербукинг).
👉Подписочный сервис может не отключать доступ сразу после неуспешного платежа (подписка на ChatGPT).
Во всех этих случаях формальный инвариант временно нарушается.
Но это не архитектурная халатность. Наоборот, бизнес заранее решает:
➖ какой риск допустим;
➖ насколько можно отклониться от «истины»;
➖ как обнаружить расхождение;
➖ как потом его компенсировать.
И здесь, на мой взгляд, находится важный урок CAP и distributed systems вообще:
Если строгая
Архитектурные догмы заканчиваются там, где начинается экономика продукта 🤔.
Очередная статья про CAP и PACELK натолкнула на одну интересную мысль. В реальных системах бизнес редко выбирает между "строго правильно" или "нельзя".
Гораздо чаще появляется третий вариант:
разрешить, но в пределах бюджетных рисков
👉 Банкомат может выдать ограниченную сумму без связи с банком (ограниченная автономия).
👉 Платёжная сеть может одобрить транзакцию без ответа банка владельца карты (небольшие суммы) .
👉Авиакомпания может продать больше билетов, чем мест (овербукинг).
👉Подписочный сервис может не отключать доступ сразу после неуспешного платежа (подписка на ChatGPT).
Во всех этих случаях формальный инвариант временно нарушается.
Но это не архитектурная халатность. Наоборот, бизнес заранее решает:
И здесь, на мой взгляд, находится важный урок CAP и distributed systems вообще:
consistency, availability и даже некоторые бизнес-правила — не самоцель. Они обслуживают бизнес-инварианты.
Если строгая
consistency ухудшает клиентский опыт сильнее, чем редкие контролируемые ошибки, зрелая система вполне может выбрать inconsistency но ограниченную, наблюдаемую и компенсируемую.Архитектурные догмы заканчиваются там, где начинается экономика продукта 🤔.
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
CAP Theorem: The One Rule That Explains Why Your Bank Uses SQL and Instagram Does Not
When a network splits your servers apart, you have to choose between being correct and being available. You cannot have both. This single…
❤3👍3🔥1
📚 MariaDB добивает MySQL: поддержка закрывается а открытый код прячут за пейволл
Статья-трагедия! Если читать, то это прям крах MySQL. Ребята из SecurityLab немного перегнули. Если выключить эмоции, то смысл в следующем:
Зачем приложениям из экосистемы MariaDB поддерживать и MySQL? Правильно не зачем. Поэтому хорош тратить силы в пустую.
Как я понял, раньше пока кодовые базы были близки поддержка сразу двух СУБД не была проблематичной. Сейчас всё разошлось в разы сильнее, поэтому поддержка стала намного дороже.
Вот и вся новость 😊
Статья-трагедия! Если читать, то это прям крах MySQL. Ребята из SecurityLab немного перегнули. Если выключить эмоции, то смысл в следующем:
MariaDB использует контроль над Galera, чтобы сильнее развести экосистемы MariaDB и MySQL и направить пользователей кластерного MySQL либо к миграции на MariaDB, либо к альтернативам вроде Percona
Зачем приложениям из экосистемы MariaDB поддерживать и MySQL? Правильно не зачем. Поэтому хорош тратить силы в пустую.
Как я понял, раньше пока кодовые базы были близки поддержка сразу двух СУБД не была проблематичной. Сейчас всё разошлось в разы сильнее, поэтому поддержка стала намного дороже.
Вот и вся новость 😊
❤3😁1
📚We Moved to NoSQL for the Flexibility. It Took a Year to Admit We’d Just Moved the Schema Somewhere We Couldn’t See It Anymore.
Классическая история. Команда переезжает с РСУБД на документную БД, чтобы избавиться от миграций, согласований и жёсткой схемы.
Переезд сработал 💪 Поля добавляются без проблем, метаданные лежат как надо. А через год выясняется, что документ
🧠 Какие интересные выводы я для себя уловил:
1️⃣ Schema-less не существует.
Любые данные имеют схему. Вопрос лишь где, кем и когда она контролируется. NoSQL убирает не схему, а одну конкретную точку её контроля.
2️⃣. Схема превратилась в распределённый контракт без владельца.
Если в одну коллекцию пишут несколько сервисов, каждый начинает нести собственное представление о данных. Это неуправляемый консенсус.
3️⃣. Стоимость не исчезла, а легла под процент.
РСУБД часто заставляет заплатить за изменение схемы авансом: моделирование, миграции, проверки.
Schema-flexible БД позволяет этот платёж отложить. Но без должного управления долг начинает копиться и оплачивать его потом приходится всем потребителям.
4️⃣. Validation layer - это возвращение централизованного управления схемой.
То, что команда собирала почти квартал, в индустрии давно есть. Пример тому, schema registry (Avro/Confluent), контракты (protobuf/JSON Schema с enforcement на продюсере).
5️⃣. Для персистентных данных "принцип Постела" опасен.
Хранилищу лучше быть
Писать только актуальную форму данных, но уметь читать несколько совместимых версий.
И пожалуй, главный вывод:
Классическая история. Команда переезжает с РСУБД на документную БД, чтобы избавиться от миграций, согласований и жёсткой схемы.
Переезд сработал 💪 Поля добавляются без проблем, метаданные лежат как надо. А через год выясняется, что документ
user оброс шестью разными формами, один сервис пишет signupDate, другой createdAt, и БД молча принимает оба.🧠 Какие интересные выводы я для себя уловил:
1️⃣ Schema-less не существует.
Любые данные имеют схему. Вопрос лишь где, кем и когда она контролируется. NoSQL убирает не схему, а одну конкретную точку её контроля.
2️⃣. Схема превратилась в распределённый контракт без владельца.
Если в одну коллекцию пишут несколько сервисов, каждый начинает нести собственное представление о данных. Это неуправляемый консенсус.
Схема начнёт стихийно жить во всём коде сразу.
3️⃣. Стоимость не исчезла, а легла под процент.
РСУБД часто заставляет заплатить за изменение схемы авансом: моделирование, миграции, проверки.
Schema-flexible БД позволяет этот платёж отложить. Но без должного управления долг начинает копиться и оплачивать его потом приходится всем потребителям.
4️⃣. Validation layer - это возвращение централизованного управления схемой.
То, что команда собирала почти квартал, в индустрии давно есть. Пример тому, schema registry (Avro/Confluent), контракты (protobuf/JSON Schema с enforcement на продюсере).
5️⃣. Для персистентных данных "принцип Постела" опасен.
Хранилищу лучше быть
строгим на записи и толерантным на чтении. Писать только актуальную форму данных, но уметь читать несколько совместимых версий.
И пожалуй, главный вывод:
Schema flexibility - это не отсутствие ограничений. Это выбор места, где вы заплатите за управление изменениями: при записи, при миграции или потом во всех consumer'ах сразу.
👍6😁1