Что быстрее- хранить значения в памяти Golang или Redis?

Question

[Роман Ракзин]

Golang довольно быстрый, по сравнению с другими языками.
Вот стало интересно- что будет быстрее- хранить большое количество данным в переменных/картах на go или обращаться к серверу Redis, так как он очень быстрый, да и предоставляет кучу готовых функций, которые б для выборки на go ещё нужно было бы писать.
Кто-то сталкивался с подобным?

Answer 1

[Никита]

Конечно быстрее у себя хранить прям в программе, но редиска ведь даёт большие возможности для простого хранения данных. Вам так или иначе придётся писать какую-то обёрточку, которая хранит в массивах и мапах данные, а это лишняя трата времени и о других тоже подумать стоит (даже о себе через какое-то время), ведь пока разберёшься что понаписали уже день пройдёт. А редиску все знают.

Answer 2

[uvelichitel]

Хранилища используют для хранения, для многократного использования возможно несколькими приложениями. Внутренние данные приложения не сохраняются даже при простом перезапуске.

Answer 3

[Папа Стифлера]

Внутренний in-process кеш будет сильно быстрее хотя бы потому, что не будет нужды заниматься сериализацией/десериализацией данных.

Answer 4

[Oleksiy Chechel]

В какой ситуации Redis или похожие инструменты стоит использовать.

Допустим, оперативные данные - цифра открытых соединений в определенный момент времени. Решается на уровне приложения просто, создаем переменную-счетчик, при открытии соединения увеличиваем, при закрытии - уменьшаем. Но с ростом нагрузки, приходится запустить несколько экземпляров приложения на нескольких серверах. Теперь в каждом экземпляре - разные счетчики и разные значения. Но если использовать внешнее хранилище - счетчик будет содержать общую цифру соединений.
Второй случай - нужна сохранность данных в кеше при перезапуске/падении приложения. Например, тот-же счетчик, но уже не открытых соединений, а посетителей за сегодня. После каждого перезапуска терять данные нельзя.
Третий случай - использование специфичных хранилищ, типа HyperLogLog в редисе.