В мире PostgreSQL всё ещё нет готового коробочного решения для горизонтального масштабирования. Когда один кластер перестаёт тянуть нагрузку, начинается самое интересное: чистка или охлаждение данных, распил одного кластера на несколько и, в конце концов, шардирование.
На практике всё упирается не в сами шарды, а в инфраструктуру вокруг них. Стоит ли реализовывать логику на стороне приложения? Как из одного шарда сделать 2, 4, 8, 32 и так далее? И как перенести туда данные и избежать downtime?
Система заточена на OLTP‑нагрузки, где большинство транзакций можно уложить в один шард. Например:
customer_id или product_category author_id или типу контента (при этом комментарии и связанный контент остаются на одном шарде)Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡11🔥8❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Авто.ру — это сервис, который делает покупку и продажу автомобиля удобной, технологичной и безопасной. Он обрабатывает тысячи запросов в секунду, а внутри у него оркестр из бизнес-логики. Раньше сервис работал поверх шардированного MySQL, но масштабироваться на нём было трудно. Поэтому команда решила переехать на Yandex Database.
А как проходил переезд, с чем столкнулись по пути и как в процессе оптимизировали архитектуру всего сервиса, показывает Андрей Борунов, руководитель группы разработки базовых сервисов в Авто.ру.
В докладе Андрей рассказал:
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍6❤2
Мы хотели ускорить сетевую диагностику в приложении, а для этого уменьшили интервал запросов с 5 минут до 30 секунд. Логично предположить: раз клиенты стали ходить в 10 раз чаще, то и нагрузка вырастет в 10 раз. Мы подготовили инфраструктуру под 50 000 RPS, но после релиза увидели лишь 25 000.
Оказалось, что наша модель была слишком простой. На масштабе миллионов пользователей поведение системы описывается не линейной, а более сложной зависимостью. А чтобы понять её, мы построили вероятностную модель, основанную на времени жизни сессии пользователя.
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥4🥰1🤯1
Сеть помогает строить агентов, а агенты помогают строить сети!
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤2🥴2👏1
В блоге о работе в Яндексе вышла статья разработчика каталога Лавки. За четыре года он вырос до тимлида, понял, что это не его, и снова стал бэкендером. Но софт-скилы нужны не только руководителям.
Делимся инсайтами о том, как и зачем бэкендеру уметь в софты:
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
🥱10🔥5❤2❤🔥1🤷♂1
😈 Как мы запустили 50 тысяч фейковых водителей в прод
На связи Андрей Матвеев, разработчик в команде платформы надёжности Яндекс Такси. А ещё я техлид проекта virtual-orders — нашей системы нагрузочных учений. С ней мы выявляем узкие места в архитектуре, определяем границы работоспособности и прогнозируем поведение сервиса в разных сценариях.
👩⚕️ В карточках я показываю, как мы проводим интеграционные нагрузочные тесты прямо в продакшене
📖 А в статье на Хабре рассказываю:
🟢 Как мы распределяли нагрузку во время учений с учётом географии и пиковых сценариев
🟢 Почему выбрали эмуляторы для тестирования
🟢 Как оценивали результаты тестов на дашбордах
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend
На связи Андрей Матвеев, разработчик в команде платформы надёжности Яндекс Такси. А ещё я техлид проекта virtual-orders — нашей системы нагрузочных учений. С ней мы выявляем узкие места в архитектуре, определяем границы работоспособности и прогнозируем поведение сервиса в разных сценариях.
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤4🔥3🗿1