проектов с ними не сталкиваются. Зачем, зачем я захочу самоудаляющуюся запись?
А чем это хуже атрибута expires_at и хранения токена, чтобы потом можно было достать информацию о нем, а не вытаскивать её из логов?
Сорян, не понимаю о чем ты)
тем что когда токенов станет миллиарды, то всё это будет жрать место. И база будет пухнуть, потом потребуются индексы чтобы быстрее доставать непротухшие токены из этой разросшейся баз. Потом встанет вопрос как сделать так чтобы база была не в одном экземпляре, и был обеспечен HA в любом случае - есть кейсы, когда нужен быстрый шаред сторадж. И желательно с элементами HA
> есть кейсы, когда нужен быстрый шаред сторадж. И желательно с элементами HA а при чем тут ттл и редис?
тем что в редисе ттл встроен и он сам вычистит протухший ключ
а как ттл относится к необходимости быстрого шаред стораджа?
это если у тебя есть гарантии, что ключ протухает РАНЬШЕ протухания ТТЛ
охереть, а партиционирование в постгрес уже отменили
у меня 10 реплик одного и того же приложения. Каждое приложение использует токен, у которого есть срок жизни. Где мне хранить эти токены? СУБД не подходит
в конфигмапах кубера лол
То есть если редис упадет, то и токены отзвоутся? ой-вей
а получить его заного по апи нельзя типа? типа, ку вот мои креды дай мне токен
не всегда возможно. В противном случае не стоял бы вопрос где хранить общие данные
а кто выписывает их вообще? просто непонятно, например ОК юзает vault на 100500 юзверей, в вольте с этим нет проблем, в плане попросить новый ключик
разные апихи. у каждой свой подход. Кто-то выпишет новый токен и аннулирует тут же предыдущий. Соответственно 9 остальных реплик тут же перестанут работать
заебенить NATS который сообщит всем репликам что бы взяли новый токен
вот мы плавно и приходим к требованиям, которые могут (и возможно должны) быть реализованы в таком хранилище
или redis оставить, который в pub/sub умеет 😂
ну да, в этом плане нет разницы вроде бы ак
Обсуждают сегодня