Какой стек технологий выбрать для такого сайта? Дабы сразу не быть закиданным тапками, отмечу, что думаю над сайтом уже года пол. За это время успел написать основные методы api на php (lumen), а сейчас переписываю фронт со второго ангуляра на вью. Но самое главное - я так и не пришёл к понимаю, как правильно делать некоторые вещи. Для этого и пишу вопрос.
Теперь немного о сайте. Функционал типичный, в качестве примера можно рассматривать всем известный пикабу. Нагрузка, допустим, 6 млн просмотров в день.
Основной функционал:
1. Создание постов с тегами
2. Вывод постов по тегам
3. Наличие рейтинга у постов
4. Возможность постраничной выдачи лучших постов (за день/неделю/произвольный период)
5. Лента с горячими постами. Выдаётся тоже страницами.
6. Желательно при полном обновлении страницы скрывать посты, которые пользователь уже видел.
Самым сложным оказалось сделать грамотную ленту с горячими постами. Алгоритм ранжирования взял у реддита:https://medium.com/hacking-and-gonzo/how-reddit-ra...
Он достаточно прост, но вот правильно внедрить его, у меня пока не хватает знаний. Сейчас остановился на том, что раз в 20-30 минут крон запускает задание по ранжированию постов и проставляет им рейтинг. Допустим, так выглядит первая десятка горячих после выполнения задания:
#5 - 100 (номер поста, индекс горячести)
#1 - 95
#2 - 90
#3 - 85
#4 - 80
#6 (и т.д)
#7
#8
#9
#10
Потом пользователь запрашивает лучшие посты и ему выдают первые пять постов : 5, 1, 2, 3, 4. Пока он их смотрим, отрабатывает задание и мы получаем новый список горячих:
#7 - 120
#8 - 115
#5 - 110
#1 - 95
#2 - 90
#3
#4
#6
#9
#10
Пользователь запрашивает вторую пятерку лучших постов, и ему в ответ приходят посты #3, 4, 6, 9, 10. То есть ему будет отправлено два поста, которые он уже видел, и два поста #7 и #8 он пропустит, т.к. они уже вылезли в топ.
Конечно, можно сохранять посты, которые уже были отданы пользователю, номер сессии. А дальше скулем выгребать первые 1000 горячих постов, посты, которые уже были выданы пользователю, и отдавать первые 20 свежих постов. Но на такие подвиги, мне кажется, не хватит никакой производительности и дискового места.
Также непонятно, как хранить уже просмотренные пользователем посты. Не в скуле же?
Возможно, php и скуль уже устарели и для этой задачи логично использовать NoSQL и какой-нибудь node.js вместо php?
В общем, нужен совет знающего архитектора)
Какой стек технологий выбрать для такого сайта? Дабы сразу не быть закиданным тапками, отмечу, что думаю над сайтом уже года пол. За это время успел написать основные методы api на php (lumen), а сейчас переписываю фронт со второго ангуляра на вью. Но самое главное - я так и не пришёл к понимаю, как правильно делать некоторые вещи. Для этого и пишу вопрос.
Теперь немного о сайте. Функционал типичный, в качестве примера можно рассматривать всем известный пикабу. Нагрузка, допустим, 6 млн просмотров в день.
Основной функционал:
1. Создание постов с тегами
2. Вывод постов по тегам
3. Наличие рейтинга у постов
4. Возможность постраничной выдачи лучших постов (за день/неделю/произвольный период)
5. Лента с горячими постами. Выдаётся тоже страницами.
6. Желательно при полном обновлении страницы скрывать посты, которые пользователь уже видел.
Самым сложным оказалось сделать грамотную ленту с горячими постами. Алгоритм ранжирования взял у реддита:https://medium.com/hacking-and-gonzo/how-reddit-ra...
Он достаточно прост, но вот правильно внедрить его, у меня пока не хватает знаний. Сейчас остановился на том, что раз в 20-30 минут крон запускает задание по ранжированию постов и проставляет им рейтинг. Допустим, так выглядит первая десятка горячих после выполнения задания:
#5 - 100 (номер поста, индекс горячести)
#1 - 95
#2 - 90
#3 - 85
#4 - 80
#6 (и т.д)
#7
#8
#9
#10
Потом пользователь запрашивает лучшие посты и ему выдают первые пять постов : 5, 1, 2, 3, 4. Пока он их смотрим, отрабатывает задание и мы получаем новый список горячих:
#7 - 120
#8 - 115
#5 - 110
#1 - 95
#2 - 90
#3
#4
#6
#9
#10
Пользователь запрашивает вторую пятерку лучших постов, и ему в ответ приходят посты #3, 4, 6, 9, 10. То есть ему будет отправлено два поста, которые он уже видел, и два поста #7 и #8 он пропустит, т.к. они уже вылезли в топ.
Конечно, можно сохранять посты, которые уже были отданы пользователю, номер сессии. А дальше скулем выгребать первые 1000 горячих постов, посты, которые уже были выданы пользователю, и отдавать первые 20 свежих постов. Но на такие подвиги, мне кажется, не хватит никакой производительности и дискового места.
Также непонятно, как хранить уже просмотренные пользователем посты. Не в скуле же?
Возможно, php и скуль уже устарели и для этой задачи логично использовать NoSQL и какой-нибудь node.js вместо php?
В общем, нужен совет знающего архитектора)
Теперь немного о сайте. Функционал типичный, в качестве примера можно рассматривать всем известный пикабу. Нагрузка, допустим, 6 млн просмотров в день.
Основной функционал:
1. Создание постов с тегами
2. Вывод постов по тегам
3. Наличие рейтинга у постов
4. Возможность постраничной выдачи лучших постов (за день/неделю/произвольный период)
5. Лента с горячими постами. Выдаётся тоже страницами.
6. Желательно при полном обновлении страницы скрывать посты, которые пользователь уже видел.
Самым сложным оказалось сделать грамотную ленту с горячими постами. Алгоритм ранжирования взял у реддита:https://medium.com/hacking-and-gonzo/how-reddit-ra...
Он достаточно прост, но вот правильно внедрить его, у меня пока не хватает знаний. Сейчас остановился на том, что раз в 20-30 минут крон запускает задание по ранжированию постов и проставляет им рейтинг. Допустим, так выглядит первая десятка горячих после выполнения задания:
#5 - 100 (номер поста, индекс горячести)
#1 - 95
#2 - 90
#3 - 85
#4 - 80
#6 (и т.д)
#7
#8
#9
#10
Потом пользователь запрашивает лучшие посты и ему выдают первые пять постов : 5, 1, 2, 3, 4. Пока он их смотрим, отрабатывает задание и мы получаем новый список горячих:
#7 - 120
#8 - 115
#5 - 110
#1 - 95
#2 - 90
#3
#4
#6
#9
#10
Пользователь запрашивает вторую пятерку лучших постов, и ему в ответ приходят посты #3, 4, 6, 9, 10. То есть ему будет отправлено два поста, которые он уже видел, и два поста #7 и #8 он пропустит, т.к. они уже вылезли в топ.
Конечно, можно сохранять посты, которые уже были отданы пользователю, номер сессии. А дальше скулем выгребать первые 1000 горячих постов, посты, которые уже были выданы пользователю, и отдавать первые 20 свежих постов. Но на такие подвиги, мне кажется, не хватит никакой производительности и дискового места.
Также непонятно, как хранить уже просмотренные пользователем посты. Не в скуле же?
Возможно, php и скуль уже устарели и для этой задачи логично использовать NoSQL и какой-нибудь node.js вместо php?
В общем, нужен совет знающего архитектора)
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Для такого сайта с высокой нагрузкой и сложным алгоритмом ранжирования постов, вам стоит обратить внимание на следующие технологии:
База данных: вместо MySQL можно рассмотреть использование NoSQL базы данных, такой как MongoDB или Cassandra. Они могут эффективнее обрабатывать большие объемы данных и подходят для такого типа приложения.
Серверный язык: Node.js может быть хорошим выбором для вашего сайта, так как он позволяет обработать большое количество одновременных запросов за счет неблокирующего ввода/вывода.
Фронтенд: если вы уже начали переписывать фронтенд на Vue.js, то это также хороший выбор. Vue.js хорошо справляется с созданием динамических интерфейсов и удобен в использовании.
Кэширование: для эффективной работы с таким объемом данных и алгоритмом ранжирования, вам также потребуется хорошая система кэширования. Рассмотрите использование Redis для кэширования постов и результатов ранжирования.
Мониторинг и оптимизация: не забывайте о мониторинге производительности вашего сайта с помощью инструментов типа New Relic или Datadog. Также важно проводить оптимизацию кода и БД для снижения нагрузки на сервер.
Конечно, выбор технологий зависит от ваших предпочтений и специализации, но вышеописанные рекомендации могут помочь вам создать эффективный и масштабируемый сайт с функционалом, который вы описали.