Как архитектура LinkedIn позволяет находить сообщение за 150мс

В LinkedIn поиск по сообщениям особенно важен, потому что это профессиональная соцсеть. Пользователю может понадобиться найти сообщение, которое прислал ему бывший коллега несколько лет назад. Поэтому важно, чтобы поиск работал быстро и качественно.

Инженеры LinkedIn изрядно заморочились над архитектурой поиска. Подробнее — в статье.

⭐️ Интересные идеи

➡️ Основой архитектуры стали два вывода. Во-первых, пользователь может искать только по своим сообщениям, что позволяет строить индекс на основе его инбокса. Во-вторых, не все пользователи пользуются поиском, поэтому имеет смысл строить индекс только для тех, кто это делает (строить индексы — довольно дорого по ресурсам).

➡️ Для хранения сообщений используется KV store RocksDB. Сообщения хранятся в значениях по ключу вида MemberId | ConversationId | MessageId.

➡️ Для поиска строится инвертированный индекс, используется Apache Lucene (которая, например, лежит в основе OpenSearch). Для построения индекса фразы токенизируются и сохраняются в виде карты токен-сообщения.

➡️ Индекс создаётся лениво — когда пользователь делает запрос на поиск. При запросе вытаскиваются все сообщения пользователя из RocksDB и выстраиваются в in-memory индекс, который используется для ускорения дальнейших операций поиска.

➡️ Индексы партиционируются и распределяются по разным нодам, чтобы не перегружать одну. Для координации используется Zookeeper и sticky routing.

➡️ Про TTL индекса статья умалчивает.

Приятного чтения!

#systemdesign@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи