Добрый день!

Пишу небольшой бот, и столкнулся с проблемой - где хранить произвольный контекст в формате json.
Хочу его запихать в колонку text рядом с записью соответствующего собеседника.

Таким образом при каждом сообщении это поле может перезаписываться - космоса там не будет, вряд ли выйдет за 500 символов, чаще будет 10-50 символов.

Но я в postgresql новичок, и не могу найти очевидных ответов на то, как БД будет вести себя в случае частого update по полю с типом text значениями переменной длины.

Не начнет ли у меня раздуваться база из-за частого устаревания старых значений в пользу записи новых?
Подскажите пожалуйста, как лучше поступить?

Karbafos,

я видел такой тип, но так же не нашел то, как он будет храниться.
Этот тип лишен таких проблем как text в части съедания места из-за частой перезаписи? (без настроек vacuum)

Scott Tiger,

Спасибо за разъяснения!

Правда вопросов только увеличилось...
ну а если пользователей будет 1 000, а если 10 000 ? хранить все в файлах?
Я думаю, что БД должна решить вопросы быстрого доступа к нужным данным лучше, чем файловая система...

Просто при написании бота нет такого понятия - как сессия, и поэтому надо эту самую сессию реализовать самому.
Храня в ней контекст, но только на стороне сервера. И это однозначно БД. Срок хранения может быть разным, от нескольких секунд до десятков минут.

Я возможно не прав, но пока не увидел альтернативного решения.

Или лучше так:

вообще реализовать отдельную таблицу для кэша (с json) с автовакуумом и fillfactor 50,
в качестве primary key взять значения primary key таблицы юзеров (без внешних ключей),
При каждой выдаче джоинить юзера с его кэшем.
Неактуальный кэш удалять раз в сутки.

Такое решение имеет место быть адекватным?

Scott Tiger,

автор1. Сессия, которую Вы хотите хранить до нескольких десятков минут, должна ли быть доступна с других экземпляров приложения? Или проще: у Вас кластер серверов обеспечивает работу этого бота или один сервер?
Один сервер

авторПри перезапуске сервера нужно ли сохранять состояние сессии на постоянном хранилище (диске, СУБД и т.п.) или его можно потерять без вреда?
Лучше хранить, меньше проверок в коде придется делать. Но если это значительно облегчит существование, то можно и восстанавливать кэши.

Scott Tiger,

огромное спасибо!
Redis - то что доктор прописал.

У меня работают два изолированных скрипта (один для вебхуков, второй параллельно сам инициирует коммуникации), и мне нужен такой посредник, который и будет кэшем заниматься... Redis самое то - не сталкивался еще с ним.