[Перевод] Путь к масштабированию PostgreSQL: от теории к практике
"Postgres масштабируется" - нет других двух слов, которые вызывали бы больше споров. По крайней мере, в кругах, где я общаюсь, в подвале компании, где инфраструктурные эльфы заставляют Rails-приложение работать. Многие верят, вопреки всему и маркетинговым кампаниям Big NoSQL, что знакомая технология лучше, чем новый неизвестный инструмент, о котором только что рассказали на совещании руководства. Честно говоря, я понимаю их позицию. Заставить Postgres писать больше данных может быть сложно. Вам нужно больше оборудования. В большинстве случаев его можно получить, просто нажав кнопку "Обновить". Но когда вы дошли до экземпляра r5.24xlarge с 5 репликами такого же размера, и ваши процессы vacuum всё ещё отстают от графика, ситуация становится довольно пугающей. Именно здесь начинается испытание для настоящего инженера. На пределе возможностей. Я говорю не о WebAssembly . Я говорю об инженерном духе, который смотрит на проблему под давлением руководства и вместо того, чтобы бежать к ближайшей команде продаж с большими обещаниями (но малым количеством фактов о вашем конкретном случае), решает её, используя базовые принципы. А базовый принцип говорит нам, что нам нужно. У Postgres закончилась пропускная способность для записи. Либо из-за блокировок при работе с WAL , либо что-то застопорило vacuum. Вероятно, это та неактивная транзакция, которая открыта уже 45 секунд, пока приложение делает запрос к Stripe, но это не наша забота. Мы - инфраструктурная команда, и наша задача - заставить базу данных работать.
https://habr.com/ru/articles/891122/
#postgresql #шардинг #масштабирование_postgresql #репликация_базы_данных #отказоустойчивость #высокие_нагрузки #базы_данных #devops #оптимизация #инфраструктура