📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».
Поговорим про Часть 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 - возвращать подготовленные данные из хранилища обратно в операционные системы, чтобы данные реально работали "в поле". Очень хочется посмотреть на такой процесс в продакшн среде. Жаль, что сейчас я немного далек от этого.
Реальность как всегда иная 🧪. Исходя из моего опыта, заказчику всегда нужно всё и без ограничений и за недорого. Поэтому запускается процесс гибридизации ежа🦔, ужа🐍 и прочих зверят🦈🐗🦜. В итоге получается "платформа данных", которая уникальна для каждого заказчика 🌈.
Занавес
Поговорим про Часть 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 и понимает цену изменений.
Сегодня про Часть 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 и понимает цену изменений.
🔥3
📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».
Наконец-то финальная 😮💨 Часть 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 уже не про то, чтобы "выбрать технологии и жить счастливо" 👨👨👦👦. Это про то, чтобы делать платформу как продукт. С пользователями, приоритетами и бесконечными правками 🛞.
Люди и процессы задают направление. Технологии просто помогают ехать быстрее 🏎. Или красиво буксовать 🚜.
А потом приходит реальность и тихо шепчет заклинание 🪄
И в вашем озере данных 🏖 заводятся единороги 🦄, а в бэклоге начинает шевелиться химера из ежа 🦔 и ужа 🐍.
Наконец-то финальная 😮💨 Часть 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 уже не про то, чтобы "выбрать технологии и жить счастливо" 👨👨👦👦. Это про то, чтобы делать платформу как продукт. С пользователями, приоритетами и бесконечными правками 🛞.
Люди и процессы задают направление. Технологии просто помогают ехать быстрее 🏎. Или красиво буксовать 🚜.
А потом приходит реальность и тихо шепчет заклинание 🪄
“Хочу всё. Без ограничений. И за недорого”.
И в вашем озере данных 🏖 заводятся единороги 🦄, а в бэклоге начинает шевелиться химера из ежа 🦔 и ужа 🐍.
🔥1
Сейчас отсматриваю видео с прошедшей на этой неделе конференции Monster SCALE Summit.
К сожалению, не получилось посмотреть её в онлайне, т.к. у меня были лекции в ВУЗах. Поэтому смотрю сейчас 👀.
В одном из выступлений мне безумно понравилась фраза спикера:
Вольный перевод:
Думаю, как круто звучит 🔥! Обязательно надо взять её на вооружение 😎 . Ждите этой отсылки на моих лекциях 😏
К сожалению, не получилось посмотреть её в онлайне, т.к. у меня были лекции в ВУЗах. Поэтому смотрю сейчас 👀.
В одном из выступлений мне безумно понравилась фраза спикера:
Those who would trade safety for performance, deserve neither safety nor performance.
Вольный перевод:
Те, кто выбирают между безопасностью и производительностью не заслуживаются ни того, ни другого.
Думаю, как круто звучит 🔥! Обязательно надо взять её на вооружение 😎 . Ждите этой отсылки на моих лекциях 😏
❤1
Пару слов про формат Monster SCALE Summit.
Это онлайн-конференция.
❇️Идея
👉 Организаторы собрали программу на 2 дня.
👉 Затем записали ВСЕ выступления на видео.
👉 Сделали по каждому видео рекламный short (клип).
👉 За неделю до старта выложили все шортсы на youtube канале. 👉 Во время конференции на платформе согласно графику открывали доступ к видео.
👉 Все зрители смотрели записанное заранее выступление! Далее в чате вели обсуждение доклада и задавали какие-то вопросы спикеру (если тот о был чате).
Согласитесь, формат крайне необычный! Я в прошлом году не придал этому значения, а в этом бросилось в глаза. Мне кажется такой формат довольно неплох.
Это онлайн-конференция.
❇️Идея
👉 Организаторы собрали программу на 2 дня.
👉 Затем записали ВСЕ выступления на видео.
👉 Сделали по каждому видео рекламный short (клип).
👉 За неделю до старта выложили все шортсы на youtube канале. 👉 Во время конференции на платформе согласно графику открывали доступ к видео.
👉 Все зрители смотрели записанное заранее выступление! Далее в чате вели обсуждение доклада и задавали какие-то вопросы спикеру (если тот о был чате).
Согласитесь, формат крайне необычный! Я в прошлом году не придал этому значения, а в этом бросилось в глаза. Мне кажется такой формат довольно неплох.
ScyllaDB
Monster Scale Summit On Demand
Monster Scale Summit Extreme scale engineering Discover the latest trends and best practices impacting data-intensive applications. Register for access to all 60+ sessions available on demand. Featured Sessions All Sessions
👍1
📚 Прочитал статью «Why Redis Feels Weird...» и поймал себя на мысли, что автор специально не указал версию Redis, а ведь с выходом 8-ки кое-какие выводы стоит изменить.
Главный посыл :
Если вы "свалили данные в кучу" 🚮 и надеетесь, что потом каким-нибудь запросом данные найдутся и "склеются", то расслабьтесь, не получится 😏. В Redis по-прежнему вы сами отвечаете за пути доступа, консистентность и ищите компромиссы между скорость чтения и ценой записи.
Автор описывает Redis как спартанское хранилище 🏠, где каждый индекс нужно вытачивать вручную из SET и ZSET. С выходом Redis 8 (и окончательной интеграцией Redis Stack в ядро) эта "боль" стала опциональной:
👉 Ручные индексы vs Search. Зачем вручную поддерживать ключ idx:user:email, если можно один раз создать индекс через FT.CREATE? Redis 8 сам просканирует ваши JSON-д1окументы и обеспечит адекватную скорость поиска 🕯.
👉 Hashes vs JSON. Автор топит за хэши, называя JSON «неудобным блобом». Но с нативным RedisJSON это больше не так. Мы можем атомарно менять одно поле глубоко внутри документа. Это удобнее, гибче и довольно быстро. Хотя признаю, тестов я не видел и сам не делал.
В итоге, эта статья отличная прививка от "реляционного мышления", но воспринимать её как руководство к действию в 2026-м не стоит. Современный Redis стал гораздо "человечнее"🤖👨🏻🦳.
Раньше нам говорили:
Redis 8 говорит:
Для понимания основ, сгодится. Но в коде используйте возможности 8-й версии, чтобы не превращать проект в кладбище вспомогательных ключей 💪
Главный посыл :
"сначала думай о запросах, потом о данных".
Если вы "свалили данные в кучу" 🚮 и надеетесь, что потом каким-нибудь запросом данные найдутся и "склеются", то расслабьтесь, не получится 😏. В Redis по-прежнему вы сами отвечаете за пути доступа, консистентность и ищите компромиссы между скорость чтения и ценой записи.
Автор описывает Redis как спартанское хранилище 🏠, где каждый индекс нужно вытачивать вручную из SET и ZSET. С выходом Redis 8 (и окончательной интеграцией Redis Stack в ядро) эта "боль" стала опциональной:
👉 Ручные индексы vs Search. Зачем вручную поддерживать ключ idx:user:email, если можно один раз создать индекс через FT.CREATE? Redis 8 сам просканирует ваши JSON-д1окументы и обеспечит адекватную скорость поиска 🕯.
👉 Hashes vs JSON. Автор топит за хэши, называя JSON «неудобным блобом». Но с нативным RedisJSON это больше не так. Мы можем атомарно менять одно поле глубоко внутри документа. Это удобнее, гибче и довольно быстро. Хотя признаю, тестов я не видел и сам не делал.
В итоге, эта статья отличная прививка от "реляционного мышления", но воспринимать её как руководство к действию в 2026-м не стоит. Современный Redis стал гораздо "человечнее"🤖👨🏻🦳.
Раньше нам говорили:
«Забудьте про таблицы и страдайте, создавая связи вручную».
Redis 8 говорит:
«Забудьте про таблицы, но используйте наши встроенные инструменты поиска и документов, чтобы не изобретать велосипед».
Для понимания основ, сгодится. Но в коде используйте возможности 8-й версии, чтобы не превращать проект в кладбище вспомогательных ключей 💪
Medium
Why Redis Feels Weird (Until You Stop Thinking in Tables)
Redis is one of those tools that feels easy right up until it doesn’t. You set a few keys, everything is fast, and for a while it seems…
❤2
16 марта в свой День Рождения решил поделиться одной личной историей.
🎮 Как я уходил из мобильного гейминга на 5 лет и что нашел, вернувшись.
Я геймер со стажем 😎. Мой путь начался с 8-ми битных пикселей на Dendy, далее была Sega, ПК, ноутбуки, планшеты и дошел до современных смартфонов.
В мобильные игры я втянулся где-то в 2011 году. Причина была простой до банальности, эпидемия на работе. Все играли - и я играл. Популяризация планшетов, всеобщий фанатизм от продуктов Apple, "злые птицы". Эх, была эпоха 😅
В какой-то момент (году в 2020-м) я забросил мобильный гейминг.
И вот, буквально недавно, из чистого любопытства решил скачать одну популярную мобильную стратегию. Просто хотел посмотреть, как далеко шагнул прогресс "донатных помоек". И, честно говоря, я был очень, ну просто очень удивлен👀. Технический прогресс за эти годы сделал огромный скачок 🦶. Начнем по порядку.
🛑Мой личный «Black List»: почему я уходил
👉 Фиаско с лутбоксами. Однажды я влил в проект около 40к рублей (ползарплаты на тот момент!). Хотел буста, а получил... ничего. Великий Рандом показал мне фигу, и в тот же день игра была удалена навсегда.
👉 Работа во вторую смену. Ивенты требовали заходить в игру каждый час на 5 минут. Это не геймплей, это какой-то дежурный график на минималках, сжирающий все «человеческие ресурсы». Бывало даже по ночам приходилось лазить в планшет 😰
👉Разработчики-джуны. Помню, как мы с моей ТОП-гильдией находили баги в каждом обновлении! В каждом 🤯! Мы буквально ломали экономику ивентов. По началу было забавно, но потом стало раздражать. Раз, два, три облажались, ладно. Но когда это длится год, то становится грустно.
👉 Скриптовое бессилие. Последней каплей стали боты-автофармлеры. Я фармил ресурсы сутками, а сосед по альянсу просто включил скрипт на ночь и обогнал меня за неделю! Обида за потраченное время была такой сильной, что я завязал с мобилками. Нет смысла тратить реальное время.
🔮Пять лет спустя или добро пожаловать в будущее
Скачав свежую стратегию, я ожидал увидеть те же костыли, но обнаружил мощный инженерный скачок. Вот что меня зацепило:
✅ Автопереводчик в чате. Это просто магия. Больше не нужно гуглить, что там кричит на турецком ваш противник/союзник. Одна кнопка - и вы понимаете друг друга. Уровень интеграции такой, что языковой барьер просто исчез.
✅ Четкий Roadmap на 100 дней. Больше никаких ожиданий и догадок, а что нас ждет в игре дальше? Прямо в игре висит календарь обновлений. Не только список эвентов, но и прочие изменения. Полная прозрачность.
✅Data-driven альянсов и API. Раньше я вел учет активности игроков в монструозных Excel-таблицах. Сейчас для оперативной аналитики вся инфа есть в UI. Более того, некоторые разработчики дают API! Можно выгружать историю действий, строить графики и анализировать эффективность каждого игрока или альянса. Игра превращается в прикольный BI-проект.
✅Античит-терапия. Увидеть, как система банит 10 человек из альянса за скрипты весьма прикольно 🫣. Особенно забавляет их нытье: «А за что? Это же просто донатка, а не CS!». Спасибо разработчикам, теперь тратить время (и деньги) не так обидно, когда знаешь, что правила одни для всех.
✅UX/UI здорового человека. Интерфейсы стали более богатыми, но иконки с донатом чуть подбешивают. Видно, что в штат наконец-то наняли нормальных дизайнеров. Но признаю, что какой-то пользовательской документации мне не хватает 📘 Я бы почитал
🛋 Итог: что там под капотом?🖥
Мобильные игры превратились в сложнейшие высоконагруженные системы. Как человеку, который преподает базы данных, мне безумно интересно:
❓Как они держат консистентность в ивентах «сервер против сервера» при такой нагрузке?
❓Что там за база данных: шардированный SQL, что-то из NoSQL-стека типа Valkey или вообще свои велосипеды?
❓Как организован Disaster Recovery? Если у них упадет база во время финала сезона, через сколько минут они поднимут бэкап и не случится ли «откат» на миллионы долларов?
В общем, снимаю шляпу🎩 . Нужно срочно выбираться на технические конференции геймдев-компаний. Очень хочется узнать как всё устроено "изнутри".
Я геймер со стажем 😎. Мой путь начался с 8-ми битных пикселей на Dendy, далее была Sega, ПК, ноутбуки, планшеты и дошел до современных смартфонов.
В мобильные игры я втянулся где-то в 2011 году. Причина была простой до банальности, эпидемия на работе. Все играли - и я играл. Популяризация планшетов, всеобщий фанатизм от продуктов Apple, "злые птицы". Эх, была эпоха 😅
В какой-то момент (году в 2020-м) я забросил мобильный гейминг.
И вот, буквально недавно, из чистого любопытства решил скачать одну популярную мобильную стратегию. Просто хотел посмотреть, как далеко шагнул прогресс "донатных помоек". И, честно говоря, я был очень, ну просто очень удивлен👀. Технический прогресс за эти годы сделал огромный скачок 🦶. Начнем по порядку.
🛑Мой личный «Black List»: почему я уходил
👉 Фиаско с лутбоксами. Однажды я влил в проект около 40к рублей (ползарплаты на тот момент!). Хотел буста, а получил... ничего. Великий Рандом показал мне фигу, и в тот же день игра была удалена навсегда.
👉 Работа во вторую смену. Ивенты требовали заходить в игру каждый час на 5 минут. Это не геймплей, это какой-то дежурный график на минималках, сжирающий все «человеческие ресурсы». Бывало даже по ночам приходилось лазить в планшет 😰
👉Разработчики-джуны. Помню, как мы с моей ТОП-гильдией находили баги в каждом обновлении! В каждом 🤯! Мы буквально ломали экономику ивентов. По началу было забавно, но потом стало раздражать. Раз, два, три облажались, ладно. Но когда это длится год, то становится грустно.
👉 Скриптовое бессилие. Последней каплей стали боты-автофармлеры. Я фармил ресурсы сутками, а сосед по альянсу просто включил скрипт на ночь и обогнал меня за неделю! Обида за потраченное время была такой сильной, что я завязал с мобилками. Нет смысла тратить реальное время.
🔮Пять лет спустя или добро пожаловать в будущее
Скачав свежую стратегию, я ожидал увидеть те же костыли, но обнаружил мощный инженерный скачок. Вот что меня зацепило:
✅ Автопереводчик в чате. Это просто магия. Больше не нужно гуглить, что там кричит на турецком ваш противник/союзник. Одна кнопка - и вы понимаете друг друга. Уровень интеграции такой, что языковой барьер просто исчез.
✅ Четкий Roadmap на 100 дней. Больше никаких ожиданий и догадок, а что нас ждет в игре дальше? Прямо в игре висит календарь обновлений. Не только список эвентов, но и прочие изменения. Полная прозрачность.
✅Data-driven альянсов и API. Раньше я вел учет активности игроков в монструозных Excel-таблицах. Сейчас для оперативной аналитики вся инфа есть в UI. Более того, некоторые разработчики дают API! Можно выгружать историю действий, строить графики и анализировать эффективность каждого игрока или альянса. Игра превращается в прикольный BI-проект.
✅Античит-терапия. Увидеть, как система банит 10 человек из альянса за скрипты весьма прикольно 🫣. Особенно забавляет их нытье: «А за что? Это же просто донатка, а не CS!». Спасибо разработчикам, теперь тратить время (и деньги) не так обидно, когда знаешь, что правила одни для всех.
✅UX/UI здорового человека. Интерфейсы стали более богатыми, но иконки с донатом чуть подбешивают. Видно, что в штат наконец-то наняли нормальных дизайнеров. Но признаю, что какой-то пользовательской документации мне не хватает 📘 Я бы почитал
🛋 Итог: что там под капотом?
Мобильные игры превратились в сложнейшие высоконагруженные системы. Как человеку, который преподает базы данных, мне безумно интересно:
❓Как они держат консистентность в ивентах «сервер против сервера» при такой нагрузке?
❓Что там за база данных: шардированный SQL, что-то из NoSQL-стека типа Valkey или вообще свои велосипеды?
❓Как организован Disaster Recovery? Если у них упадет база во время финала сезона, через сколько минут они поднимут бэкап и не случится ли «откат» на миллионы долларов?
В общем, снимаю шляпу
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉6🔥5❤3🤔1
📚 Эволюция PostgreSQL-хранилища размещений в Авито
Я долго думал стоит ли писать что-то про эту статью и всё-таки решил её "подсветить"💡 . Она довольно старая, от 5 февраля, но написана хорошо и интересно.
Описать данную работу можно так: это полезная статья для тех, кто работает с большими проектами. Она честно показывает на примере Авито, что даже простые вещи (вроде удаления записей из базы) перестают работать, когда данных становится очень много, и учит, что проблемы нужно решать не костылями, а переделывая архитектуру с учётом будущего роста.
Я сам работал с подобной базой и наблюдал её рост со 100 МБ до 4 ТБ. Мы как раз подходили к идеи партиционирования данных, но...банк схлопнулся 💸. Рост базы данных закончился вместе с ним.
Хочу обратить внимание, что статья в целом, неплохая, но почему-то на ней всего 20 лайков и 3 коммента. Такое ощущение, что никому это не интересно 🤷♂️
Я долго думал стоит ли писать что-то про эту статью и всё-таки решил её "подсветить"
Описать данную работу можно так: это полезная статья для тех, кто работает с большими проектами. Она честно показывает на примере Авито, что даже простые вещи (вроде удаления записей из базы) перестают работать, когда данных становится очень много, и учит, что проблемы нужно решать не костылями, а переделывая архитектуру с учётом будущего роста.
Я сам работал с подобной базой и наблюдал её рост со 100 МБ до 4 ТБ. Мы как раз подходили к идеи партиционирования данных, но...банк схлопнулся 💸. Рост базы данных закончился вместе с ним.
Хочу обратить внимание, что статья в целом, неплохая, но почему-то на ней всего 20 лайков и 3 коммента. Такое ощущение, что никому это не интересно 🤷♂️
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Эволюция PostgreSQL-хранилища размещений в Авито
Что делать, если сервис, который вырос из транзакции в монолите, за несколько лет стал входной точкой во все размещения на Авито? Когда через PostgreSQL проходят миллионы объявлений в день, привычные...
Forwarded from commit -m "better"
https://jepsen.io/analyses/mariadb-galera-cluster-12.1.2
TL;DR - Кайл Кингсбери из Jepsen в очередной раз знатно напихал хуев за щеку вендорам.
(Вообще, у него есть какие-то измерения, которые не находили тех или иных проблем в исследуемых базах данных? Не помню таких)
В этот раз под раздачу попал MariaDB Galera Cluster. В документации нам рассказывают про "instantly replicated, no lost transactions" и уровень изоляции "между Serializable и Repeatable Read".
По факту же, с их собственными рекомендованными настройками, кластер тупо и безвозвратно теряет закоммиченные транзакции при одновременном краше нод, или сетевых партишенах.
Более того, эта всратая поделка допускает Lost Update и Stale Read даже в абсолютно здоровом кластере без сбоев, по факту давая гарантии хуже, чем Read Uncommitted!
Удивительно, как люди в здравом уме продолжают тащить такое в прод, просто начитавшись документации. В копилочку того, почему верить нельзя никому, а маркетологам баз данных - особенно.
TL;DR - Кайл Кингсбери из Jepsen в очередной раз знатно напихал хуев за щеку вендорам.
(Вообще, у него есть какие-то измерения, которые не находили тех или иных проблем в исследуемых базах данных? Не помню таких)
В этот раз под раздачу попал MariaDB Galera Cluster. В документации нам рассказывают про "instantly replicated, no lost transactions" и уровень изоляции "между Serializable и Repeatable Read".
По факту же, с их собственными рекомендованными настройками, кластер тупо и безвозвратно теряет закоммиченные транзакции при одновременном краше нод, или сетевых партишенах.
Более того, эта всратая поделка допускает Lost Update и Stale Read даже в абсолютно здоровом кластере без сбоев, по факту давая гарантии хуже, чем Read Uncommitted!
Удивительно, как люди в здравом уме продолжают тащить такое в прод, просто начитавшись документации. В копилочку того, почему верить нельзя никому, а маркетологам баз данных - особенно.
😱6
📚 TiDB and the rise of the AI-native database
Очень прикольная статья от разработчика TiDB из компании PingCAP.
🔧 Суть: В современном мире главным преимуществом является не модели ИИ, а инфраструктура данных, которая работает с ними.
Тезисы:
1️⃣ Смена главного пользователя БД. Если раньше базы данных проектировались для людей (разработчиков, аналитиков), то теперь их основными пользователями становятся автономные AI-агенты. Они создают, используют и удаляют базы данных без участия человека, в огромных количествах.
2️⃣ Классические СУБД (вроде MySQL или PostgreSQL) не справляются с новыми нагрузками, потому что они не рассчитаны на:
➖ Миллионы короткоживущих экземпляров баз данных.
➖ Огромный объем служебных данных (метаданных) при малом объеме полезных.
➖ Экономическую неэффективность (платить $5 за базу, которая живет несколько минут, скажем так, нецелесообразно).
3️⃣ TiDB теперь я позиционирует как «AI-нативная» базы данных:
➖ Архитектура: Используется подход виртуализированного слоя данных с мультиарендностью (multi-tenancy). Физическая инфраструктура общая, а логические базы данных для агентов изолированы, создаются и удаляются мгновенно. Архитектура TiDB позволяет эффективно работать с миллионами мелких «логических» баз данных.
➖ Новая модель ценообразования. Автор описывает пример сотрудничества с платформой Manus, где пришлось отказаться от оплаты за инстанс. Вместо этого была внедрена модель оплаты за совокупное потребление ресурсов (usage-based), так как более 90% баз данных создавалось агентами для одной задачи.
Несмотря на популярность новых технологий, авторы уверены, что SQL останется основным языком для взаимодействия ИИ с данными из-за его надежности и универсальности.
🔮Будущее: База данных становится "невидимой" инфраструктурой, работающей "под капотом" у AI-агентов, которые выполняют сложные запросы пользователей (например, создание сайта по голосовой команде). Ключевая стратегия для эпохи ИИ - хранить все данные и делать их доступными для машин с максимальной скоростью.
Очень прикольная статья от разработчика TiDB из компании PingCAP.
Тезисы:
Несмотря на популярность новых технологий, авторы уверены, что SQL останется основным языком для взаимодействия ИИ с данными из-за его надежности и универсальности.
🔮Будущее: База данных становится "невидимой" инфраструктурой, работающей "под капотом" у AI-агентов, которые выполняют сложные запросы пользователей (например, создание сайта по голосовой команде). Ключевая стратегия для эпохи ИИ - хранить все данные и делать их доступными для машин с максимальной скоростью.
Please open Telegram to view this post
VIEW IN TELEGRAM
The New Stack
TiDB and the rise of the AI-native database
Data infrastructure, not models, is the AI edge. Learn how TiDB’s AI-native database powers millions of agents at machine speed.
👍2
Сегодня стартовал PG BootCamp Russia 2026.
Ссылка на онлайн-трансляцию.
К сожалению, не смог сегодня прийти туда очно "по семейным обстоятельствам".
Буду смотреть онлайн.
По поводу картинки. Очень иронично, что на мероприятии по PostgreSQL выступает контребьютер PostgreSQL в футболке YDB.
Ссылка на онлайн-трансляцию.
К сожалению, не смог сегодня прийти туда очно "по семейным обстоятельствам".
Буду смотреть онлайн.
По поводу картинки. Очень иронично, что на мероприятии по PostgreSQL выступает контребьютер PostgreSQL в футболке YDB.
😁6
📚 SurrealDB привлекает $23 млн для расширения своей AI-native многомодельной базы данных
Тут примечательно, что SurrealDB тоже себя позиционирует как AI-native СУБД. Видимо это новый тренд в эволюции баз данных. Тренд 2026 года.
Из интересного 🤔, SurrealDB - это масштабируемая, распределенная документно-графовая СУБД 📃➖ 📇 . Да, да, это не реляционная база как TiDB. Что-то необычное 😳
Мне кажется, что SurrealDB является конкурентом MongoDB. По крайней мере складывается такое ощущение исходя из описания.
Еще один тезис в сторону конкуренции с MongoDB в том, что в SurrealDB нет SQL, там свой язык SurrealQL.
SurrealDB - написана на Rust🦀 .
Короче, разработчики выполнили план и получили премию. Я так понял это утверждение 🤔 💰
Вдогонку, чтобы не делить посты следующая статья: Тесты производительности SurrealDB 3.0
Она написана одним из разработчиков SurrealDB. В ней он привёл результаты тестирования СУБД, который они проводили своим собственным бенчмарком crud-bench.
Я даже не знаю, что тут сказать. Всё равно, что я спроектировал автомобиль и по моим тестам он круче BMW в 100 раз 😎. Доверять этим цифрам смысла нет. Это как компания Nvidea показывает рост производительности своих карт на основе своих бенчмарков.
В очередной раз скажу, что без привлечения независимых RnD центров для проведения тестирования доверять цифрам в отчете бессмысленно.
17 февраля SurrealDB Inc объявила о привлечении дополнительных инвестиций в размере 23 миллионов баксов. Вот это начало года! Конено не 400 млн как ClickHouse, но всё равно сумма приличная.
Тут примечательно, что SurrealDB тоже себя позиционирует как AI-native СУБД. Видимо это новый тренд в эволюции баз данных. Тренд 2026 года.
Из интересного 🤔, SurrealDB - это масштабируемая, распределенная документно-графовая СУБД 📃
Мне кажется, что SurrealDB является конкурентом MongoDB. По крайней мере складывается такое ощущение исходя из описания.
Еще один тезис в сторону конкуренции с MongoDB в том, что в SurrealDB нет SQL, там свой язык SurrealQL.
SurrealDB - написана на Rust
Компания утверждает, что ее база данных стала самой быстрорастущей за всю историю: ее скачали 2,3 миллиона раз, она набрала 31 000 звезд на GitHub и более 1000 форков.
Среди известных клиентов SurrealDB — Verizon Communications Inc., Walmart Inc., ING Groep NV, Nvidia Corp., Samsung Electronics Co. Ltd., Tencent Holdings Ltd. и Poly AI Ltd.
Продление финансирования связано с выходом общедоступной версии SurrealDB 3.0.
Короче, разработчики выполнили план и получили премию. Я так понял это утверждение 🤔 💰
Вдогонку, чтобы не делить посты следующая статья: Тесты производительности SurrealDB 3.0
Она написана одним из разработчиков SurrealDB. В ней он привёл результаты тестирования СУБД, который они проводили своим собственным бенчмарком crud-bench.
Я даже не знаю, что тут сказать. Всё равно, что я спроектировал автомобиль и по моим тестам он круче BMW в 100 раз 😎. Доверять этим цифрам смысла нет. Это как компания Nvidea показывает рост производительности своих карт на основе своих бенчмарков.
В очередной раз скажу, что без привлечения независимых RnD центров для проведения тестирования доверять цифрам в отчете бессмысленно.
Please open Telegram to view this post
VIEW IN TELEGRAM
SiliconANGLE
SurrealDB raises $23M to expand AI-native multimodel database
SurrealDB Inc. today revealed that it has raised an additional $23 million in funding for its multimodel artificial intelligence-native database.The plan is to accelerate product maturity and adop
❤3
📚 База по графовой СУБД Neo4j
Довольна старая статейка, но я специально ее придержал для студентов, которые планируют изучать графовые БД.
Как базовые туториал материал неплох, хотя в эпоху ИИ постигать популярные opensource инструменты в 100 раз проще. Хотя признаю, чтобы начать учиться нужно уметь задавать правильные вопросы. Если ты совсем не в теме, то ты даже вопросы сформулировать не сможешь. Про релевантные ответы и говорить не стоит.
В общем, ребята, начинайте изучение чего-то нового по туториалам на Хабре или Youtube, а уже потом идите к ИИ "засыпайте" её вопросами по пройденному материалу! 🕸 Вот тут ИИ раскрывается во всей красе! 👍
Если конечно ИИ не с галюционирует и не обманит вас 🤪
Чем-то ИИ мне напоминает студентов на экзамене, которые на "серьезных щах" придумывает такую чушь, что даже сами верят в неё! 😱
Довольна старая статейка, но я специально ее придержал для студентов, которые планируют изучать графовые БД.
Как базовые туториал материал неплох, хотя в эпоху ИИ постигать популярные opensource инструменты в 100 раз проще. Хотя признаю, чтобы начать учиться нужно уметь задавать правильные вопросы. Если ты совсем не в теме, то ты даже вопросы сформулировать не сможешь. Про релевантные ответы и говорить не стоит.
В общем, ребята, начинайте изучение чего-то нового по туториалам на Хабре или Youtube, а уже потом идите к ИИ "засыпайте" её вопросами по пройденному материалу! 🕸 Вот тут ИИ раскрывается во всей красе! 👍
Если конечно ИИ не с галюционирует и не обманит вас 🤪
Чем-то ИИ мне напоминает студентов на экзамене, которые на "серьезных щах" придумывает такую чушь, что даже сами верят в неё! 😱
😁2
🎦 Эволюция баз данных: SQL, NoSQL и доминирование PostgreSQL | Константин Осипов #78
Ссылки на трансляцию на российских площадках:
- vkvideo -
- rutube -
Шикарное интервью с Костиком Осиповым! Советую всем посмотреть о оценить его! Можно весь диалог на цитаты разносить..
Несколько интересных мыслей, которые я подчерпнул:
👉 ScyllaDB больше ориентирована на работу с диском.
👉 Кластер ScyllaDB в несколько петабайт это нормально.
👉 Кластер 22 ноды и сотни терабайт на каждой. Старт одной ноды может занимать часы.
👉 Из популярных NoSQL систем язык SQL не добавили только MongoDB и Redis.
👉 Самые живые направления NoSQL СУБД, для которых PostgreSQL пока не подходит - это поисковые базы данных🔍 .
👉 СУБД Firebird используется в кассах.
👉 SSD справляется с нагрузкой. КЭШ в ОЗУ не нужен.
👉 Есть ли кладбище СУБД?
‼️ СУБД не умирают, они остаются маленькими навсегда.
👉 База данных - канал доставки кода программисту
👉 Все новые СУБД ориентируется на синтаксис PostgreSQL
⁉️Благодаря ИИ мы смогли понять, что такое "рутина". Ранее мы думали, что вот это интеллектуальный труд, а на самом деле это не так.
⁉️Но это может вызвать "застой" в разработке.
❗️ Как я понял Костика: "Picodata зарабывает в РФ на том, что внедряет в компании сертифицированную ФСТЭК СУБД как замену Redis Cluster. Кластер Picodata аналогичен по функционалу Redis Cluster". Интересный кейс. На рынке РФ нет форка Редис для госсектора. Вот так Костик решил это проблему.
👉 Так же Picodata может служить как импортозамещение Cassandra, ScyllaDB.
👉 Всё это работает через плагины Picodata
✅Если не знаете какую СУБД взять, то берите PostgreSQL
Тренды📈 :
⚡️Разработчики СУБД пытаются переписать всё на Rust
⚡️Не так важен высокий RPS. Сейчас главное объем. В РФ почти нет компаний у которых нагрузка выше 5000 транзакций в секунду.
В конце три предсказания🔮 :
🔜 Через 2-3 года в Cassandra добавлять синтаксис ANSI SQL.
🫤 Будет прикольно полностью переписать PostgreSQL на Rust.
😐 Не понятно нужны ли распределенные СУБД? Выживут ли они спустя 3 года?
Ссылки на трансляцию на российских площадках:
- vkvideo -
- rutube -
Шикарное интервью с Костиком Осиповым! Советую всем посмотреть о оценить его! Можно весь диалог на цитаты разносить..
Несколько интересных мыслей, которые я подчерпнул:
👉 ScyllaDB больше ориентирована на работу с диском.
👉 Кластер ScyllaDB в несколько петабайт это нормально.
👉 Кластер 22 ноды и сотни терабайт на каждой. Старт одной ноды может занимать часы.
👉 Из популярных NoSQL систем язык SQL не добавили только MongoDB и Redis.
👉 Самые живые направления NoSQL СУБД, для которых PostgreSQL пока не подходит - это поисковые базы данных
👉 СУБД Firebird используется в кассах.
👉 SSD справляется с нагрузкой. КЭШ в ОЗУ не нужен.
👉 Есть ли кладбище СУБД?
‼️ СУБД не умирают, они остаются маленькими навсегда.
👉 База данных - канал доставки кода программисту
👉 Все новые СУБД ориентируется на синтаксис PostgreSQL
⁉️Благодаря ИИ мы смогли понять, что такое "рутина". Ранее мы думали, что вот это интеллектуальный труд, а на самом деле это не так.
⁉️Но это может вызвать "застой" в разработке.
👉 Так же Picodata может служить как импортозамещение Cassandra, ScyllaDB.
👉 Всё это работает через плагины Picodata
✅Если не знаете какую СУБД взять, то берите PostgreSQL
Тренды
⚡️Разработчики СУБД пытаются переписать всё на Rust
⚡️Не так важен высокий RPS. Сейчас главное объем. В РФ почти нет компаний у которых нагрузка выше 5000 транзакций в секунду.
В конце три предсказания
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Эволюция баз данных: SQL, NoSQL и доминирование PostgreSQL | Константин Осипов #78
Сегодня у нас в гостях — Константин Осипов, один из самых известных инженеров в мире баз данных: core-разработчик MySQL, создатель Tarantool, бывший директор разработки в ScyllaDB и сооснователь Picodata. Мы поговорили о том, как на самом деле устроен рынок…
🔥3👍1
🎦 Valkey 2026: In-Memory Databases, AI Agents & Real-Time Data | Madelyn Olson, AWS
❗️Текст❗️
Мэделин Олсон (мейнтейнер Valkey, Principal Engineer AWS), утверждает, что в 2026 году произойдет решительный сдвиг в сторону команд экспертов, управляющих меньшим количеством баз данных, но при этом эти базы данных должны будут выполнять гораздо больше функций.
1️⃣ Консолидация баз данных
Компании устали от "зоопарка" специализированных БД (векторные, поисковые и т.д.) и переходят к нескольким универсальным системам. Победителями станут Postgres и Valkey.
2️⃣Valkey для AI-агентов
Агентные системы требуют доступа к структурированным данным в реальном времени. Valkey адаптируется к новым вызовам:
👉 гибридный поиск: полнотекстовый + векторный для RAG.
👉 улучшенной durability (чтобы стать не просто кэшем, а полноценной базой данных).
3️⃣ Снижение затрат на память
Рост цен на RAM и SSD заставляет искать компромиссы. Valkey делает ставку на сжатие данных (с использованием CPU, например, AWS Graviton) и хранение части данных на SSD - это снижает TCO без значимой потери производительности.
4️⃣ Человеческий фактор
Успех внедрения AI-инструментов зависит от опыта разработчиков. Чем проще интегрировать базы данных и агентов в повседневную работу, тем быстрее технологии принимаются.
⚡️ Дорожная карта Valkey на 2026 год⚡️
🔥 Первоклассная надежность. Переход от асинхронной репликации к более надежным гарантиям согласованности, что позволяет использовать Valkey в качестве основной базы данных, а не просто кэша.
🔥 Гибридный поиск. Уже вышла новая версия ValkeySearch 1.2, которая позволяет выполнять поиск по текстовым, теговым, числовым и векторным атрибутам в рамках одного запроса и анализировать результаты.
🔥 Оптимизация затрат. Сжатие данных и интеграция с твердотельными накопителями для снижения растущих затрат на инфраструктуру без ущерба для производительности
❗️Текст❗️
Мэделин Олсон (мейнтейнер Valkey, Principal Engineer AWS), утверждает, что в 2026 году произойдет решительный сдвиг в сторону команд экспертов, управляющих меньшим количеством баз данных, но при этом эти базы данных должны будут выполнять гораздо больше функций.
1️⃣ Консолидация баз данных
Компании устали от "зоопарка" специализированных БД (векторные, поисковые и т.д.) и переходят к нескольким универсальным системам. Победителями станут Postgres и Valkey.
2️⃣Valkey для AI-агентов
Агентные системы требуют доступа к структурированным данным в реальном времени. Valkey адаптируется к новым вызовам:
👉 гибридный поиск: полнотекстовый + векторный для RAG.
👉 улучшенной durability (чтобы стать не просто кэшем, а полноценной базой данных).
3️⃣ Снижение затрат на память
Рост цен на RAM и SSD заставляет искать компромиссы. Valkey делает ставку на сжатие данных (с использованием CPU, например, AWS Graviton) и хранение части данных на SSD - это снижает TCO без значимой потери производительности.
4️⃣ Человеческий фактор
Успех внедрения AI-инструментов зависит от опыта разработчиков. Чем проще интегрировать базы данных и агентов в повседневную работу, тем быстрее технологии принимаются.
🔥 Первоклассная надежность. Переход от асинхронной репликации к более надежным гарантиям согласованности, что позволяет использовать Valkey в качестве основной базы данных, а не просто кэша.
🔥 Гибридный поиск. Уже вышла новая версия ValkeySearch 1.2, которая позволяет выполнять поиск по текстовым, теговым, числовым и векторным атрибутам в рамках одного запроса и анализировать результаты.
🔥 Оптимизация затрат. Сжатие данных и интеграция с твердотельными накопителями для снижения растущих затрат на инфраструктуру без ущерба для производительности
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Valkey 2026: In-Memory Databases, AI Agents & Real-Time Data | Madelyn Olson, AWS
In-memory databases are becoming critical infrastructure for AI agents and real-time data serving. Madelyn Olson, Valkey Project Maintainer and Principal Engineer for AWS In-Memory Databases, explains how database consolidation is replacing the sprawl of…
👍1