KISS в архитектуре Нужен ли Redis? Сразу оговорюсь - оцениваю технологии с высоты собственного опыта на PHP и Java-стеке. Если есть идеи или мысли что я что-то упустил или не так посчитал - обязательно пишите в комменты, обсудим! Итак, давайте оценим Redis, как яркого представителя кэш систем, и оценим прирост производительности по сравнению с “только СУБД”. Не буду рассматривать сложные штуки, например дополнительные структуры типа списков, деревьев и блокировок. Предположу, что соотношение производительностей этих структур будет аналогичным. Итак, по оценке ChatGPT на среднем современном сервере производительность Redis при работе в режиме key-value с 80% read нагрузкой и 20% write составляет 420к операций в секунду. Аналогичный вариант при работе с 2 столбцами primaryKey + text в одной таблице в PostgreSQL сможет выдать ~82к операций в секунду при условии что таблица достаточного размера, чтоб находиться постоянно в памяти. Для меня эти оценки выглядят очень реалистичными. Давайте скажем, что Redis в любом режиме выдает 5х производительности по сравнению с СУБД размеры данных в которой позволяют им всегда находиться в кеше. Много это или мало? Думаю, что достаточно ответить на вопрос - много ли проектов на нашем опыте действительно упираются в производительность СУБД по живой нагрузке, а не по причине неправильных, причем зачастую аналитических, запросов. За 12 лет опыта работы видел такие проекты только на сценах конференций. Это конечно интересно но правда ли redis нужен на конкретно вашем сегодняшнем проекте? Те мои проекты, которые использовали memcached или redis, могли бы положить их в общую бд с тем же результатом и с минимальными просадками по скорости работы. В абсолютном большинстве проектов где я работал 99% нагрузки на реляционную БД генерируется аналитическими запросами, и даже в этих случаях общая нагрузка на БД редко превышает 20-50%, иначе запускается очередной цикл оптимизации аналитических запросов силами инженеров. В итоге, подозреваю, что 95-98% современных проектов могут легко обойтись без in-memory специализированных решений. Это позволяет тянуть меньше технологий в проект, упрощать схему инфраструктуры, уменьшать количество точек отказа, делать проще требования к новым инженерам. Звучит очень выгодно! А вы что думаете? ^^ P.S. я, конечно, тоже люблю делать производительные решения и достигать максимум возможного, но правда ли это нам надо на бизнес-проектах, которые не планирует пользоваться этой производительностью?