TGViewer
ТехнофITнес | Никита Ульшин ТехнофITнес | Никита Ульшин @tech_fit · 262 subscribers
Post #50 294
Секреты стройности монолита: подходы по снятию нагрузки с БД

Одна из причин, почему команды начинают переходить на микросервисы — основная БД захлёбывается под нагрузкой. Масштабировать stateless-сервисы просто, с базой же это делать гораздо сложнее.

В очередной интересной статье инженеры Яндекса разбирают, как можно снизить нагрузку на БД, которая и так уже работает на ~100K RPS, и как её аккуратно распилить на части.

⭐️ Интересные идеи

➡️ Первое, с чего стоит начать — тщательный анализ долгих запросов. Инженеры Яндекса написали для этого свой парсер логов. Это позволило выявить плохо написанные запросы и быстро их поправить, получив буст к производительности.

➡️ Анализ логов также помог узнать, какие таблицы являются самыми нагруженными и востребованными. Выносить в сервисы было долго, поэтому инженеры приняли решение выделить эти таблицы в отдельные базы.

➡️ Интересен также процесс выбора таких таблиц: они должны быть достаточно нагруженными, не слишком сильно связаны с другими таблицами и к ним не должно быть слишком специфичных запросов (попутно ещё и с MySQL на PostgreSQL переезжали).

➡️ Эксперимент пришлось несколько раз откатывать из-за особенностей инфраструктуры. В первом релизе не хватило воркеров, потому что их количество в Яндекс Облаке фиксировано для выбранного флейвора, и двойная запись быстро их исчерпала. Во втором случае master переехал в другой ДЦ, и система несколько минут пыталась писать в slave — с печальными последствиями.

➡️ Была проделана большая работа по очистке базы (потому что исходный вес был 4 ТБ): анализ и удаление исторических данных, анализ неиспользуемых таблиц, даже лишние индексы почистили. В итоге удалось значительно сократить объём занимаемого на диске пространства.

➡️ Финальный аккорд — после выяснения требований оказалось, что не нужно хранить в основной БД данные о заказах старше одного месяца, потому что они используются в основном для аналитики и выборочных проверок. Это позволило уменьшить размер БД до целевого значения в 750 ГБ.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи
  • 👍 5
  • ⚡ 2
  • 🔥 2
More from @tech_fit
  1. Oct 13, 2025Почему Uber переехал с Postgres на MySQL Интересная статья о том, какие проблемы в Postgre…
  2. Oct 6, 2025Паттерн Bulkhead Продолжаю читать статьи про паттерны отказоустойчивых приложений. На очер…
  3. Oct 1, 2025Как сервера договариваются друг с другом: алгоритм распределённого консенсуса Raft Распред…
  4. Sep 29, 2025Микросервисы не подходят стартапам Интересная статья, которая в очередной раз напоминает о…
  5. Aug 25, 2025Сколько партиций в Kafka мне нужно? Партиции — это одна из важнейших частей Kafka. С их по…
  6. Aug 18, 2025Роадмап архитектора Как вы знаете, иногда я тут делюсь не обзорчиками, а вполне прикладным…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →