В условиях highload сложность оптимизации реляционных баз данных возрастает на порядок, так как покупка ещё более мощного железа обходится дорого а также уже нет возможности просто выключить приложение ночью для долгого процесса альтера БД и миграции данных.

Недавно мы рассказали, как мы оптимизировали PHP-код нашего приложения. Теперь же пришёл черёд статьи про то, как мы полностью изменили внутреннюю структуру самой нагруженной и важной базы данных в Badoo, не потеряв при этом ни одного запроса.

Привет Хабр!

Меня зовут Алексей Солодкий, я PHP-разработчик в компании Badoo. И сегодня я поделюсь текстовой версией моего доклада для первого Badoo PHP Meetup. Видео этого и других докладов с митапа можно найти здесь.

Любая система, состоящая хотя бы из двух компонентов (а если у вас есть и PHP, и база данных, то это уже два компонента), сталкивается с целыми классами рисков во взаимодействии между этими компонентами.

Отдел платформы, в котором я работаю, интегрирует новые внутренние сервисы с нашим приложением. И решая эти задачи, мы накопили опыт, которым я и хочу поделиться.

Наш бэкенд — это PHP-монолит, взаимодействующий со множеством сервисов (самописных из них сейчас порядка пятидесяти). Между собой сервисы взаимодействуют редко. Но проблемы, о которых я говорю в статье, также актуальны для микросервисной архитектуры. Ведь в этом случае сервисы очень активно взаимодействуют друг с другом, а чем больше у вас взаимодействия, тем больше у вас проблем.

Рассмотрим, что делать, когда сервис падает или тупит, как организовать сбор метрик и что делать, когда всё вышесказанное вас не спасёт.