Как организовать хранение гостевых данных в интернет-магазине?
Есть интернет-магазин на Laravel, для зарегистрированных пользователей хранение избранных товаров, корзины, просмотренных товаров происходит в PosgreSQL, необходимо такую же логику перенести на гостевых пользователей, но так как у гостя нет никаких данных в бд, кроме session_id или токена, который я ему генерирую и сохраняю в куки), возникла потребность в реализации хранения гостевых данных в key-value базе данных. Сначала выбор пал на Redis, но так как одна из особенностей хранения гостевых данных заключается в том, что эти данные нужно хранить пару месяцев (может больше), то есть гость (при сохраненном токене в куки), должен теоретически иметь возможность посмотреть свою корзину или избранное и через месяц-два, пришло понимание, что Redis для этих целей не особо подходит, так как данные хранятся в оперативной памяти.
Для key-value хранения на SSD есть MongoDB, которую сейчас рассматриваю как доп базу данных к основной на PostgreSQL, используемую для гостевых данных, но никогда подобную историю не реализовывал. Отсюда основной вопрос:
правильны ли мои мысли по поводу MongoDB в качестве дополнительной базы данных или нужно использовать что-то другое? Или просто сделать отдельную таблицу в посгресе типа guest_cart, guest_favorites (но тут уже могут быть нюансы при автоудалении большого кол-ва просроченных (неактульных) записей)?
1. Redis умеет в persistence и позволяет сбрасывать данные на диске и хранить их там. Было бы желание
2. Postgres умеет в json и создать там таблицу session_id, content json не вопрос. И если у вас HDD + SSD через tablespaces конкретно ее можно вынести на SSD.
Вы как то много написали что вы хотите выбрать из БД, как хранить - но очень мало описали что именно вы собираетесь хранить и как часто хотите это выбирать - а это основной вопрос
А почему по простому не решаете? (допустим, если у вас не высокие нагрузки на базу).
Записываете уник сессию гостя в базу (это дает еще много прикольных штук).
Записываете в таблицы, типа guest_cart, guest_favorites и любые другие таблицы.
По необходимости мигрируете из этих таблиц данные в основную запись пользователя, если он зарегистрируется.
Записываете last_action_ts в сессию бд. И стираете раз в день данные, если last_action_ts уже старше чем 2 месяца.
Это один из вариантов, если использовать postgres, да. Такой подход в целом жизнеспособен, смущает лишь то, что на каждый новый тип данных (если что-то новое надо будет хранить кроме корзины, избранного и просмотренного), придется делать новую таблицу, хотелось сразу это вынести в отдельную базу.
ну, по сути, вы можете записать пользователей сессии к пользователям с меткой -1 (минус ID), или добавить маркеры, что это пользователи сессии.
И вести их уже как настоящих временных пользователей. со всеми функциями , что у вас будут.
Даже имя им дать, например как в гугл таблицах - Неопознанный зеленый лев)
Хранение на сервере данных - еще может давать крутой плюс в виде прогрева клиента.
Простой пример - вы статистикой замечаете, что пользователь смотрит один и тот же товар уже 5 дней из 7.
Ну так дайте ему скидку в 5-10%, и этот лид ваш вместе с регистрацией и другой механикой прогрева.
Алексей Скляров а, ну тогда да, сохраняйте в либо основную либо в дополнительную БД. Redis на самом деле тоже вполне можно использовать - только запускать его отдельным инстансом в облаке и не трогать лишний раз. Он спокойно месяцами и более может работать.
Простой
Средний
