Конспектируя Кабанчика: Fan-in & Fan-out

Коэффициент разветвления по входу (Fan-in) и Коэффициент разветвления по выходу (Fan-out).

Пользователи пишут посты - это на вход (fan-in).

Пользователи читают посты - это на выход данных с сервера (fan-out).

В книге “Совершенный код” вы можете найти “желательные характеристики проекта” (стр.78). Это применительно к коду (классы, методы).

В них есть упоминание fan-in & fan-out в следующем контексте:

Высокий коэффициент по входу (fan-in) - хорошо, так как это интенсивное использование вспомогательных классов (почему это хорошо?).

Низкий или средний коэффициент по выход - хорошо, так как если больше 7ми, то он использует слишком много других классов и, возможно, слишком сложен.

Тут хотя бы приводится пара исследований почему низкий fan-out хорошо - Card and Glass, 1990; Basili, Briand, and Melo, 1996;

Twitter

В Twitter изначально была проблема с коэффициентом по выходу.

Например человек был подписан на 100 пользователей, и ему нужно было постоянно обновлять ленту делая тяжелые запросы к базе с JOIN.

Тяжелые они потому что нужно запросить всех пользователей на которых он подписан, выбрать посты для каждого и соединить их отсортировав по времени.

Тут можно посмотреть выше на правило из “совершенного кода” и…

…была применена вторая модель:

Для каждого пользователя создавался кеш (сгенерированный набор данных) со списком постов тех, на кого он подписан.

Каждый раз, когда кто-либо из них создавал новый твит, этот твит вставлялся в каждый кеш пользователя подписчика.

Для пользователей с большим количеством подписчиков генерировалось большое количество изменений на вход (fan-in).

У тебя 100млн подписчиков? Ты запостил что-то? Сделаем ка 100.000.000 изменений в кешах твоих подписчиков.

У нас тут проблемы с коэффициентом разветвления на вход (fan-in). теперь…

Сделали микс - для обычных пользователей - обновляем кеши всех подписчиков.

Для знаменитостей - отдельный запрос с последними постами.