Но по content_id нельзя понять, когда он был опубликован. И точность нужна секундная - для построения истории.

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

Мне надо строить по юзеру историю просмотра, это не архитектурное решение, а продуктовое требование.

Ну кстати это наводит меня на мысль, да, что может быть если пожертвовать историей и дать юзерам вместо неё условно-вечные закладки...

Именно, конечно есть, https://www.postgresql.org/docs/10/ddl-partitioning.html

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

ну либо пиши на диск по юзеру fifo, конда оператива кончится

если просто сохранять историю для всяких анализов ml и прочего, то это резко все упрощает, сгружай в тот же clickhouse/vertica/druid и тд и все

Нет, это именно юзеру нужно отдавать.

короче, даже в этой ситуации практически все что угодно будет лучше монги )

Даже если так ее можно генерить он demand и какое то время хранить, врядли это часто используемая функция

...квантор всеобщности, символ включения - значит Постгря тоже будет лучше?

С кликхаусом есть такая проблема: в него надо писать пачками сильно больше чем по 10 строк, чтобы безболезненно хранить в нём полтора триллиона записей. То есть бОльшую часть времени он будет неконсистентен.

А также это значит, что задачу "отфильтруй из списка тот контент, который уже был прочитан" мы всё равно должны решать при помощи какого-то другого инструмента. Так мы получаем связку "другой инструмент + кликхаус", а зачем, если можно просто хранить таймштампы в этом же "другом инструменте"?

можно buffered table на входе сделать, это решит запись пачками и чтение актуальных данных тоже

это подход c hot/cold storage для таких задач более правильный, но в целом если это не коре бизнес твоего сервиса то похер на чем, лишь бы работало)

ну я ж тебе говорю - можно сделать unlogged таблицу и хранить ее в оперативе вместе с индексами.

даже mysql с handler socket будет лучше.

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

кликхаус тут можно натянуть, но он не потянет 3к чтений в секунду. он не для этого.

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

Лучше - это меньше чем 5 шардов по 3 реплики, например)

кстати, на весь твой проект надо ВСЕГО 250 гигов, а не 250 гигов в месяц.

лучше )