ну то есть сама формулировка не исключает, что Руби был похоронен во всех этих стартапах еще до того, как начала писаться статья

угу

ключевые слова в статье https://poolp.org/images/2019-08-30-tweet_2.png

дак они еще все из долины

не 100, а 35

php 0.8B valuation

bruh

не. stripe же на руби и монге )

ну тогда можно подключать

что “не”? исключает?:)

я точно знчю что они сейчас на этом

да это понятно

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

Давай обстрагируемся немного, представь что у тебя только 1 юзер, и он смотрит контент, смотреть он его может конечно и не в хронологическом порядке наприммер посмотрел c9, потом с5, c6, c4, c7, c8. Теперь если ты можешь хранить просмотренный контент в хронологическом порядке его создания с1 … cN, тебе приходит запрос на фильтрацию нового контента к примеру c5 - c35, ты сразу понимаешь что последний просмотренный контент c9, отбрасываешь все что новее как точно не просмотренное и только c5 - c9 нужно проверить есть ли в нашем наборе данных, так как набор данных упорядочен, ты можешь делать это очень эффективно не перебирая всю историю. Утрированно например двоичный поиск с5 и далее от него и до конца истории проходишь по куску данных.

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

Да, но контент от рекоммендера поступает не в том порядке, в каком он был опубликован. На то он и рекоммендер. Он вообще может взять и рекомендовать что-то двухнедельной давности на основании смайла, который ты поставил 5 минут назад.

Ну то есть можно использовать для первичной фильтрации, наверное.

а это не важно, можно отсортировать перед проверкой там небольшие размеры данных

Далее, 10 байт content id символьно цифровых можно упаковать в 60 бит прицепить к ним таймстамп 32 бита = 12 байт, если начать хранить данные в бакетах по юзеру то оне надо будет хранить user id и тут экономия получится неплохая

Звучит как хорошая оптимизация: держать где-то в Редисе для всех юзеров первый и последний прочитанные content_id, и фильтровать список перед чтением. Спасибо!