История изменений
Исправление KivApple, (текущая версия) :
Гугли N + 1 query problem.
Решение заключается в том, что тебе нужно, чтобы вместо get_author_by_id был get_authors_by_ids, вместо get_region_by_id был get_regions_by_ids и т. д. То есть в каждом сервисе должен быть метод для массового получения объектов по списку id.
Тогда ты сначала получаешь список новостей, а затем из него через iter().map().collect() делаешь списки id связанных ресурсов, запрашиваешь сразу все обходимые ресурсы каждого типа, потом строишь из каждого такого списка HashMap (в качестве ключа будет id связанного ресурса) и пробегаешься по новостям уже доставая необходимые данные из HashMap вместо запроса к другому сервису на каждую новость, потому что все данные у тебя уже есть.
И теперь у тебя 8 запросов вне зависимости от количества новостей. Но надо, чтобы каждый сервис отдающий дополнительные данные умел искать по списку id вместо одного (не знаю как Эластик, но в том же SQL есть оператор IN позволяющий искать по вхождению элемента в список вместо обычного равенства). Если такой функционал в него добавить нельзя, то задача нерешаема и тебе придётся делать твои 240 запросов (хотя можно попытаться кешировать ответы хотя бы).
Исправление KivApple, :
Гугли N + 1 query problem.
Решение заключается в том, что тебе нужно, чтобы вместо get_author_by_id был get_authors_by_ids, вместо get_region_by_id был get_regions_by_ids и т. д. То есть в каждом сервисе должен быть метод для массового получения объектов по списку id.
Тогда ты сначала получаешь список новостей, а затем из него через iter().map().collect() делаешь списки id связанных ресурсов, запрашиваешь сразу все обходимые ресурсы каждого типа, потом строишь из каждого такого списка HashMap и пробегаешься по новостям уже доставая необходимые данные из HashMap вместо запроса к другому сервису на каждую новость, потому что все данные у тебя уже есть.
И теперь у тебя 8 запросов вне зависимости от количества новостей. Но надо, чтобы каждый сервис отдающий дополнительные данные умел искать по списку id вместо одного (не знаю как Эластик, но в том же SQL есть оператор IN позволяющий искать по вхождению элемента в список вместо обычного равенства). Если такой функционал в него добавить нельзя, то задача нерешаема и тебе придётся делать твои 240 запросов (хотя можно попытаться кешировать ответы хотя бы).
Исходная версия KivApple, :
Гугли N + 1 query problem.
Решение заключается в том, что тебе нужно, чтобы вместо get_author_by_id был get_authors_by_ids, вместо get_region_by_id был get_regions_by_ids и т. д. То есть в каждом сервисе должен быть метод для массового получения объектов по списку id.
Тогда ты сначала получаешь список новостей, а затем из него через iter().map().collect() делаешь списки id связанных ресурсов, запрашиваешь сразу все обходимые ресурсы каждого типа, потом строишь из каждого такого списка HashMap и пробегаешься по новостям уже доставая необходимые данные из HashMap вместо запроса к другому сервису.
И теперь у тебя 8 запросов вне зависимости от количества новостей. Но надо, чтобы каждый сервис отдающий дополнительные данные умел искать по списку id вместо одного (не знаю как Эластик, но в том же SQL есть оператор IN позволяющий искать по вхождению элемента в список вместо обычного равенства). Если такой функционал в него добавить нельзя, то задача нерешаема и тебе придётся делать твои 240 запросов (хотя можно попытаться кешировать ответы хотя бы).