При написании чата кеш не нужен. Запросов к базе не так много. Горячая информация хранится в приложении. Вот я сейчас это сообщение отправлю и его получит более 5000 человек, к базе же будет запрос на запись, без чтения. Получение истории? Она кешируется на клиенте и 700 клиентов из этого чата сразу отправят моё сообщение в локальную базу. PostgreSQL отлично подходит для чата. По истории - каждый использует по своему. Мне в телеграмме не хватает календаря для удобной навигации. Часто могу и в переписку прошлого месяца и предыдущего полугодия залезть.
PostgreSQL был (и есть?) в основе скайпа, Дискорда (сейчас там кассандра). Объёмы телеграмма и вк требуют собственных движков. На ютубе есть доклад по базе сообщений вк, но начинать удобнее, быстрее и безопаснее с PostgreSQL. Потому что предугадать все варианты выборок не так просто. Кеш, кстати, тоже вносит ограничения на варианты выборок и может превратиться в inmemory копию базы без удобного и гибкого языка запросов

Итак:
— делаешь очень много апдейтов, пусть и на таблице смешного размера (у меня всего 20 мегабайт);
— пихаешь на слейв hot_standby_feedback = on, потому что когда-то тебе приспичило;
— дожидаешься, пока слейв начнет отставать;
— запросы на мастере начинают жрать CPU, фильтруя старые записи, но при этом тормозят не сильно, а так, чтобы не попадать в логирование медленных запросов — таблица-то маленькая;
— слейв догоняет тормозящего мастера, все восстанавливается;
— где-то между этими пунктами ты набираешь EXPLAIN ANALYZE (BUFFERS) и очень удивляешься, почему у тебя вместо пяти буферов сто тысяч.

> — делаешь очень много апдейтов, пусть и на таблице смешного размера (у меня всего 20 мегабайт);

таблица случаем не реализует нечто вроде очереди?

Я вообще предлагал именно горячую информацию (последние тысячи сообщений) хранить в Redis, а историю, если нужно - в PostgreSQL. Про кеширование я написал в целом, не конкретно про чаты. К тому, что в большинстве проектов одним PostgreSQL всё равно не обойдёшься.

Смотря среди каких проектов, наверное. Т.е. зависит от области применения / что кто видел и т.п.

Ну это да

Я не могу понять, что такое горячая информация в чате.
Примерный путь сообщения:
1. Клиент написал
2. Бекенд отправил событие в брокер сообщений
3. Сервис, ответственный за хранение, записал сообщение в базу
4. Сервисы, ответственные за доставку, отправили сообщение напрямую из брокера
5. Сообщение записывается в локальные базы клиентов

Вроде, для хранения сообщений в пункте 3 Постгреса хватает

Есть ещё получение истории/последних сообщений. Но, всю историю хранить не вариант, а последние 50 сообщений - разве для PostgreSQL сложно их достать?

Ну согласен, что тут всё довольно субъективно. Но я бы всё равно Редис использовал по нескольким причинам:
1) Выборка Redis всё равно будет быстрее
2) Зачем лишний раз ходить в базу, когда можно в неё не ходить?
3) В чатах не всегда нужна история (по крайней мере, полная). Если она не требуется, то зачем держать сообщения в базе постоянно? А если и не держать их там постоянно, а всё равно периодически чистить, то Redis для этой задачи, на мой взгляд, использовать проще

1. совсем не факт, что из Редиса удастся делать удобные выборки достаточно быстро
2. ходить все-равно куда-то надо будет, и надо еще создать ситацию, когда Редис будет оправдан
3. надо определиться видимо, кто как понимает чаты,
и видимо это пункт первый или даже нулевой :))

мое предложение - сначала определить паттерны использования информации, а уже потом думать, действительно ли для нее нужен какой-то промежуточно-кэширующий уровень.

так как гемора промежуточный уровень доставит порядочно

1) Насчёт удобных - согласен. Не то, что не быстро, а, скорее всего, будет просто неудобно.
2) Ну да, от ситуации зависит
3) Согласен

"так как гемора промежуточный уровень доставит порядочно" - и с этим тоже согласен) Убедил!))

а вот скорость тут ка раз надо померить, так как если паттерн использования - частая выборка последних сообщений (не факт что он такой нужен вообще), то постргрес такое тоже довольно шустро будет обрабатывать на прогретых кэшах

по поводу имено чата, я уже вроде упоминал centrifugo и вебсокеты не ней - такая штука действительно ускоряет чаты

потому что уже сама хорошо умеет работать с вебсокетами

IT Chats
ℹ️ Собираем IT-чаты, если у вас есть предложения по улучшению и/или исправлению канала, пишите нам: @itchats_bot 💬

🤝 Лучший способ нас поддержать – это поделится с нами информацией по теме, благодарим Вас! 😉

IT-каналы в @itchannels 📣
https://t.me/it_chats

Кто нибудь работал с Mc Access в sql режиме?

Я.

Имеете в виду adp?