Дизайн базы данных новостей, как в Facebook

Как сделать "дружественный" дизайн базы данных новостной лентой, так что было бы не слишком дорого получить все элементы (запрос), чтобы добавить в ленту новостей? Единственный способ, с помощью которого я могу думать, будет включать UNIONing почти в каждую таблицу (представляющую группы, заметки, друзей и т.д.) И получать даты и т.д., Что просто кажется, что это будет очень дорогой запрос для каждого пользователя, и это 'd довольно трудно кэшировать что-то подобное, когда все будут разными.

Ответ 1

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

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

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

Рассмотрим индексирование таблицы событий на основе UserId (или UserId и Date). Также рассмотрите очистку старых данных, когда это больше не требуется.

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

Ответ 2

Обсуждение о реализации потоков социальной активности здесь: Каков наилучший способ реализации потока социальной активности?

Ответ 3

Трудно ответить на этот вопрос без схемы, но я подозреваю, что UNION с 10 или более правильно проиндексированными таблицами ничего:
Типичное приложение LAMP, такое как wordpress или PHPBB, запускает более 10 запросов на просмотр страницы без проблем. Поэтому не беспокойтесь.

Ответ 4

UNION = дорого, потому что полный набор результатов зависит от операции DISTINCT. UNION ALL = дешевле, потому что это эффективно несколько запросов, для которых результаты каждого из них добавляются вместе.

Это зависит от объема данных или курса.

Основным драйвером эффективности будут индивидуальные запросы, объединенные вместе, но нет причин, по которым выбор последних (скажем) 10 записей из каждой из 10 таблиц должен занимать более малой доли секунды.