Рекомендации по проектированию и оптимизации БД для социальных приложений

Обычный случай. У меня есть простое приложение, которое позволит людям загружать фотографии и подписываться на других людей. В результате у каждого пользователя будет что-то вроде «стены» или «ленты активности», где он или она увидит последние фотографии, загруженные его / ее друзьями (людьми, на которых он или она подписаны).

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

Я пришел к следующей дилемме: Это означает, что каждый раз, когда я загружаю фотографию, БД помещает в это «ведро» n строк, где n означает количество людей, за которыми я подписан, то есть много циклов записи. Однако, если бы у меня была такая таблица, я мог бы легко применить некоторые методы оптимизации, такие как умное индексирование, а также удаление записей старше определенного периода времени (очереди).

Тем не менее, третий подход, который приходит на ум, - это даже менее денормализованная схема, в которой приложение на стороне сервера снимает часть сложности с БД. Я видел, что некоторые социальные приложения, такие как friendfeed, сильно зависят от хранения сериализованных объектов, таких как объекты JSON в БД.

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