📚 Neo4j for Engineers Who Already Know Databases
Редко попадается что-то стоящие и это как раз случай найти что-то блестящие на в горе песка.
Это вводная статья по Neo4j, но с опорой на то, что вы уже знакомы с реляционной теорией. Автор не объясняет графы «с нуля», а показывает, чем меняются проектирование, запросы, оптимизация и масштабирование системы после перехода от таблиц к графовой модели.
Весь материал построен вокруг условного интернет-магазина
Я как раз хотел переписать свою лекцию по Neo4j в курсе. Думаю многие идеи из статьи возьму для курса.
Редко попадается что-то стоящие и это как раз случай найти что-то блестящие на в горе песка.
Это вводная статья по Neo4j, но с опорой на то, что вы уже знакомы с реляционной теорией. Автор не объясняет графы «с нуля», а показывает, чем меняются проектирование, запросы, оптимизация и масштабирование системы после перехода от таблиц к графовой модели.
Весь материал построен вокруг условного интернет-магазина
Shopgraph: пользователи подписываются друг на друга, создают заказы и покупают товары. На этом примере автор сравнивает SQL-запрос с несколькими JOIN и Cypher-запрос, непосредственно описывающий путь:пользователь → знакомый → заказ → товар.
Я как раз хотел переписать свою лекцию по Neo4j в курсе. Думаю многие идеи из статьи возьму для курса.
❤1
📚 Предзаказ на книгу: «Высоконагруженные приложения. Программирование, масштабирование, поддержка. 2-е изд.»
Оформил предзаказ. Жду конца сентября⏳ .
Я уверен на ВСЕХ ИТ-конференциях осени-зимы это будет ТОП лидеров продаж! 💪 Я даже задумываюсь в подарок пару экземпляров взять 🤔.
Оформил предзаказ. Жду конца сентября
Я уверен на ВСЕХ ИТ-конференциях осени-зимы это будет ТОП лидеров продаж! 💪 Я даже задумываюсь в подарок пару экземпляров взять 🤔.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
📚 Я протестировал TerraMaster F4-425 Pro. Зачем современному NAS одновременно HDD и NVMe
Меня очень привлекает идея домашнего NAS хранилища. Много изучал в свое время, но так не и не решился купить.
Сейчас опять задумался на эту тему, но не могу себя убедить в его необходимости. Текущих ресурсов ноутбука мне хватает. Каких-то огромных фильмотек/фототек у меня нет. Всё вполне укладываться в 50/100 ГБ. Облачное хранилища мне выше крыши. Но почему-то очень хочется его купить...
Прикинул, по деньгам получается 100 000+ рубликов. Можно что-то дешевле взять, но если мы говорим о тандеме NAS сервер + ИБП + 1 NVMe + 2 HDD (5 TB) - то меньше не получается 😊
Может к новому году созрею или проект какой-то денежный подвернется и на эти деньги куплю NAS, не знаю.
Если у кого-то есть опыт активной работы с NAS, то напишите. Интересно почитать...
Например, на нем могут работать:➖ Docker-контейнеры;➖ виртуальные машины;➖ Plex или Jellyfin;➖ Nextcloud;➖ системы резервного копирования;➖ менеджеры фотографий;➖ базы данных;➖ Git-сервер;➖ домашняя автоматизация.
Меня очень привлекает идея домашнего NAS хранилища. Много изучал в свое время, но так не и не решился купить.
Сейчас опять задумался на эту тему, но не могу себя убедить в его необходимости. Текущих ресурсов ноутбука мне хватает. Каких-то огромных фильмотек/фототек у меня нет. Всё вполне укладываться в 50/100 ГБ. Облачное хранилища мне выше крыши. Но почему-то очень хочется его купить...
Прикинул, по деньгам получается 100 000+ рубликов. Можно что-то дешевле взять, но если мы говорим о тандеме NAS сервер + ИБП + 1 NVMe + 2 HDD (5 TB) - то меньше не получается 😊
Может к новому году созрею или проект какой-то денежный подвернется и на эти деньги куплю NAS, не знаю.
Если у кого-то есть опыт активной работы с NAS, то напишите. Интересно почитать...
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1
Решил глянуть 👀 несколько выступлений кое-как связанных с базами данных.
1️⃣ DWH‑инженер на стероидах: прокачиваем продуктивность с ИИ
Никита Бурковский, Data Engineer, BI Consult
Преза
Я ожидал от доклада каких-то откровений, но... получил что-то другое 🙃. Если кратко описать доклад, то автор открыл для себя ИИ-помощника. Затем скормил ему данные своего проекта/ов. И всё. Теперь все типовые инженерные задачи выполняются в разы проще 🤓. Даже ревью. Попутно дописал несколько ботов/роботов для еще большего упрощения задач 💪.
Об этом весь доклад 🤨.
Из интересного я бы отметил секцию, где автор совместно с ИИ пытались доработать схему данных. Почему-то ИИ показал себя слабее, чем ожидалось. Почему? Загадка... 🤷♂️
2️⃣ Ломаем PostgreSQL Jepsen’ом и верифицируем локи в TLA+: два подхода к надёжности распределённых систем
Евгений Дюков, Ведущий разработчик Managed Databases, Yandex Cloud
Преза
Евгений довольно опытный спикер от Яндекса💪. Очень часто выступает на различных конференциях и рассказывает об интересных вещах. Поэтому я
Фактически он рассказал о том, как использовал Jepsen, что-то там дописа/переписал. Попробовал TLA+ и PlusCal снова что-то там недополучил и собственно, конец🤨. Каких-то выводов нет.
Наверное цель была донести, что Яндекс использует популярные фреймворки для тестирования распределенных систем и пишет свои🥸. Пытается сделать фреймворк для тестирования устойчивость распределенных систем на выбранном участке кода. QA-фреймворк с кучей заглушек.
Откровений нет. Что-то в этом году уровень докладов низковат.🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
Мероприятия | Yandex Infrastructure
infra.conf 2026. Конференция Yandex Infrastructure.
Всё про создание инфраструктуры и высоконагруженные системы, инструменты разработки, базы данных и стораджи, построение и особенности эксплуатации инфраструктуры в эпоху ML.
👀1
📚 Новая СУБД «СберТеха» включена в реестр российского ПО
Нежданно негаданно СБТ анонсировали новую СУБД О.К.Е.А.Н. На оф сайте звучит как, Platform V Ocean DB. Даже в реестре отечественно ПО успели засветиться. Запись №33689 датирована 21 мая 2026 года.
❇️ Что это "зверь" такой?
Это наш отечественный форк опенсорс проекта OceanBase.
Как я понял, это пополнение в рядах DistributedSQL СУБД.
Её ключевая комбинация:
То есть это потенциальная замена сложной связке из MySQL/PostgreSQL, шардирующего middleware, CDC и отдельного ClickHouse.
Ближайшие аналоги: TiDB, PolarDB-X, YugabyteDB, CockroachDB и YDB.
К сожалению никаких публичных внедрений, независимых тестов нет - поэтому судить о какой-то зрелости продукта затруднительно.
Буду следить на анонсами СБТ. Я думаю осенью на ИТ-конференциях расскажут побольше о новинке. Ждемс...
Нежданно негаданно СБТ анонсировали новую СУБД О.К.Е.А.Н. На оф сайте звучит как, Platform V Ocean DB. Даже в реестре отечественно ПО успели засветиться. Запись №33689 датирована 21 мая 2026 года.
❇️ Что это "зверь" такой?
Это наш отечественный форк опенсорс проекта OceanBase.
Как я понял, это пополнение в рядах DistributedSQL СУБД.
Её ключевая комбинация:
👉 горизонтальное масштабирование записи;
👉 автоматический шардинг и ребалансировка;
👉 ACID-транзакции между узлами;
👉 отказоустойчивость без переключения всей базы;
👉 HTAP: транзакции и аналитика на одних данных;
👉 MySQL-совместимый интерфейс.
То есть это потенциальная замена сложной связке из MySQL/PostgreSQL, шардирующего middleware, CDC и отдельного ClickHouse.
Ближайшие аналоги: TiDB, PolarDB-X, YugabyteDB, CockroachDB и YDB.
К сожалению никаких публичных внедрений, независимых тестов нет - поэтому судить о какой-то зрелости продукта затруднительно.
Буду следить на анонсами СБТ. Я думаю осенью на ИТ-конференциях расскажут побольше о новинке. Ждемс...
😁2👍1
⚡️⚡️⚡️ClickHouse launches ClickHouse Labs with Andy Pavlo as VP of Database Research
Алексей Миловидов открывает исследовательскую лабораторию ClickHouse Labs. Его вице-президентом назначается один из самых известных исследователей по базам данных Энди Павло из университета Карнеги‑Меллона (CMU).
Очень мощная коллаборация💪! У Энди богатый опыт во множестве проектов и здорово, что он наконец-то нашел спонсора💰💰💰
Ждем крутых открытий в 2027 году ✨
Алексей Миловидов открывает исследовательскую лабораторию ClickHouse Labs. Его вице-президентом назначается один из самых известных исследователей по базам данных Энди Павло из университета Карнеги‑Меллона (CMU).
Очень мощная коллаборация💪! У Энди богатый опыт во множестве проектов и здорово, что он наконец-то нашел спонсора💰💰💰
Ждем крутых открытий в 2027 году ✨
ClickHouse
ClickHouse launches ClickHouse Labs with Andy Pavlo as VP of Database Research | ClickHouse
Renowned database researcher will lead a new group dedicated to advancing foundational database technology and sharing its work openly with the broader community.
🔥6
📚 Почти 7% компаний вернулись с российских СУБД на иностранные
Люблю провокационные статьи до жути 😊
Давайте чуть порассуждаем об обратной стороне импортозамещения СУБД
Общий тренд понятен: компании уходят с Oracle и Microsoft SQL Server на российские решения. Но миграция не всегда заканчивается промышленным запуском.
Иногда проект останавливают ещё на пилоте или откладывают на неопределённый срок. Причины могут быть следующие:
В результате компания может продолжать использовать зарубежную СУБД без официальной поддержки в России. DBA самостоятельно устанавливают обновления. Сами патчи можно получить через друзей-знакомых. В крайнем случае закупать поддержку через посредников. Банальная "заморозка" версии ПО тоже работает.
Публичных примеров окончательного возврата немного. Ладно, их почти нет. Кто в здравом уме будет писать, что проект перехода на отечественно ПО провалился? Никто.
Компании не любят рассказывать о неудачных проектах.
Поэтому все рассуждения и выводы строятся на инсайдах бесед с коллегами "по цеху".
Мое мнение остается прежним. Кто хотел мигрировать на отечественные СУБД уже мигрировал или находится на в финишной прямой по закрытию проекта. Остальным это просто не нужно.
Недавнее сообщения от PostgresPro о массовых сокращениях лишь подтверждают это. Проектом стало мало, а народу много. Закрыли проект, спасибо, всем пока👋
Люблю провокационные статьи до жути 😊
Импортозамещение - фуфло! Оно провалится рано или поздно! Западные решения лучше!! И бла-бла-бла... Кайф 😋
Давайте чуть порассуждаем об обратной стороне импортозамещения СУБД
Общий тренд понятен: компании уходят с Oracle и Microsoft SQL Server на российские решения. Но миграция не всегда заканчивается промышленным запуском.
Иногда проект останавливают ещё на пилоте или откладывают на неопределённый срок. Причины могут быть следующие:
👉 производительность на реальной нагрузке оказалась ниже ожидаемой;
👉 приложение слишком сильно зависит от PL/SQL и других функций Oracle;
👉 стоимость переделки превышает экономический эффект;
👉 не хватает специалистов и зрелых инструментов миграции;
👉 бизнес не готов принять риск простоя критической системы.
В результате компания может продолжать использовать зарубежную СУБД без официальной поддержки в России. DBA самостоятельно устанавливают обновления. Сами патчи можно получить через друзей-знакомых. В крайнем случае закупать поддержку через посредников. Банальная "заморозка" версии ПО тоже работает.
Публичных примеров окончательного возврата немного. Ладно, их почти нет. Кто в здравом уме будет писать, что проект перехода на отечественно ПО провалился? Никто.
Компании не любят рассказывать о неудачных проектах.
Поэтому все рассуждения и выводы строятся на инсайдах бесед с коллегами "по цеху".
Мое мнение остается прежним. Кто хотел мигрировать на отечественные СУБД уже мигрировал или находится на в финишной прямой по закрытию проекта. Остальным это просто не нужно.
Недавнее сообщения от PostgresPro о массовых сокращениях лишь подтверждают это. Проектом стало мало, а народу много. Закрыли проект, спасибо, всем пока
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
📚 Роман Севрук (К2Тех): «Рынок СУБД вышел из режима экстренного импортозамещения и переходит к проверке на зрелость»
В продолжении темы импортозамещения.
Какой-то "хрен с горы" решил порассуждать на тему импортозамещения СУБД (Простите, что-то игривое сегодня настроение). Я об этом менеджере по развитию ничего не знаю и сама компания К2Тех не то, чтобы "на слуху".
Как делается эта оценка? Меня всегда это удивляло. Как аналитики придумывают такие цифры? Загадка. Опрос по телефону? Анкетирование? В общем, цифры из головы.
Насколько мне известно общий для импортозамещения срок 1 января 2028 года! И только для некоторой категории предприятий срок продлили до 2036 года. Таких компаний, немного. Поэтому вряд компании "расслабили булки" из-за этого.
Такое ощущение, что весь западный мир уже тогда мог обрабатывать OLTP и OLAP нагрузки, а мы даже сейчас в 2026 году до сих пор этого не умеем. OracleDB больше не купить. Мир рухнул.
Oracle конечно универсальная СУБД, но далеко не все её использовали для аналитики. Это коммерческая продукт, который стоит как "самолёт". Были стандартные DWH решения в виде Greenplum, про ClickHouse не забываем, SAP, Vertica и многие другие. Мне кажется наши СЕО, CIO были вполне осведомлены о разнообразии рынка СУБД тогда и тем более сейчас.
Я соглашусь, что привлечение интеграторов к проекту миграции даст больший профит, чем попытка сделать всё силами внутренних команд. Взгляд со стороны может подсвятить то, на что вы никогда не обращали внимание, а самое главное это 100% улучшит внутреннюю документацию по системам.
Мы все пониманием, что интеграторы нужны в качестве "козлов отпущения" если что-то пойдёт не так. Классика 😊
У меня какое-то двоякое чувство. С одной стороны сейчас все требования к специалисту по СУБД свелись к знанию PostgreSQL и его экосистемы. Найти спеца не так уж и сложно, даже вырастить не проблема, т.к. обучающих материалов и курсов очень много!
С другой стороны мир СУБД огромен! Даже в РФ не все сидят на одном лишь PostgreSQL. Вырастить специалиста даже по MySQL, YDB, Tarantool, Valkey и прочим решениям очень тяжело.
В продолжении темы импортозамещения.
Какой-то "хрен с горы" решил порассуждать на тему импортозамещения СУБД (Простите, что-то игривое сегодня настроение). Я об этом менеджере по развитию ничего не знаю и сама компания К2Тех не то, чтобы "на слуху".
При этом около 70% компаний всё ещё используют решения западных производителей.
Как делается эта оценка? Меня всегда это удивляло. Как аналитики придумывают такие цифры? Загадка. Опрос по телефону? Анкетирование? В общем, цифры из головы.
Одним из драйверов рынка вы назвали импортозамещение. На ЦИПРе было заявлено, что его сроки сдвигаются до 2036 года.
Насколько мне известно общий для импортозамещения срок 1 января 2028 года! И только для некоторой категории предприятий срок продлили до 2036 года. Таких компаний, немного. Поэтому вряд компании "расслабили булки" из-за этого.
Да, действительно, после 2022 года универсальных СУБД «на все случаи жизни» на рынке не осталось. У каждого российского решения есть свои сильные стороны: одно лучше подходит для хранения, другое – для высоких нагрузок, третье – для аналитики.
Такое ощущение, что весь западный мир уже тогда мог обрабатывать OLTP и OLAP нагрузки, а мы даже сейчас в 2026 году до сих пор этого не умеем. OracleDB больше не купить. Мир рухнул.
Oracle конечно универсальная СУБД, но далеко не все её использовали для аналитики. Это коммерческая продукт, который стоит как "самолёт". Были стандартные DWH решения в виде Greenplum, про ClickHouse не забываем, SAP, Vertica и многие другие. Мне кажется наши СЕО, CIO были вполне осведомлены о разнообразии рынка СУБД тогда и тем более сейчас.
Самая большая проблема миграции сегодня уже даже не выбор конкретной СУБД. Главное — оценить влияние миграции на всю ИТ-архитектуру. Пытаться сделать всё своими силами — значит держать лишних FTE или постоянно переучивать людей. У интегратора выше насмотренность...
Я соглашусь, что привлечение интеграторов к проекту миграции даст больший профит, чем попытка сделать всё силами внутренних команд. Взгляд со стороны может подсвятить то, на что вы никогда не обращали внимание, а самое главное это 100% улучшит внутреннюю документацию по системам.
Мы все пониманием, что интеграторы нужны в качестве "козлов отпущения" если что-то пойдёт не так. Классика 😊
На рынке заметен дефицит сильных экспертов, особенно senior-уровня, способных разрабатывать и дорабатывать сами СУБД. Подготовка специалиста до уровня middle или senior занимает до трех лет
У меня какое-то двоякое чувство. С одной стороны сейчас все требования к специалисту по СУБД свелись к знанию PostgreSQL и его экосистемы. Найти спеца не так уж и сложно, даже вырастить не проблема, т.к. обучающих материалов и курсов очень много!
С другой стороны мир СУБД огромен! Даже в РФ не все сидят на одном лишь PostgreSQL. Вырастить специалиста даже по MySQL, YDB, Tarantool, Valkey и прочим решениям очень тяжело.
📚 Создатель знаменитого российского Linux купил полсотни разработчиков суверенной СУБД «Персей»
Рынок СУБД продолжает консолидацию. Еще один форк-postgres был успешно поглощен. В прошлом году Аренадата купила OrionDB у Orionsoft. Странно, что PostgresPro никого не покупает. Хотя, зачем им еще кто-то? 🤔
В общем, товарищи из Тантор Лабс наверняка счастливы до безумия! Их продукт точно будет развиваться и будут вваливаться еще больше денег в различные проекты. Еще лет 5 можно горя не знать!
Как там дела у Pangolin, Jatoba, Квант-Гибрид? Тихо пока. Может ждут чего-то? или кого-то... 😉
«Группа Астра» - разработчик Astra Linux - усиливает свой бизнес систем управления базами данных.
Компания через дочернюю «Тантор Лабс» получила:
👉 исключительные права на разработки, связанные с российской СУБД «Персей»;
👉 команду примерно из 50 инженеров, которая перейдёт из «МТ-Интеграции» и продолжит развивать продукт.
Рынок СУБД продолжает консолидацию. Еще один форк-postgres был успешно поглощен. В прошлом году Аренадата купила OrionDB у Orionsoft. Странно, что PostgresPro никого не покупает. Хотя, зачем им еще кто-то? 🤔
В общем, товарищи из Тантор Лабс наверняка счастливы до безумия! Их продукт точно будет развиваться и будут вваливаться еще больше денег в различные проекты. Еще лет 5 можно горя не знать!
Как там дела у Pangolin, Jatoba, Квант-Гибрид? Тихо пока. Может ждут чего-то? или кого-то... 😉
❤2
📚 Проблема с хранением данных в базе решена. Вот что будет дальше
В этом смысле ETL можно рассматривать как разновидность архитектурного техдолга. Долгое время мы компенсировали несовместимость систем всё более сложными конвейерами передачи данных. Теперь пора уменьшать количество посредников и развивать механизмы обмена непосредственно на уровне платформы данных.
Задел уже есть:
Хочется верить, что следующий этап развития архитектуры данных будет связан не с появлением очередного адаптера, а с постепенным исчезновением самих границ между системами 🆓.
Данные должны не переезжать из одного изолированного хранилища в другое, а свободно и безопасно становиться доступными там, где они нужны.
Добро пожаловать в светлое радужное будущее! 🌈
p.s. свежо предание, а верится с трудом (с) 😎
PostgreSQL часто остаётся основным источником операционных данных, но затем информация копируется в DWH, поисковые системы, ML-платформы и векторные базы. Каждый новый контур означает ещё один ETL/CDC-пайплайн, задержки, дублирование и риск рассинхронизации.
Поэтому будущее Postgres — не обязательно в том, чтобы заменить все специализированные СУБД. Скорее он должен стать центром экосистемы данных: надёжным system of record с удобной репликацией, доступом к внешним источникам и расширениями для аналитики и ИИ.
В этом смысле ETL можно рассматривать как разновидность архитектурного техдолга. Долгое время мы компенсировали несовместимость систем всё более сложными конвейерами передачи данных. Теперь пора уменьшать количество посредников и развивать механизмы обмена непосредственно на уровне платформы данных.
Задел уже есть:
logical replication, CDC, foreign data wrappers, расширения и открытые форматы хранения. Но пока это скорее отдельные строительные блоки, чем единая модель взаимодействия.Хочется верить, что следующий этап развития архитектуры данных будет связан не с появлением очередного адаптера, а с постепенным исчезновением самих границ между системами 🆓.
Данные должны не переезжать из одного изолированного хранилища в другое, а свободно и безопасно становиться доступными там, где они нужны.
Добро пожаловать в светлое радужное будущее! 🌈
p.s. свежо предание, а верится с трудом (с) 😎
The New Stack
The database storage problem is solved. Here’s what comes next.
Postgres is evolving from a system of record into a hub for data movement. Here's how interoperability and AI are reshaping its future.
❤1
🎦 Unlocked Conference, часть 1. Кеш ускоряет систему, а потом случается это...
На youtube вышли в публичный доступ видео с конференции Unlocked Conference от сообщества Valkey. Думаю стоит их разобрать.
Я не буду обозревать каждое видео в отдельности. Это долго и скучно. Поэтому просто выскажу здесь несколько "умных мыслей", которые меня зацепили.
Главный вывод можно сформулировать такой:
Несколько забавных историй:
🔹 100% CPU не всегда означает 100% загрузки.
В Valkey часть CPU могла уходить на busy polling. Метрики показывали полное насыщение уже при 300 тыс. QPS, хотя узел был способен обработать почти вдвое больше.
🔹 Отличный SLO может скрывать полный отказ клиента.
У Valkey средняя доступность по всему парку была прекрасной. Но отдельная partition могла лежать на 100%, полностью ломая workflow конкретного клиента. Средняя температура по дата-центру снова победила реальность.
🔹 Fail fast иногда означает fail catastrophically.
Одна неисправная нода очень быстро возвращала код
🔹 Retry может пережить причину аварии.
Нагрузка вызвала ошибки, ошибки породили retries, а retries удержали систему выше capacity. Исходный spike уже закончился, но система продолжала гореть самостоятельно 🔥.
Production обычно ломается не при нормальной эксплуатации, а во время переходов - failover, resharding, cache flush, восстановления соединений и массового запуска клиентов. Поэтому проверять нужно не только максимальный QPS.
Нужно проверять, умеет ли система вернуться в норму после того, как всё пошло не по плану.
На мой взгляд один из самых больнючих кейсов. Проблема ушла, а система не смогла восстановиться. Только всемогущий 💪 рестарт помог оживить prod. Мне кажется это одна их самых популярных проблем всех распределенных систем. В продолжении...
🔹 В биллинге кеш способен материализовать деньги из воздуха.
Независимая запись в основную БД и Redis привела к cache drift, двойным списаниям и неправильным балансам. Для финансовых данных кеш не может быть вторым источником истины.
Добавить Redis как кэширующий слой - это стандартный паттерн. Это частая практика. Вопрос, как данные синхронизировать между основной БД и кешем?
Самый очевидный вариант, это делать запись в БД и кеш в одной транзакции. А что если это невозможно? То как быть?
Предлагайте варианты 😎
На youtube вышли в публичный доступ видео с конференции Unlocked Conference от сообщества Valkey. Думаю стоит их разобрать.
Я не буду обозревать каждое видео в отдельности. Это долго и скучно. Поэтому просто выскажу здесь несколько "умных мыслей", которые меня зацепили.
Главный вывод можно сформулировать такой:
Кэш - это не ускоритель базы данных. Это ещё одна распределённая система со своими способами сломать ваш прод 😁
Несколько забавных историй:
В Valkey часть CPU могла уходить на busy polling. Метрики показывали полное насыщение уже при 300 тыс. QPS, хотя узел был способен обработать почти вдвое больше.
У Valkey средняя доступность по всему парку была прекрасной. Но отдельная partition могла лежать на 100%, полностью ломая workflow конкретного клиента. Средняя температура по дата-центру снова победила реальность.
Одна неисправная нода очень быстро возвращала код
500. Алгоритм least-connections балансировщика решил, что она самая свободная, и направил на неё ещё больше запросов. Чем быстрее нода падала, тем больше трафика получала. Идеальная производительность, просто результат немного не тот. "Чутулю" совсем 😜Нагрузка вызвала ошибки, ошибки породили retries, а retries удержали систему выше capacity. Исходный spike уже закончился, но система продолжала гореть самостоятельно 🔥.
Production обычно ломается не при нормальной эксплуатации, а во время переходов - failover, resharding, cache flush, восстановления соединений и массового запуска клиентов. Поэтому проверять нужно не только максимальный QPS.
Нужно проверять, умеет ли система вернуться в норму после того, как всё пошло не по плану.
На мой взгляд один из самых больнючих кейсов. Проблема ушла, а система не смогла восстановиться. Только всемогущий 💪 рестарт помог оживить prod. Мне кажется это одна их самых популярных проблем всех распределенных систем. В продолжении...
Независимая запись в основную БД и Redis привела к cache drift, двойным списаниям и неправильным балансам. Для финансовых данных кеш не может быть вторым источником истины.
Добавить Redis как кэширующий слой - это стандартный паттерн. Это частая практика. Вопрос, как данные синхронизировать между основной БД и кешем?
Самый очевидный вариант, это делать запись в БД и кеш в одной транзакции. А что если это невозможно? То как быть?
Предлагайте варианты 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Unlocked Conference
Unlocked 2026 | Valkey Conference | May 7, Seattle
Learn how to build robust and scalable systems from industry leaders like Amazon, Apple, Google, Momento, Netflix, Snap and Uber!
❤4🤪1
🎦 Unlocked Conference, часть 2. Почему Valkey должен стать скучным 🥱
Самое важное слово на конференции про высокопроизводительный кеш неожиданно было не про
В инженерном смысле скучная система - это система, которая не преподносит сюрпризов в три часа ночи.
Что для этого делают в Valkey и вокруг него?
🔹 Превращают клиента в полноценную часть распределённой системы.
Production-grade клиент должен переживать failover, resharding,
Клиент Valkey - это не просто библиотека с командами
🔹 Убирают зависимость от
Фича Valkey 10. Forkless Save снижает риск стартовых пауз и почти двукратного роста памяти из-за Copy-on-Write. Правда, цена переносится в latency некоторых записей.
Некий обмен. Меньше требований к RAM - больше внимания к write latency.
Забавно, что Amazon эту фичу у себя сделали еще в 2020 году!😱 Спустя 6 лет AWS расщедрились и заопенсорсили её. Нууууу, спасибо конечно. Но какое-то неприятное чувство внутри осталось. Могли бы и раньше озаботиться ☹️
🔹 Netflix предлагает версионировать данные как код.
Новая версия кеша заранее строится, проверяется и затем атомарно включается. При проблемах - быстрый rollback. Никакого постепенного заполнения, частично обновлённого состояния и философских дискуссий о том, кто опять забыл инвалидировать кеш.
Интересная проприетарная фича. Доклад был короткий, поэтому оценить всю её пользу сложновато. Хотя задумка интересная 🧐.
🔹 Reddit экономит память не закупкой новых серверов, а моделью данных.
Hash field expiration позволил сократить один кластер с 44 до 25 Тбайт памяти. А Cuckoo filter помог отсеять запросы к заведомо отсутствующим ключам. Потому что самый быстрый и дешёвый запрос к Valkey это тот, который не пришлось отправлять 😊
🔹 Valkey становится частью AI-инфраструктуры.
Semantic cache может повторно использовать ответы LLM для похожих запросов. Но слишком мягкий similarity threshold способен вернуть Париж как столицу Германии.
TTL отвечает за временную актуальность. Threshold - за смысловую. Ошибиться можно по обеим координатам.
Общий вектор конференции такой:
Максимальный QPS хорошо выглядит на слайде.
Но настоящая зрелость начинается там, где resharding, restart или сетевой сбой перестают быть событием для всей компании.
Нас ждёт утопичное будущее 🤤 Но это не точно 🫠
Самое важное слово на конференции про высокопроизводительный кеш неожиданно было не про
performance. Это было слово boring .В инженерном смысле скучная система - это система, которая не преподносит сюрпризов в три часа ночи.
Что для этого делают в Valkey и вокруг него?
Production-grade клиент должен переживать failover, resharding,
MOVED, сетевые сбои и изменение топологии. А ещё - не устраивать retry storm, использовать backoff, jitter и circuit breaker.Клиент Valkey - это не просто библиотека с командами
GET и SET. Иногда это последняя линия обороны между небольшим сбоем и большим инцидентом.fork() при сохранении данных.Фича Valkey 10. Forkless Save снижает риск стартовых пауз и почти двукратного роста памяти из-за Copy-on-Write. Правда, цена переносится в latency некоторых записей.
Некий обмен. Меньше требований к RAM - больше внимания к write latency.
Забавно, что Amazon эту фичу у себя сделали еще в 2020 году!😱 Спустя 6 лет AWS расщедрились и заопенсорсили её. Нууууу, спасибо конечно. Но какое-то неприятное чувство внутри осталось. Могли бы и раньше озаботиться ☹️
Новая версия кеша заранее строится, проверяется и затем атомарно включается. При проблемах - быстрый rollback. Никакого постепенного заполнения, частично обновлённого состояния и философских дискуссий о том, кто опять забыл инвалидировать кеш.
Интересная проприетарная фича. Доклад был короткий, поэтому оценить всю её пользу сложновато. Хотя задумка интересная 🧐.
Hash field expiration позволил сократить один кластер с 44 до 25 Тбайт памяти. А Cuckoo filter помог отсеять запросы к заведомо отсутствующим ключам. Потому что самый быстрый и дешёвый запрос к Valkey это тот, который не пришлось отправлять 😊
Semantic cache может повторно использовать ответы LLM для похожих запросов. Но слишком мягкий similarity threshold способен вернуть Париж как столицу Германии.
TTL отвечает за временную актуальность. Threshold - за смысловую. Ошибиться можно по обеим координатам.
Общий вектор конференции такой:
Valkey развивается не как "Redis с ещё большим количеством функций", а как открытая и предсказуемая инфраструктурная платформа.
Максимальный QPS хорошо выглядит на слайде.
Но настоящая зрелость начинается там, где resharding, restart или сетевой сбой перестают быть событием для всей компании.
Нас ждёт утопичное будущее 🤤 Но это не точно 🫠
Please open Telegram to view this post
VIEW IN TELEGRAM
Unlocked Conference
Unlocked 2026 | Valkey Conference | May 7, Seattle
Learn how to build robust and scalable systems from industry leaders like Amazon, Apple, Google, Momento, Netflix, Snap and Uber!
❤4👍1
🎦 Давным давно, аж 23 июня прошел Data.Митап от Сбера
Было три доклада:
Хотел туда лично прийти, но это был конец июня. У меня защиты ВКР были расписаны на каждый день с 15 числа до 27 числа. Не смог 😞
Посмотрел доклады в записи. В целом, вроде всё интересно, но ничего такого важно для себя не вынес. Если нет слайда с выводами, то тяжело вычленить что-то важно из моноголога автора 🥲.
Отмечу последний доклад. Про оптимизаторы запросов. Очень глубокий доклад с математической теорией. Автор молодец👍. Презентация крутая. Я далек от алгоритмов и тер-вера в целом, но разработчикам оптимизаторов будет крайне полезно. Если вы этим занимаетесь, то гляньте👀.
Было три доклада:
👉 17:40 - PostgreOnRocks: как превратить PostgreSQL в облачную базу данных на RocksDB и S3
👉 18:10 - Multi-DC кластер DataGrid с синхронной репликацией и сниженным TCO
👉 18:40 - Генетика или игры: новый алгоритм для оптимизации запросов в реляционных СУБД
Хотел туда лично прийти, но это был конец июня. У меня защиты ВКР были расписаны на каждый день с 15 числа до 27 числа. Не смог 😞
Посмотрел доклады в записи. В целом, вроде всё интересно, но ничего такого важно для себя не вынес. Если нет слайда с выводами, то тяжело вычленить что-то важно из моноголога автора 🥲.
Нашли проблему, затем разработали решение - получили профит. Конец 😊
Отмечу последний доклад. Про оптимизаторы запросов. Очень глубокий доклад с математической теорией. Автор молодец👍. Презентация крутая. Я далек от алгоритмов и тер-вера в целом, но разработчикам оптимизаторов будет крайне полезно. Если вы этим занимаетесь, то гляньте👀.
👍1
📚 Как мы работаем со студентами: дипломы, которые становятся частью 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