Реляционная схема (основные таблицы — имена и ключи)
- users
- id BIGINT PRIMARY KEY
- username VARCHAR($255$) UNIQUE
- email VARCHAR($255$) UNIQUE
- password_hash VARCHAR($255$)
- created_at TIMESTAMP
- last_active_at TIMESTAMP
- рекомендации: держать профиль-данные, которые часто меняются, отдельно (см. profiles)
- profiles
- user_id BIGINT PRIMARY KEY REFERENCES users(id)
- display_name VARCHAR($255$)
- bio TEXT
- avatar_url VARCHAR($1024$)
- locale VARCHAR($16$)
- индекс: user_id PK (частые селекты по user_id)
- posts
- id BIGINT PRIMARY KEY
- author_id BIGINT NOT NULL REFERENCES users(id)
- content TEXT
- created_at TIMESTAMP NOT NULL
- visibility ENUM('public','private','friends','custom')
- likes_count INT DEFAULT $0$ -- денормализованный счётчик
- comments_count INT DEFAULT $0$ - индекс: (author_id, created_at DESC), (created_at) — для ленты и архива
- post_media
- id BIGINT PRIMARY KEY
- post_id BIGINT REFERENCES posts(id)
- media_url VARCHAR($1024$)
- order INT
- индекс: post_id
- follows (подписки/друзья)
- follower_id BIGINT NOT NULL REFERENCES users(id)
- followee_id BIGINT NOT NULL REFERENCES users(id)
- created_at TIMESTAMP
- PRIMARY KEY(follower_id, followee_id)
- индекс: followee_id для получения списка подписчиков; follower_id для списка подписок
- likes
- user_id BIGINT NOT NULL REFERENCES users(id)
- post_id BIGINT NOT NULL REFERENCES posts(id)
- created_at TIMESTAMP
- PRIMARY KEY(user_id, post_id)
- индекс: post_id для подсчёта/выборки лайков; можно партиционировать по post_id диапазонам/хешу
- recommendations (предвычисленные рекомендации)
- user_id BIGINT NOT NULL
- post_id BIGINT NOT NULL
- score FLOAT
- reason VARCHAR($255$) -- метаданные (коллаборативная фильтрация, контентная причина и т.д.)
- created_at TIMESTAMP
- PRIMARY KEY(user_id, post_id)
- индекс: (user_id, score DESC, created_at) — быстрый fetch лучших рекомендаций
- timelines (опционально — материализованные ленты для fan-out-on-write)
- user_id BIGINT NOT NULL
- post_id BIGINT NOT NULL
- author_id BIGINT
- created_at TIMESTAMP -- время публикации поста
- source ENUM('follow','recommendation','reshare')
- PRIMARY KEY(user_id, post_id)
- индекс: user_id с сортировкой по created_at DESC
Нормализация — варианты и компромиссы
- Полная нормализация (3NF)
- плюсы: консистентность, отсутствие дублирования, простота транзакций
- минусы: много JOIN’ов для ленты; медленные агрегаты (counts)
- Практическая денормализация (рекомендуется для производительности ленты)
- хранить денормализованные счётчики в posts (likes_count, comments_count)
- материализованные timelines per-user (таблица timelines) для мгновенной выдачи ленты
- хранить рекомендации в отдельной таблице recommendations
- компромисс: обеспечивать eventual consistency (фоновые джобы для согласования)
- Разделение «часто меняющихся» и «редко меняющихся» данных
- profile vs users; media в отдельной таблице/хранилище (CDN)
Индексация для быстрых запросов ленты
- основная выборка ленты: SELECT post.* FROM timelines WHERE user_id = ? ORDER BY created_at DESC LIMIT $N$ - индекс: timelines(user_id, created_at DESC) — покрывающий
- если фан-аут на чтение: SELECT posts.* FROM posts WHERE author_id IN (...) ORDER BY created_at DESC LIMIT $N$ - индекс: posts(author_id, created_at DESC)
- если список followees большой, лучше материализовать timeline
- индексы для лайков/проверки существования лайка:
- likes PRIMARY KEY(user_id, post_id) и индекс по post_id для агрегатов
- альтернативно Bloom-фильтр в кэше для уменьшения запросов к БД
- покрывающие индексы для часто запрашиваемых полей (например (user_id, created_at, post_id, author_id))
- полнотекстовый поиск — отдельный движок (Elasticsearch) вместо индекса БД
Стратегии получения ленты (архитектурные паттерны)
- Fan-out on write (push)
- при публикации поста пушить запись в timelines всех подписчиков
- плюс: чтение ленты очень быстро — O(1) для каждого пользователя
- минус: высокая нагрузка при авторе с миллионами подписчиков (write amplification)
- Fan-out on read (pull)
- при чтении агрегировать последние посты от followees (merge k-sorted lists)
- плюсы: экономия места при больших авторах; простота записи
- минусы: чтение дороже, latency ∼ $\mathcal{O}(k\log k)$ для слияния потоков, где $k$ — число подписок
- Гибрид
- пушим для пользователей с небольшим числом подписчиков и для VIP авторов делаем pull или специальные механизмы
Кэширование
- Кэширующие слои
- Redis/Memcached для timelines per-user, горячих постов, сессионных данных
- CDN для медиа (post_media.media_url)
- поиск/рекомендации — кешировать результаты и ранжирование
- Стратегии записи/инвалидации
- cache-aside (при чтении: если нет в кеше — читаем из БД и записываем)
- write-through / write-back для счётчиков (но сложнее при отказах)
- при фан-аут-on-write — обновлять/инвалидировать кэш timelines целевых пользователей при публикации
- TTL для рекомендаций (например: $1$ час) и для временных кэшей
- использовать pub/sub для распространения инвалидаций между сервисами
- Специальные оптимизации
- хранить часть ленты (первые $N$ элементов, например $100$) в Redis — быстрый page-0
- hot-post cache: топ-посты и их precomputed payloads
- Bloom filters для проверки "лайкнул ли пользователь" без запроса к БД
Шардирование (горизонтальное масштабирование)
- Принципы
- шардировать по пользователю (user-centric sharding) — все данные пользователя (posts, likes от пользователя, timelines для него) на одном шарде
- плюс: большинство транзакций локальны
- минус: тяжело при hot users (много подписчиков)
- шардировать по посту (post-centric) — полезно если операции по посту доминируют
- шардировать recommendations отдельно (ML-сервис, собственное хранилище)
- Стратегии шардирования
- хеш-шардирование: shard = hash(user_id) mod $S$ - просто, равномерно распределяет нагрузку
- сложности при ресайзинге (решение: consistent hashing)
- range-sharding (по диапазонам id)
- удобно для бэкапов, но возможны горячие шардовые точки
- lookup/Directory-based routing
- централизованная таблица-маппинг user_id → shard_id, полезно для гибкого ре-шейринга
- Rebalancing
- consistent hashing для минимизации перемещений данных при добавлении шарда
- фоновые миграции/копирование с cutover window
- Репликация и отказоустойчивость
- каждая шардовая нода — primary + несколько read replicas
- читать из реплик для масштабирования чтений, писать на primary
-跨-шардовые операции
- избегать joins между шардами; агрегировать на сервисном уровне
- для глобальных агрегатов (топы, глобальные тренды) держать репликационные/агрегационные сервисы
- Размещение timelines
- timelines per-user хранить в шарде пользователя (позволяет быстро читать)
- при fan-out-on-write писать в timelines шарда каждого подписчика; если подписчик на другом шарде — кросс-шардовая запись через асинхронную очередь
- Партиционирование внутри шарда
- дальше партиционировать таблицы по времени (например по месяцу) для управления размером индексов и архивирования
Дополнительные рекомендации по консистентности и масштабированию
- допускайте eventual consistency для ленты и счётчиков, чтобы снизить блокировки
- использовать фоновые джобы / стриминг (Kafka) для fan-out, расчёта рекомендаций и обновления денормализованных таблиц
- мониторинг hot-shards, latency и размера timelines; автоматические эвристики для переключения автора на pull-режим при очень большом количестве подписчиков
- для рекомендаций: хранить предварительные рекомендации в отдельной таблице/NoSQL для быстрой выдачи и периодически обновлять ML-метрики
Краткое сводное руководство по выбору
- небольшая система / быстрое прототипирование: нормализованная БД, кэширование Redis, pull-лента
- масштабируемая продсистема: user-sharding + materialized timelines (fan-out-on-write) + Redis для первых $100$ элементов + async pipelines (Kafka) + отдельный сервис/хранилище для рекомендаций
Если нужно, могу привести пример SQL DDL для конкретной СУБД или пример индексов/запросов для ленты.