Танец на канате: миграция без остановок, или Как мы подружили Mongo и PostgreSQL / Яндекс 360

В докладе расскажу про то, как мы в Диске переносили общие данные из нешардированного MongoDB в шардированный PostgreSQL. После переноса данных пользователей в шардированную БД у нас осталась часть данных про общие папки, которые было сложно изолировать внутри шарда пользователя. Спустя время общая БД не справлялась с нагрузкой: все операции перед выполнением должны сначала получить информацию об общих папках и только после этого начинать работать. Поэтому надо было дублировать информацию ближе к другим данным пользователей — в их шарды. Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода — у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и не потерять доступ к своим данным. При этом было необходимо выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функционал. При выкатке также нельзя было допустить downtime. В качестве решения мы разделили данные так, чтобы гостям не приходилось ходить куда-то, кроме своего шарда, а для согласованности данных с владельцем общей папки мы применили паттерн «сага» и любое изменение происходило таким образом, чтобы данные были доставлены в три базы: — к владельцу, — к гостю, — в общую MongoDB (для failback’а). Я подробно рассмотрю процесс записи в несколько инстансов БД без распределённых транзакций и миграцию с минимальными ограничениями для пользователей. Андрей Колнооченко, разработчик ядра бэкенда Яндекс Диска, Яндекс 360 О внутренней инфраструктуре Яндекса: Сайт: https://infra.yandex.ru/
Телеграм-канал: https://t.me/yandex_infrastructure