Коротко: для запроса «посты друзей второго уровня с фильтром по интересам» выбор БД влияет на модель данных и где выполняется «поиск по двум шагам» — на чтении (fan‑out on read) или при записи (fan‑out on write). Ниже сопоставление по ключевым критериям.

1) Реляционная БД (SQL)

Модель данных: нормализованные таблицы Users, Friends(user_id, friend_id), Posts(post_id, author_id, ...), Interests(user_id, interest_id) или PostTags.Согласованность: сильная (ACID) при использовании одной транзакции; одиночные запросы/обновления детерминированы.Масштабируемость: вертикальная и частичная горизонтальная (шардирование, репликация). Масштабирование сложнее при больших графах связей.Сложность запроса: стандартный вариант — двойное JOIN или рекурсивный CTE на 2 уровня. При среднем числе друзей (d) и числа постов на пользователя (p) асимптотика читательских операций примерно (O(d^2 + d\cdot p)) (по сути — просмотреть друзей друзей и их посты). С индексами будет платой по I/O, но JOINs могут быть дорогими при больших (d).Денормализация для высокой нагрузки: материализованные представления или таблицы Feed(user_id, post_id, created_at), предварительно генерируемые (fan‑out on write); кэширование результатов/индексов; хранение пред‑агрегированных списков friends_of_friends или списков интересов. Минус — сложность поддержания консистентности (нужны транзакции/фоновые джобы).

2) Документная БД (например, MongoDB)

Модель данных: документы User{_id, friends:[ids], interests:[...], feed_cached:[post_refs]} и отдельные Post документы; или вложенные посты в User (непригодно при большом количестве постов).Согласованность: обычно согласованность в пределах одного документа сильна; многодокументные операции могут быть eventual или поддерживать транзакции (зависит от СУБД). Репликация часто eventual при чтении со вторичных.Масштабируемость: горизонтальное шардинг на коллекциях хорош; чтение и запись масштабируются лучше, чем монолитный RDBMS.Сложность запроса: без денормализации нужно сначала читать список друзей ((O(d))), затем для каждого — их друзей ((O(d^2))) и получать посты по фильтру интересов — много запросов или агрегация в MapReduce/aggregation pipeline. Практически применяют предвычисленные feeds или агрегацию по интересу через индекс.Денормализация: встроенные массивы friends и interests для быстрого чтения; предзаполнение feed_cached (fan‑out on write) или хранение pointers to posts внутри пользователя; inverted indexes по интересам (коллекция Interest -> post_ids). Минусы: дублирование данных, сложные транзакции при обновлениях (нужны фоновые обновления, idempotent операции).

3) Графовая БД (например, Neo4j, JanusGraph)

Модель данных: вершины User, Post, Interest; ребра FRIEND, AUTHORED, HAS_INTEREST. Запрос «друзья второго уровня» — двушаговый обход: (user)-[:FRIEND]->(u1)-[:FRIEND]->(u2)-[:AUTHORED]->(post) с условием interest.Согласованность: зависит от реализации: локальные ACID (Neo4j) или консистенция через хранилища (в распределённых решениях может быть eventual/слабее). Транзакции над графом обычно поддерживаются.Масштабируемость: одиночные мастера справляются с графовыми обходами; распределённые графы масштабируются сложнее (шардирование по вершинам/ребрам), но специализированные движки оптимизированы для многопроходных обходов. Для очень большой соцсети нужна распределённая архитектура (сложнее).Сложность запроса: графовые БД естественны для k‑hop запросов — обход в 2 шага стоит примерно пропорционально числу посещённых вершин/ребер: (O(|V{vis}| + |E{vis}|)), для среднегоdegree (d) — примерно (O(d^2)) для дву‑шагового обхода плюс фильтрация постов. Обычно быстрее и проще выражается в запросе, чем в SQL.Денормализация: заранее Materialized two‑hop edges (создание ребёр FRIEND_OF_FRIEND для ускорения чтения), кэширование результатов двухшаговых обходов, хранение агрегированных feed‑узлов. Минус — поддержание актуальности при изменениях связей; дополнительные ребра увеличивают стоимость записи.

Резюме и рекомендации

Если нужна строгая согласованность и сложные транзакции — реляционная БД; но при больших степенях связности запросы JOIN/CTE дорогие, обычно применяют материализацию фидов.Если важна простая горизонтальная масштабируемость и гибкая схема — документная БД; чаще применяют денормализацию: вложенные friend‑lists и предсобранные feeds, плюс inverted indexes по интересам.Если основная нагрузка — графовые обходы (двух/трехшаговые запросы, рекомендации) и важна выразительность запросов по соседям — графовая БД более естественна; для очень больших сетей нужны решения с предвычислением или дополнительным шардированием/кешем.

Типичные паттерны высокой нагрузки (сравнение)

Fan‑out on write (рекомендован при высокой частоте чтений): при создании поста пушить ссылку в feed_cached всех подписчиков — быстрый read, дорогие writes.Fan‑out on read: хранить минимум, вычислять friends_of_friends на чтение — дешёвые writes, дорогие reads (подходит при редких чтениях).Материализованные представления / precomputed two‑hop sets: поддерживают быстрый фильтр по интересам, но требуют фоновой синхронизации.Inverted indexes по интересам: по интересу → список post_id (шарды по интересам), полезно когда фильтр по интересам селективен.Кэширующие слои (Redis) для hot‑feeds и результатов two‑hop запросов.

Выбор зависит от профиля нагрузки: если reads » writes и важны быстрые ответы — денормализация + предзаполненные фиды в документо‑или реляционной БД; если часто выполняются произвольные k‑hop запросы и нужно гибко выражать связи — графовая БД с кэшированием/предвычислением.