Видео вчерашнего стрима с Никитой Кречетовым, Avito:
https://www.youtube.com/watch?v=bJnDkDAoOUw
Некоторое «мясо» по темам интервью (в видео на самом деле ещё больше инсайтов).
Масштаб: ~2700 хранилищ Redis, среди них сотни шардированных инсталляций. Это “внутреннее облако”: продуктовые команды не думают про жизненный цикл БД (создание, окружения, секреты, аккаунты, доступы) — это делает платформенная команда.
Почему исторически не Redis Cluster. Присматривались к Redis Cluster пробовали с Redis 5 → 7, но считали технологию незрелой для больших масштабов, требовалось перепилить компоненты платформы, клиентские библиотеки созрели не сразу.
Выбор Valkey vs KeyDB vs Dragonfly
• Лицензию Redis “закрыли” в марте 2024.
• Valkey: первый стабильный релиз — апрель 2024; форк Redis, бинарно близкий, но вначале было неясно, “взлетит ли” комьюнити.
• Dragonfly не тестировали: не подошла лицензия.
• KeyDB рассматривали всерьёз (развивался с 2019, поддержка/участие Snapchat), интересен master-master / active replication (идея распределять write-нагрузку без шардирования данных) + честная “многопоточность” через несколько event loop (условно “несколько Redis в потоках”), давала выигрыш на 3–4 потоках.
• Но в процессе выяснилось, что KeyDB фактически не поддерживается/не развивается, и примерно в 2025 приняли окончательное решение перейти на Valkey.
Производительность: конкретные цифры
• Оптимальная конфигурация по тестам: 3–4 потока.
• На тестах Valkey 8.x давал: до +50% к максимальному RPS/пропускной способности относительно Redis 7.2.8 (при одинаковом CPU-лимите, “CPU под завязку”), относительно KeyDB — ещё несколько процентов выигрыша.
• Узкое место часто было не CPU, а количество соединений и “пиковые” коннекты: Valkey 8.x держал их более линейно и предсказуемо (за счёт переработки многопоточности).
“Неожиданность” с обновлением версий
• Тестировали на 8.0.2 (стабильно, хороший выигрыш).
• Попробовали обновить часть кластеров на 8.1.0: на синтетике “норм”, но на реальных данных хуже latency (в среднем до ~1.5×), быстро откатились обратно на 8.0.2.
• Реальные паттерны нагрузки сложно воспроизвести на стенде, часть проблем проявляется только в проде.
Почему поверх Cluster построили ещё один “кластер” (sidecar + Raft)
Valkey/Redis Cluster “умный”, но для платформы не хватает критичных функций:
• Авто-учётки/доступы, интеграции с безопасностью.
• Автоматический решардинг при изменении топологии (добавление/удаление узлов).
• Умная поддержка зон доступности (AZ): важно равномерно держать master-ноды по зонам, кластер не умеет “умный фейловер” с учётом AZ.
🔥 спасибо за интересный платформенный кейс
👍 из полей доноситсяналей valkey!
—
Обучение Devhands Redis/Valkey: https://devhands.io/rv
Канал Алексея Рыбака: https://t.me/rybakalexey
Канал Avito Tech: https://t.me/avitotech
Канал Avito Data Tech: https://t.me/avitotech
https://www.youtube.com/watch?v=bJnDkDAoOUw
Некоторое «мясо» по темам интервью (в видео на самом деле ещё больше инсайтов).
Масштаб: ~2700 хранилищ Redis, среди них сотни шардированных инсталляций. Это “внутреннее облако”: продуктовые команды не думают про жизненный цикл БД (создание, окружения, секреты, аккаунты, доступы) — это делает платформенная команда.
Почему исторически не Redis Cluster. Присматривались к Redis Cluster пробовали с Redis 5 → 7, но считали технологию незрелой для больших масштабов, требовалось перепилить компоненты платформы, клиентские библиотеки созрели не сразу.
Выбор Valkey vs KeyDB vs Dragonfly
• Лицензию Redis “закрыли” в марте 2024.
• Valkey: первый стабильный релиз — апрель 2024; форк Redis, бинарно близкий, но вначале было неясно, “взлетит ли” комьюнити.
• Dragonfly не тестировали: не подошла лицензия.
• KeyDB рассматривали всерьёз (развивался с 2019, поддержка/участие Snapchat), интересен master-master / active replication (идея распределять write-нагрузку без шардирования данных) + честная “многопоточность” через несколько event loop (условно “несколько Redis в потоках”), давала выигрыш на 3–4 потоках.
• Но в процессе выяснилось, что KeyDB фактически не поддерживается/не развивается, и примерно в 2025 приняли окончательное решение перейти на Valkey.
Производительность: конкретные цифры
• Оптимальная конфигурация по тестам: 3–4 потока.
• На тестах Valkey 8.x давал: до +50% к максимальному RPS/пропускной способности относительно Redis 7.2.8 (при одинаковом CPU-лимите, “CPU под завязку”), относительно KeyDB — ещё несколько процентов выигрыша.
• Узкое место часто было не CPU, а количество соединений и “пиковые” коннекты: Valkey 8.x держал их более линейно и предсказуемо (за счёт переработки многопоточности).
“Неожиданность” с обновлением версий
• Тестировали на 8.0.2 (стабильно, хороший выигрыш).
• Попробовали обновить часть кластеров на 8.1.0: на синтетике “норм”, но на реальных данных хуже latency (в среднем до ~1.5×), быстро откатились обратно на 8.0.2.
• Реальные паттерны нагрузки сложно воспроизвести на стенде, часть проблем проявляется только в проде.
Почему поверх Cluster построили ещё один “кластер” (sidecar + Raft)
Valkey/Redis Cluster “умный”, но для платформы не хватает критичных функций:
• Авто-учётки/доступы, интеграции с безопасностью.
• Автоматический решардинг при изменении топологии (добавление/удаление узлов).
• Умная поддержка зон доступности (AZ): важно равномерно держать master-ноды по зонам, кластер не умеет “умный фейловер” с учётом AZ.
🔥 спасибо за интересный платформенный кейс
👍 из полей доносится
—
Обучение Devhands Redis/Valkey: https://devhands.io/rv
Канал Алексея Рыбака: https://t.me/rybakalexey
Канал Avito Tech: https://t.me/avitotech
Канал Avito Data Tech: https://t.me/avitotech
👍1🔥1
Книга: «Архитектуры данных: современные решения для любых задач»
Свежий перевод западной литературу Orelly от нашего издательства Питер.
Примечательно, что книгу рецензировали в клубе рецензентов ИТ-литературы ReadITClub.
Судя по сайту данный клуб принадлежи КРОКу и получает дополнительную поддержку от российских издательств технической литературы.
Здорово, что у нас существует подобный клуб 💪! Я до того, как открыл книгу ничего об этом не знал.
❇️ Коротко про книгу.
В ней 288 страниц — надеюсь, прочитаю быстро 😁
Состоит из 4-х частей:
Сегодня — Часть I, в ней 3 главы и 3 ключевые мысли:
1️⃣ Ценность важнее “объёмов”.
Big Data — это не “очень много данных”, а любые данные, которые дают эффект. Автор объясняет 6V: Volume, Variety, Velocity, Veracity, Variability и главное — Value. Остальные V важны ровно настолько, насколько помогают (или мешают) получить ценность.
2️⃣ Универсальной архитектуры нет.
Показывается “ландшафт” подходов: RDW → Data Lake → MDW → Fabric / Lakehouse / Mesh. Выбор зависит от нагрузок, типов данных, SLA, безопасности, доступности и того, как данные будут потребляться (в т.ч. self-service).
3️⃣ Выбор архитектуры — это процесс.
Предлагается ADS (architecture design session): собрать бизнес + ИТ и зафиксировать цели/ограничения (latency, объёмы, HA/DR, источники, ML и т.д.). По опыту: без практики и фасилитатора/ментора такую сессию легко "запороть". Было бы интересно на таких сессиях поприсутвовать...
❇️ Итоговая мысль
Сначала формулируем какую ценность хотим получить и фиксируем реальные требования/ограничения. Затем проводим дизайн-сессию со стейкхолдерами, чтобы осознанно выбрать архитектурный подход согласно задаче.
⚠️ Забавный исторический факт.
Data Lake появились в 2010-х годах. Самые яркие представители это Hadoop, Cloudera, Hortonworks и MapR. Однако, все эти решения (кроме Hadoop) провались в коммерческом плане. Причина банальная, неудобный и сложный инструментарий для извлечения данных (создание отчетов). Последним гвоздем стало то, что все любят SQL, транзакции и так нужный в корпоративной среде аудит.
В 2020-х случился "Ренессанс" с пришествием табличных форматов/транзакционными слоями вроде Delta Lake (и аналогов Iceberg/Hudi). Были добавлены transaction log, операции MERGE/UPDATE/DELETE, контроль схемы и версионирование (time travel). Таким образом, озеро стали гораздо ближе к требованиям BI и аналитики.
Очередное подтверждение того, что от SQL и реляционной теории нам не избавиться никогда 😈😈😈
Свежий перевод западной литературу Orelly от нашего издательства Питер.
Примечательно, что книгу рецензировали в клубе рецензентов ИТ-литературы ReadITClub.
Судя по сайту данный клуб принадлежи КРОКу и получает дополнительную поддержку от российских издательств технической литературы.
Здорово, что у нас существует подобный клуб 💪! Я до того, как открыл книгу ничего об этом не знал.
❇️ Коротко про книгу.
В ней 288 страниц — надеюсь, прочитаю быстро 😁
Состоит из 4-х частей:
Часть I. Основные понятия
Часть II. Общие понятия архитектуры данных
Часть III. Архитектуры данных
Часть IV. Люди, процессы и технологии
Сегодня — Часть I, в ней 3 главы и 3 ключевые мысли:
1️⃣ Ценность важнее “объёмов”.
Big Data — это не “очень много данных”, а любые данные, которые дают эффект. Автор объясняет 6V: Volume, Variety, Velocity, Veracity, Variability и главное — Value. Остальные V важны ровно настолько, насколько помогают (или мешают) получить ценность.
2️⃣ Универсальной архитектуры нет.
Показывается “ландшафт” подходов: RDW → Data Lake → MDW → Fabric / Lakehouse / Mesh. Выбор зависит от нагрузок, типов данных, SLA, безопасности, доступности и того, как данные будут потребляться (в т.ч. self-service).
3️⃣ Выбор архитектуры — это процесс.
Предлагается ADS (architecture design session): собрать бизнес + ИТ и зафиксировать цели/ограничения (latency, объёмы, HA/DR, источники, ML и т.д.). По опыту: без практики и фасилитатора/ментора такую сессию легко "запороть". Было бы интересно на таких сессиях поприсутвовать...
❇️ Итоговая мысль
Сначала формулируем какую ценность хотим получить и фиксируем реальные требования/ограничения. Затем проводим дизайн-сессию со стейкхолдерами, чтобы осознанно выбрать архитектурный подход согласно задаче.
⚠️ Забавный исторический факт.
Data Lake появились в 2010-х годах. Самые яркие представители это Hadoop, Cloudera, Hortonworks и MapR. Однако, все эти решения (кроме Hadoop) провались в коммерческом плане. Причина банальная, неудобный и сложный инструментарий для извлечения данных (создание отчетов). Последним гвоздем стало то, что все любят SQL, транзакции и так нужный в корпоративной среде аудит.
В 2020-х случился "Ренессанс" с пришествием табличных форматов/транзакционными слоями вроде Delta Lake (и аналогов Iceberg/Hudi). Были добавлены transaction log, операции MERGE/UPDATE/DELETE, контроль схемы и версионирование (time travel). Таким образом, озеро стали гораздо ближе к требованиям BI и аналитики.
Очередное подтверждение того, что от SQL и реляционной теории нам не избавиться никогда 😈😈😈
🔥4
📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».
Поговорим про Часть 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