Под микросервисами здесь скорее подразумеваются любые потребители данных, а не строгое определение микросервисной архитектуры с отдельной БД на каждый сервис.
Основная мысль была в другом: PostgreSQL выступает источником правды, и в какой-то момент к нему начинает приходить не только транзакционная нагрузка, но и большое количество запросов на чтение от разных систем.
Поэтому вопрос был не столько в записи данных, сколько в том, что разные сервисы постоянно читают и собирают одни и те же данные.
Собственно, эту часть нагрузки и предлагается вынести отдельно. PostgreSQL остаётся мастер-системой, а контур чтения берёт на себя повторяющиеся запросы, чтобы не масштабировать основную БД только из-за роста нагрузки на чтение.
Проблема была не в плохом запросе или непонимании, как работает PostgreSQL. Это типичная история растущих систем: сервисов становится больше, нагрузка на чтение растёт, и PostgreSQL начинает тратить всё больше ресурсов на выдачу одних и тех же данных разным потребителям.
Поэтому вопрос был не что оптимизировать?, а зачем каждый сервис постоянно ходит в источник правды за данными, которые можно подготовить один раз и отдавать из отдельного контура чтения? Собственно, об этом и статья. PostgreSQL остаётся системой хранения и транзакций, а контур чтения выносится отдельно, чтобы не масштабировать основную БД только из-за роста количества запросов.
Сейчас у нас реализован частный случай охлаждения — архивирование. Оно может происходить, например, по статусу или дате. При этом мы пока не отслеживаем, насколько данные «горячие» или «холодные». Как только начнём внедрять механизм нагрева, тогда и появится логика отслеживания обращений к данным.
Да, схема намеренно упрощена.
Под микросервисами здесь скорее подразумеваются любые потребители данных, а не строгое определение микросервисной архитектуры с отдельной БД на каждый сервис.
Основная мысль была в другом: PostgreSQL выступает источником правды, и в какой-то момент к нему начинает приходить не только транзакционная нагрузка, но и большое количество запросов на чтение от разных систем.
Поэтому вопрос был не столько в записи данных, сколько в том, что разные сервисы постоянно читают и собирают одни и те же данные.
Собственно, эту часть нагрузки и предлагается вынести отдельно. PostgreSQL остаётся мастер-системой, а контур чтения берёт на себя повторяющиеся запросы, чтобы не масштабировать основную БД только из-за роста нагрузки на чтение.
Проблема была не в плохом запросе или непонимании, как работает PostgreSQL. Это типичная история растущих систем: сервисов становится больше, нагрузка на чтение растёт, и PostgreSQL начинает тратить всё больше ресурсов на выдачу одних и тех же данных разным потребителям.
Поэтому вопрос был не что оптимизировать?, а зачем каждый сервис постоянно ходит в источник правды за данными, которые можно подготовить один раз и отдавать из отдельного контура чтения? Собственно, об этом и статья. PostgreSQL остаётся системой хранения и транзакций, а контур чтения выносится отдельно, чтобы не масштабировать основную БД только из-за роста количества запросов.
Сейчас у нас реализован частный случай охлаждения — архивирование. Оно может происходить, например, по статусу или дате. При этом мы пока не отслеживаем, насколько данные «горячие» или «холодные». Как только начнём внедрять механизм нагрева, тогда и появится логика отслеживания обращений к данным.