Может быть вопрос будет немного не в тему, но все же попробую задать. У меня тоже есть идея сделать телеграм бота с некоторой функциональностью, но меня останавливает один момент — я не знаю как его продвигать. Может поделитесь опытом?
Тут еще подумал про вопрос: Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени?
Думаю сильно зависит от структуры хранения, если в качестве бд что то «привычное» (sql, популярные nosql), то ожидание скорее всего будет долгим.
Если же в качестве хранилища у нас граф(какая-то графовая база, например, с ребрами по подпискам и от пользователей к постам), то какое-то ожидание вообще может исчезнуть.
Попробую ответить.
1. Если лента каждый раз будет строиться в реальном времени, при большом количестве подписок можно вообще не дождаться. Закешированная версия живет, положим, 2 недели, TTL = 14 дней. К обновлению ленты приводят события: подписка, отписка, создание поста теми на кого мы подписаны, удаление поста, удаление пользователя.
2. Представим что у нас распределенное дешевое хранилище и место не ограничено. Необязательно хранить всю ленту, можно хранить некоторую промежуточную структуру из которой можно быстро построить ленту. Можно не хранить ленту для пользователей, которые не заходили в систему 1 год.
3. Для популярных пользователей можно вынести обработку в отдельный воркер, чтобы не тормозить середнячков.
Предположим что посты в ленте должны шафлиться по какому-то алгоритму.
1) Собираем в реалтайме? Если да, то что используем?
2) Делаем предагрегацию? Если да, то что используем?
3) Что то другое.
Спрашиваю потому что недавно была такая задача и хочется сравнить свое решение с чьим то еще, ну и понять в ту ли сторону вообще пошел.
Да, без него не ставятся некоторые пакеты npm. Сейчас пробую завести апп на ubuntu 16.04 с последней монгой, посмотрю что получится. Но с пакетам из npm гемор еще тот конечно.
Конечно же нет. Данные можно вставить скопом, используя тот же merge. Трудоемкость реализации наверное просто дело опыта. Имхо, удобнее пробросить набор данных на технологию, которая предназначена для работы с ними и дальше ими оперировать уже в ней.
А почему бы не использовать для вставки и обновления данных хранимые процедуры? Почему именно метод add(..), ведь тот же EF может работать с хп. Большое количество данных в БД можно передать, например, в xml формате, а там, уже в базе, распарсить и сохранить с помощью хранимой процедуры. Как такой вариант?
Есть еще вопрос. В случае успешного прохождения интервью и тд. есть ли возможность присоединиться к кампу не 30 июня, а например 3-5 днями позднее, например 4 июля?
Думаю сильно зависит от структуры хранения, если в качестве бд что то «привычное» (sql, популярные nosql), то ожидание скорее всего будет долгим.
Если же в качестве хранилища у нас граф(какая-то графовая база, например, с ребрами по подпискам и от пользователей к постам), то какое-то ожидание вообще может исчезнуть.
1. Если лента каждый раз будет строиться в реальном времени, при большом количестве подписок можно вообще не дождаться. Закешированная версия живет, положим, 2 недели, TTL = 14 дней. К обновлению ленты приводят события: подписка, отписка, создание поста теми на кого мы подписаны, удаление поста, удаление пользователя.
2. Представим что у нас распределенное дешевое хранилище и место не ограничено. Необязательно хранить всю ленту, можно хранить некоторую промежуточную структуру из которой можно быстро построить ленту. Можно не хранить ленту для пользователей, которые не заходили в систему 1 год.
3. Для популярных пользователей можно вынести обработку в отдельный воркер, чтобы не тормозить середнячков.
1) Собираем в реалтайме? Если да, то что используем?
2) Делаем предагрегацию? Если да, то что используем?
3) Что то другое.
Спрашиваю потому что недавно была такая задача и хочется сравнить свое решение с чьим то еще, ну и понять в ту ли сторону вообще пошел.