Сохранить идентификаторы в Redis отсортированном наборе, а затем выбрать значение из Postgresql?

Question

для лучшей производительности разбивки на страницы, вместо того, чтобы делать это в postgresql:

SELECT * FROM message ORDER BY created_at DESC limit 30 offset 30;

Можно ли сохранить идентификаторы в отсортированном наборе redis, а затем просто получить идентификаторы из redis по:

ZREVRANGE message_ids 30 39

И затем запросите эти идентификаторы в postgresql, чтобы получить значения.

Причина, по которой я не сохраняю значение непосредственно в Redis, заключается в том, что оно может быть большим, а оперативная память дорогой.(Мне не хватает оперативной памяти).

Если это рекомендовано или ОК для повышения производительности, как я могу правильно запросить значения из postgresql по идентификаторам?

Я нашел следующие способы и не уверен, что это лучший подход:

SELECT m.*
FROM   unnest('{17579, 17580, 17582}'::int[]) id
JOIN   message m USING (id);

ИЛИ просто:

SELECT * FROM message WHERE id IN (17579, 17580, 17582);

Вышеприведенный запрос отэта ссылка

Кстати, я также не уверен, что приведенная выше команда выдаст мне правильный порядок, основанный на порядке списка идентификаторов и нужно ли мне ORDER BY id в конце.

В итоге, будет ли это решение redis + postgresql намного быстрее, чем только решение postgresql?

Answer 1

В итоге, будет ли это решение redis + postgresql намного быстрее, чем только решение postgresql?

По моему мнению, конечный результат не будет стоить усилий / сложности, которые выввести в систему.

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

В предложенном вами решении произойдет следующеев то время как приложение пытается обслуживать страницу (это веб-приложение, верно?):

• tcp вызов redis для получения запроса ids
• frame sql с идентификаторами
• sql-запрос по другому tcp-вызову.

Для сравнения, в базу данных отправляется только один sql-запрос, если мы выбираем прямой путь.

Тем временем также рассмотримусилия по разработке, связанные с обеспечением того, чтобы идентификаторы, переданные в redis, оставались согласованными с сервером базы данных.

---

Тем не менее, если ваша база данныхСервер находится под большой нагрузкой, и вам нужно взять на себя часть бремени, которое вы могли бы рассмотреть, включив в свой стек приложенияasticsearch / solr.

• Вам все равно придется обеспечить согласованность между базой данных и elasicsearch /Solr.И если ваш сценарий использования позволяет, вы можете связать его с фоновой работой.
• Ваши запросы на чтение редко попадут на ваш сервер базы данных.
• Elasticsearch / solr использует жесткий диск для хранения данных: чрезмерное количество оперативной памяти не потребуется.

---

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