Python на самом деле является отличным языком для создания потоков активности и новостных лент. Томмазо и я написали пакет Stream Framework. https://github.com/tschellenbach/stream-framework В настоящее время это наиболее часто используемое решение Python для создания новостных лент. Мы также предлагаем размещенное решение по адресу https://getstream.io. С клиентом Django проще всего начать работу: https://github.com/GetStream/stream-django. и python можно найти здесь (https://github.com/getstream/stream-python)
Шаблонная часть работает так
{% load stream_django %}
{% for activity in activities %}
{% render_activity activity %}
{% endfor %}
Это отобразит шаблон, расположенный в файле activity/tweet.html, с действием в качестве контекста. Например
{{ activity.actor.username }} said "{{ activity.object.body }} {{ activity.created_at|timesince }} ago"
Полная документация находится здесь: https://github.com/GetStream/stream-django#templating.
Stream Framework позволяет создавать новостные ленты любого типа с помощью Redis или Cassandra. Он масштабируется и создает отдельные новостные ленты, используя процесс разветвления.
Помимо Stream Framework (который я, очевидно, предпочитаю), существует множество других решений. Полный список доступен в пакетах django: https://www.djangopackages.com/grids/g/activities/ а>
Обратите внимание, что при работе с новостными лентами необходимо помнить о некоторых проблемах с масштабированием. В целом есть 3 распространенных подхода:
Стратегии денормализации
Потяните Большинство пользователей начинают именно так. Когда вы открываете страницу канала, вы просто запрашиваете каналы всех пользователей, на которых вы подписаны. Если каналы пользователей хранятся в памяти, это будет продолжать работать в течение достаточно долгого времени. В конце концов, довольно сложно продолжать использовать такую стратегию, поскольку вам часто приходится запрашивать большинство узлов, хранящих каналы вашего пользователя.
Push При использовании push информация о ваших действиях записывается во все фиды подписчиков. Конечно, это означает, что вы тратите массу ресурсов впустую, но конечным результатом является заранее рассчитанный фид для каждого пользователя. Этот подход (хотя изначально и не очень эффективный) хорошо масштабируется.
Комбинация В некоторых оптимизированных системах используется комбинация этих двух подходов. Также см. документ Yahoo по этой теме.
Варианты хранения
С точки зрения хранения всех этих данных наиболее распространенными вариантами являются Redis, Cassandra и MongoDB. Давайте быстро сравним их:
Redis Redis чрезвычайно прост в настройке и обслуживании. Однако он хранит данные только в памяти. Это означает, что вам придется оптимизировать способ сериализации данных и, возможно, вернуться к базе данных для менее часто запрашиваемых данных. Другая проблема заключается в том, что добавить машины в ваш кластер Redis непросто.
MongoDB Mongo DB в основном используется несколькими проектами ruby, а также доступна в качестве серверной части для pump.io от e14n. Я лично никогда не запускал его в продакшене, поэтому не могу правильно оценить этот вариант. Однако есть много сообщений в блогах, посвященных проблемам производительности, масштабируемости и удобства обслуживания mongo.
Cassandra Fashiolista, Instagram и Spotify используют Cassandra. Наше размещенное решение также использует Cassandra в качестве серверной части. Эксплуатация чрезвычайно экономична, и вы можете легко добавить больше узлов. Единственная проблема в том, что его сложно настроить и поддерживать.
Статьи
Кроме того, взгляните на эту публикацию о высокой масштабируемости, в которой мы объясняем некоторые связанные с проектом решения: http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html
Чтобы узнать больше о дизайне каналов, я настоятельно рекомендую прочитать некоторые статьи, на которых мы основывали Feedly:
person
Thierry
schedule
07.10.2014