В рекомендательное ленте используется МЛ-механизм для подбора постов. Сейчас он подбирает посты, которые не попадают в интересы пользователей. Это проблема и её исправляют.
В Монго удобнее работа с вложенными объектами, можно за один запрос найти все объекты с определенной новостью. В статье подробнее рассказал о преимуществах.
Чисто технически можно решить задачу и на sql и хранить также готовые ленты в реляционных таблицах
В статье это объяснил – с NoSQL удобнее обновлять и очищать данные. Для таблиц придётся делать ровно ту же логику, хранить и поддерживать бизнес-логику в коде удобнее, чем в триггерах.
Тоже вариант, но тогда получится что в ленте могут удалиться все новости и нечего будет показывать + появится лишняя логика при каждой выдаче (придётся не просто получить новость, а ещё вытаскивать все подписки пользователя и считать показывать ли новость)
Чтоб сформировать единый RSS для юзера нужно решить ту же самую задачу. RSS это просто формат выдачи в данном случае. У нас фактически такой же RSS, только в JSON формате.
Для iPhone есть похожее приложение Dragon Dictation, распознает голос, а потом сразу можно запостить текст в Твиттер или другие соцсети, вдруг кому-то будет полезно.
Это перевод статьи, наверно вопрос к автору. Могу предположить, что он добавил в подборку одно расширение для проверки почты и решил другие не добавлять.
Например, в Монго есть удобные операторы для поиска внутри объекта или для обновления части данных внутри json.
SQL плохо работает с json полями, там по сути надо всё поле обновлять.
Персональная лента с новостями есть в приложении, на сайте фильтр только по постам. Возможно в будущем и на сайте добавится.
Там есть запросы на выборку и обновление документов, которых нет в реляционных БД. Потому что Монго построена для работы с документами.
В рекомендательное ленте используется МЛ-механизм для подбора постов. Сейчас он подбирает посты, которые не попадают в интересы пользователей. Это проблема и её исправляют.
Да, вы правы, это рекомендательная лента. Текущий алгоритм работает не идеально, о проблемах коллеги знают и прям сейчас ими занимаются.
В Монго удобнее работа с вложенными объектами, можно за один запрос найти все объекты с определенной новостью. В статье подробнее рассказал о преимуществах.
Чисто технически можно решить задачу и на sql и хранить также готовые ленты в реляционных таблицах
Кликхауз очень плохо работает с частым обновлением
В статье это объяснил – с NoSQL удобнее обновлять и очищать данные. Для таблиц придётся делать ровно ту же логику, хранить и поддерживать бизнес-логику в коде удобнее, чем в триггерах.
Тоже вариант, но тогда получится что в ленте могут удалиться все новости и нечего будет показывать + появится лишняя логика при каждой выдаче (придётся не просто получить новость, а ещё вытаскивать все подписки пользователя и считать показывать ли новость)
Чтоб сформировать единый RSS для юзера нужно решить ту же самую задачу. RSS это просто формат выдачи в данном случае. У нас фактически такой же RSS, только в JSON формате.
Стоит добавить, что у них адекватные разработчики и им можно писать по поводу багов или фич, поправят.
Почему нельзя написать так?