Size: a a a

2020 May 07

RS

Roman Sharkov in Go-go!
Vladislav Milenin
Да понятно что необязательно. Можно и на го key-val inmemory с ttl и бекапом данных устроить. Зачем только, если есть распространенный стандарт
внешний TTL тут совсем лишний, лишний раз усложнять не стоит
источник

Н

Никита in Go-go!
Vladislav Milenin
Обычно для авторизации запросов скорость работы важна. В случае с постгресом, например, проигрыш будет в десяток раз
Так у вас будет один запрос на авторизацию, и еще 5+ запросов в БД. Не играют роли те сэкономленные наносекунды
источник

Н

Никита in Go-go!
Roman Sharkov
не expiration date а creation date

таким образом вы динамически можете определить, устарела ли сессия или нет
Как вариант, да
источник

VM

Vladislav Milenin in Go-go!
Никита
Так у вас будет один запрос на авторизацию, и еще 5+ запросов в БД. Не играют роли те сэкономленные наносекунды
Речь не о наносекундах. И ничего не стоит избежать оверхеда на каждый запрос
источник

Н

Никита in Go-go!
Vladislav Milenin
Речь не о наносекундах. И ничего не стоит избежать оверхеда на каждый запрос
Тогда о чем?
источник

p

pragus in Go-go!
Никита
Добавьте поле expiration_date и проверяйте, вот и ТТЛ. Вы все равно ходите по сети, что в редис что в основную БД. Редис не выиграет существенно времени, зато добавит потенциальную точку отказа, без которой сервис работать не будет
у вас и без бд сервис работать не будет )
источник

Н

Никита in Go-go!
pragus
у вас и без бд сервис работать не будет )
Если упадет бд, то тут как бы понятно, что дела очень плохи)
источник

VM

Vladislav Milenin in Go-go!
pragus
у вас и без бд сервис работать не будет )
И без питания в стойке
источник

Н

Никита in Go-go!
Redis - оверкилл для простой проверки токенов
источник

x

x-foby in Go-go!
pragus
клиент - в терминах http. потому что http-балансер - это тоже ведь клиент
Это да
источник

VM

Vladislav Milenin in Go-go!
оверкилл ваше стремление преуменьшать показатели при нехватке опыта

у меня в бд с 1м записей index only scan по bigint полю занимает 170мс, с редиса чтение 10к записей занимает 200мс

Не верите - проверьте)
источник

Н

Никита in Go-go!
170мс? Это очень много
источник

Н

Никита in Go-go!
Тем более по индексу
источник

Н

Никита in Go-go!
1 миллион записей это несущественный объём, чтобы поиск занимал 170мс
источник

VM

Vladislav Milenin in Go-go!
в другой таблице по uuid 40мс. Все еще в 100 раз больше)
источник

DP

Daniel Podolsky in Go-go!
Vladislav Milenin
оверкилл ваше стремление преуменьшать показатели при нехватке опыта

у меня в бд с 1м записей index only scan по bigint полю занимает 170мс, с редиса чтение 10к записей занимает 200мс

Не верите - проверьте)
в какой БД?
источник

VM

Vladislav Milenin in Go-go!
Daniel Podolsky
в какой БД?
postgres
источник

x

x-foby in Go-go!
Vladislav Milenin
оверкилл ваше стремление преуменьшать показатели при нехватке опыта

у меня в бд с 1м записей index only scan по bigint полю занимает 170мс, с редиса чтение 10к записей занимает 200мс

Не верите - проверьте)
Вы так сразу на нехватку опыта ссылаетесь, как будто уверены, что его действительно мало у оппонента, а мы тут как будто уверены, что у вас он есть.

Когда придёт ТС и скажет: у меня тут сессии на БД стали бутылочным горлышком, тогда можно будет поговорить о решении этой проблемы.
Но зачем сходу так настаивать на своём варианте, если под него кейса изначально нет в вопросе?
источник

V

Vitaly in Go-go!
Вот вы тут обсуждаете где хранить токены - в редисе, в базе данных, считаете тайминги...
Внимание, вопрос - а какова плановая и какова теоретически возможная нагрузка?

Может там в среднем 1 запрос в минуту и 5 запросов в минуту в пике в идеальных условиях.
источник

DP

Daniel Podolsky in Go-go!
а что за запрос, и что на него говорит explain?
источник