От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру
Реализация системы с микросервисной архитектурой редко обходится без классического разруливающего REST-гейтвея. Но когда ваша система растёт годами, а в гейтвее плодятся сотни ручек с просачивающейся бизнес-логикой, можно внезапно обнаружить, что ваш REST-гейтвей стал монолитом со всеми вытекающими последствиями.
Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.
Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре.
Читать: https://habr.com/ru/companies/yandex/articles/935948/
#ru
@database_design | Другие наши каналы
Реализация системы с микросервисной архитектурой редко обходится без классического разруливающего REST-гейтвея. Но когда ваша система растёт годами, а в гейтвее плодятся сотни ручек с просачивающейся бизнес-логикой, можно внезапно обнаружить, что ваш REST-гейтвей стал монолитом со всеми вытекающими последствиями.
Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.
Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре.
Читать: https://habr.com/ru/companies/yandex/articles/935948/
#ru
@database_design | Другие наши каналы
Работа над ошибками
Достаточно большой период времени занимался технической поддержкой СУБД Oracle. Накопилось некоторое количество историй и заметок на полях по этому поводу, не могу не поделиться ими с вами. В общем – садимся по удобнее, берем попкорн, чашку горячего чая или кофе.. Дело было так.
Читать: https://habr.com/ru/articles/938502/
#ru
@database_design | Другие наши каналы
Достаточно большой период времени занимался технической поддержкой СУБД Oracle. Накопилось некоторое количество историй и заметок на полях по этому поводу, не могу не поделиться ими с вами. В общем – садимся по удобнее, берем попкорн, чашку горячего чая или кофе.. Дело было так.
Читать: https://habr.com/ru/articles/938502/
#ru
@database_design | Другие наши каналы
Тестирование CAP-теоремы на примере MongoDB: аварийные ситуации
Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB.
В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB.
В этой статье я покажу результаты тестов при аварийных ситуациях, которые могут происходить в распределенной системе. Сделаем выводы о свойствах набора реплик с точки зрения CAP- и PACELC-теорем для распределенных систем и посмотрим параметры управления CAP-свойствами неоднородных распределенных систем.
Читать: https://habr.com/ru/companies/tbank/articles/938670/
#ru
@database_design | Другие наши каналы
Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB.
В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB.
В этой статье я покажу результаты тестов при аварийных ситуациях, которые могут происходить в распределенной системе. Сделаем выводы о свойствах набора реплик с точки зрения CAP- и PACELC-теорем для распределенных систем и посмотрим параметры управления CAP-свойствами неоднородных распределенных систем.
Читать: https://habr.com/ru/companies/tbank/articles/938670/
#ru
@database_design | Другие наши каналы
Наш опыт с Cassandra и ScyllaDB: какие есть ограничения у этих key-value-БД и почему стоит присмотреться к альтернативам
Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.
Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.
Но по мере роста проекта возникает необходимость более сложной работы с данными. Например, когда хочется получить информацию в разрезе дат или понять, на каких устройствах какие токены живут. И вот здесь начинают всплывать ограничения архитектуры и типовые грабли, на которые можно наступить (и мы регулярно это делали). В этом материале мы опишем, почему выбрали Cassandra и с какими проблемами столкнулись — надеемся, это поможет правильно определиться с выбором нужного инструмента для ваших систем.
Читать: https://habr.com/ru/companies/ru_mts/articles/935896/
#ru
@database_design | Другие наши каналы
Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.
Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.
Но по мере роста проекта возникает необходимость более сложной работы с данными. Например, когда хочется получить информацию в разрезе дат или понять, на каких устройствах какие токены живут. И вот здесь начинают всплывать ограничения архитектуры и типовые грабли, на которые можно наступить (и мы регулярно это делали). В этом материале мы опишем, почему выбрали Cassandra и с какими проблемами столкнулись — надеемся, это поможет правильно определиться с выбором нужного инструмента для ваших систем.
Читать: https://habr.com/ru/companies/ru_mts/articles/935896/
#ru
@database_design | Другие наши каналы
Интеллектуальное управление автопарком с помощью AI и MongoDB
Новая система на базе MongoDB и AI обрабатывает огромные объемы данных с автомобилей в реальном времени. Она оптимизирует маршруты, прогнозирует техобслуживание и дает точные инсайты для повышения эффективности и снижения затрат. Новые storage-оптимизированные узлы MongoDB Atlas Search позволяют экономить до 50% на стоимости хранения, обеспечивая в 2 раза больше места и оптимальный баланс ресурсов для больших индексов с умеренной нагрузкой. Идеальны для масштабирования AI и векторного поиска. Автоматизация технического обслуживания с помощью ИИ
Статья рассказывает, как ИИ-агенты собирают данные, анализируют причины сбоев и создают заявки на ремонт. Такой подход минимизирует простои, снижает затраты и повышает надежность оборудования на производстве.
Читать подробнее
#en
@database_design | Другие наши каналы
Новая система на базе MongoDB и AI обрабатывает огромные объемы данных с автомобилей в реальном времени. Она оптимизирует маршруты, прогнозирует техобслуживание и дает точные инсайты для повышения эффективности и снижения затрат. Новые storage-оптимизированные узлы MongoDB Atlas Search позволяют экономить до 50% на стоимости хранения, обеспечивая в 2 раза больше места и оптимальный баланс ресурсов для больших индексов с умеренной нагрузкой. Идеальны для масштабирования AI и векторного поиска. Автоматизация технического обслуживания с помощью ИИ
Статья рассказывает, как ИИ-агенты собирают данные, анализируют причины сбоев и создают заявки на ремонт. Такой подход минимизирует простои, снижает затраты и повышает надежность оборудования на производстве.
Читать подробнее
#en
@database_design | Другие наши каналы
Конституционный ИИ и MongoDB создают новый стандарт этики в искусственном интеллекте. Совместный подход обеспечивает прозрачность, справедливость и масштабируемое управление этическими принципами, позволяя строить ответственные и регулируемые AI-системы будущего.
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
Альтернатива чатам с ИИ для анализа и оптимизации SQL запросов. Часть 2
Месяц назад я опубликовал пост об инструменте для автоматической оптимизации SQL-запросов. Идея была простая — убрать этап «общения» с ИИ и предоставить простой интерфейс, где не нужно придумывать промпты.
За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.
Читать: https://habr.com/ru/articles/938806/
#ru
@database_design | Другие наши каналы
Месяц назад я опубликовал пост об инструменте для автоматической оптимизации SQL-запросов. Идея была простая — убрать этап «общения» с ИИ и предоставить простой интерфейс, где не нужно придумывать промпты.
За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.
Читать: https://habr.com/ru/articles/938806/
#ru
@database_design | Другие наши каналы
CDC без боли: как мы делали отказоустойчивую репликацию с Debezium и Kafka
Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации.
Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных).
Читать: https://habr.com/ru/companies/magnit/articles/938164/
#ru
@database_design | Другие наши каналы
Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации.
Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных).
Читать: https://habr.com/ru/companies/magnit/articles/938164/
#ru
@database_design | Другие наши каналы
CDC без боли: как мы делали отказоустойчивую репликацию с Debezium и Kafka
Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации.
Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных).
Читать: https://habr.com/ru/companies/magnit/articles/938164/
#ru
@database_design | Другие наши каналы
Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации.
Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных).
Читать: https://habr.com/ru/companies/magnit/articles/938164/
#ru
@database_design | Другие наши каналы
Новая интеграция MongoDB и LangGraph открывает возможности создания AI-агентов с долговременной памятью, которые учатся и улучшаются со временем. Это шаг к более интеллектуальным системам с улучшенным управлением данными и этикой в AI.
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
Многофакторное сравнение пяти популярных вычислительных движков для больших данных
Эволюция от Hadoop к cloud‑native и ИИ‑архитектурам. Многомерное сравнение Spark, Presto, Trino, ClickHouse и StarRocks по скорости, масштабируемости, кэшам, SQL/Python, HA и др.
Читать: «Многофакторное сравнение пяти популярных вычислительных движков для больших данных»
#ru
@database_design | Другие наши каналы
Эволюция от Hadoop к cloud‑native и ИИ‑архитектурам. Многомерное сравнение Spark, Presto, Trino, ClickHouse и StarRocks по скорости, масштабируемости, кэшам, SQL/Python, HA и др.
Читать: «Многофакторное сравнение пяти популярных вычислительных движков для больших данных»
#ru
@database_design | Другие наши каналы
Многофакторное сравнение пяти популярных вычислительных движков для больших данных
Эволюция от Hadoop к cloud‑native и ИИ‑архитектурам. Многомерное сравнение Spark, Presto, Trino, ClickHouse и StarRocks по скорости, масштабируемости, кэшам, SQL/Python, HA и др.
Читать: «Многофакторное сравнение пяти популярных вычислительных движков для больших данных»
#ru
@database_design | Другие наши каналы
Эволюция от Hadoop к cloud‑native и ИИ‑архитектурам. Многомерное сравнение Spark, Presto, Trino, ClickHouse и StarRocks по скорости, масштабируемости, кэшам, SQL/Python, HA и др.
Читать: «Многофакторное сравнение пяти популярных вычислительных движков для больших данных»
#ru
@database_design | Другие наши каналы
64-битный счётчик транзакций в PostgreSQL
На конференции PgBootcamp 2025 был доклад Евгения Воропаева "Разработка и отладка 64-битного счётчика транзакций". В докладе рассматривались проблемы, которые встретились при переносе патча, который добавляет поддержку 64-битного счетчика, с 16 на 18 версию PostgreSQL. В статье описывается история создания патча и почему он есть только в коммерческих форках.
В PostgreSQL используется 32-битные идентификаторы транзакций. У каждой версии строки в блоке таблицы есть идентификатор транзакции, которая создала эту версию. Если номер транзакции, меняющей строку, будет отстоять от номера транзакции, которая создала строку больше, чем на 2 миллиарда, то нельзя определить сравнив номера, какая из транзакций старше. Чтобы такого не произошло, в PostgreSQL есть функционал "заморозки" версий строк в блоках таблиц.
Читать: https://habr.com/ru/companies/tantor/articles/937992/
#ru
@database_design | Другие наши каналы
На конференции PgBootcamp 2025 был доклад Евгения Воропаева "Разработка и отладка 64-битного счётчика транзакций". В докладе рассматривались проблемы, которые встретились при переносе патча, который добавляет поддержку 64-битного счетчика, с 16 на 18 версию PostgreSQL. В статье описывается история создания патча и почему он есть только в коммерческих форках.
В PostgreSQL используется 32-битные идентификаторы транзакций. У каждой версии строки в блоке таблицы есть идентификатор транзакции, которая создала эту версию. Если номер транзакции, меняющей строку, будет отстоять от номера транзакции, которая создала строку больше, чем на 2 миллиарда, то нельзя определить сравнив номера, какая из транзакций старше. Чтобы такого не произошло, в PostgreSQL есть функционал "заморозки" версий строк в блоках таблиц.
Читать: https://habr.com/ru/companies/tantor/articles/937992/
#ru
@database_design | Другие наши каналы
Гонка за дата-центры: новая энергетика цифрового мира
Ещё лет десять назад мало кого интересовали дата-центры — они воспринимались скорее как техническая «кухня» цифровой экосистемы. Но ситуация в корне изменилась. ЦОДы стали горячей темой для всей мировой экономики. Они влияют на IT-ландшафт, сырьевой рынок, энергетику и даже на геополитику. Подробнее об этом читайте далее.
Читать: https://habr.com/ru/companies/cloud4y/articles/939102/
#ru
@database_design | Другие наши каналы
Ещё лет десять назад мало кого интересовали дата-центры — они воспринимались скорее как техническая «кухня» цифровой экосистемы. Но ситуация в корне изменилась. ЦОДы стали горячей темой для всей мировой экономики. Они влияют на IT-ландшафт, сырьевой рынок, энергетику и даже на геополитику. Подробнее об этом читайте далее.
Читать: https://habr.com/ru/companies/cloud4y/articles/939102/
#ru
@database_design | Другие наши каналы
На что способны новые SSD с PCIe 6.0 и когда они появятся на десктопах
Рынок SSD-накопителей прямо сейчас переживает непростое время. С одной стороны, далеко не все еще поняли, есть ли смысл переходить с PCIe 4.0 на PCIe 5.0. А с другой, производители уже демонстрируют твердотельники следующего поколения с еще более высокой пропускной способностью. Получается парадокс: технология развивается быстрее, чем у массового потребителя появляется реальная потребность в ней. Но это не значит, что PCIe 6.0 не нужна никому. Напротив, очень даже нужна.
Читать: https://habr.com/ru/companies/x-com/articles/939324/
#ru
@database_design | Другие наши каналы
Рынок SSD-накопителей прямо сейчас переживает непростое время. С одной стороны, далеко не все еще поняли, есть ли смысл переходить с PCIe 4.0 на PCIe 5.0. А с другой, производители уже демонстрируют твердотельники следующего поколения с еще более высокой пропускной способностью. Получается парадокс: технология развивается быстрее, чем у массового потребителя появляется реальная потребность в ней. Но это не значит, что PCIe 6.0 не нужна никому. Напротив, очень даже нужна.
Читать: https://habr.com/ru/companies/x-com/articles/939324/
#ru
@database_design | Другие наши каналы
Новый бенчмарк MongoDB Atlas Vector Search показывает, как улучшить поиск по векторным данным с оптимальной точностью, скоростью и затратами. Интеграция с LangGraph добавляет ИИ-агентам долгосрочную память, повышая их адаптивность и эффективность.
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
Shardman. Краткое пособие архитектора
Миф о волшебном параметре fast=true жив и здоров, но в распределённых СУБД появляется ещё один — distributed=true. Ни тот, ни другой не спасут, если не пересобрать схему, ключи шардирования, последовательности, запросы и процесс миграции. Мы трезво проходим по всем углам: от выбора ключей и colocated-таблиц до CDC, топологий и ограничений внешних ключей; показываем, где действительно ускорится, а где станет дороже — и что с этим делать.
Читать: https://habr.com/ru/companies/postgrespro/articles/939396/
#ru
@database_design | Другие наши каналы
Миф о волшебном параметре fast=true жив и здоров, но в распределённых СУБД появляется ещё один — distributed=true. Ни тот, ни другой не спасут, если не пересобрать схему, ключи шардирования, последовательности, запросы и процесс миграции. Мы трезво проходим по всем углам: от выбора ключей и colocated-таблиц до CDC, топологий и ограничений внешних ключей; показываем, где действительно ускорится, а где станет дороже — и что с этим делать.
Читать: https://habr.com/ru/companies/postgrespro/articles/939396/
#ru
@database_design | Другие наши каналы
Не лает, не кусает, в 1С не пускает. Что поможет спасти ваши базы 1С от критической уязвимости BDU:2025-07182
17.06.2025 г. ФСТЭК России зафиксирована критическая уязвимость в платформе 1С:Предприятие 8 под номером BDU-2025-07182. Этот дефект позволяет злоумышленникам, действующим удаленно, получить несанкционированный доступ к системе от имени произвольного пользователя, что создает серьезные риски для компаний, использующих решения 1С в своих бизнес-процессах.
Что грозит в связи с этим малому и среднему бизнесу? И как защититься? Подробно рассказываю далее.
Читать: https://habr.com/ru/articles/939488/
#ru
@database_design | Другие наши каналы
17.06.2025 г. ФСТЭК России зафиксирована критическая уязвимость в платформе 1С:Предприятие 8 под номером BDU-2025-07182. Этот дефект позволяет злоумышленникам, действующим удаленно, получить несанкционированный доступ к системе от имени произвольного пользователя, что создает серьезные риски для компаний, использующих решения 1С в своих бизнес-процессах.
Что грозит в связи с этим малому и среднему бизнесу? И как защититься? Подробно рассказываю далее.
Читать: https://habr.com/ru/articles/939488/
#ru
@database_design | Другие наши каналы
Новая эпоха ИИ требует инноваций в работе с данными. В статье рассказано о возможностях MongoDB Atlas: объединённые хранилища, долговременная память ИИ-агентов и эффективный векторный поиск на примере Amazon Reviews. Узнайте подробнее!
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
От реляционных СУБД к экосистеме Hadoop
Привет, хабр!
Недавно я понял, что не знаю, что такое Hadoop.
(На этом моменте становится понятно, что данная статья ориентирована на людей, которые не имеют экспертизы и реального опыта взаимодействия с продуктами экосистемы Hadoop)
Сам я являюсь разработчиком, и ежедневно взаимодействую с различными СУБД – в основном, с пресловутой PostgreSQL. Каково же было мое удивление, когда я узнал, что на проде в эту БД данные попадают не напрямую – а с какого-то Greenplum, а туда они, в свою очередь, приходят с некоего Hadoop.
В этот момент я решил узнать, чем обоснована необходимость использования этих инструментов и что они из себя представляют.
Читать: https://habr.com/ru/articles/939520/
#ru
@database_design | Другие наши каналы
Привет, хабр!
Недавно я понял, что не знаю, что такое Hadoop.
(На этом моменте становится понятно, что данная статья ориентирована на людей, которые не имеют экспертизы и реального опыта взаимодействия с продуктами экосистемы Hadoop)
Сам я являюсь разработчиком, и ежедневно взаимодействую с различными СУБД – в основном, с пресловутой PostgreSQL. Каково же было мое удивление, когда я узнал, что на проде в эту БД данные попадают не напрямую – а с какого-то Greenplum, а туда они, в свою очередь, приходят с некоего Hadoop.
В этот момент я решил узнать, чем обоснована необходимость использования этих инструментов и что они из себя представляют.
Читать: https://habr.com/ru/articles/939520/
#ru
@database_design | Другие наши каналы
Обновление MariaDB Connector/C 3.4.7 и 3.3.17 уже доступно для загрузки. В новых версиях исправлены ошибки и улучшена совместимость. Подробности в официальных заметках к релизу на сайте MariaDB.
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
MariaDB
MariaDB Connector/C 3.4.7, and 3.3.17 now available | MariaDB
MariaDB is pleased to announce the immediate availability of MariaDB Connector/C 3.4.7, and 3.3.17. Download Now Notable items: Notable items: See the release notes and changelogs for more details and…