Польза кеширования данных. Пример из реальной практики.

Спасибо, познавательно и подробно.

ну только надо понимать, что для связей далеко не всегда нужна отдельная таблица. Только лишь в случае «многие ко многим». Это базовый курс.
Статья неплохая, но для начального уровня довольно скомканая, а для продвинутых уж больно базовая. Предлагаю немного детализировать и оформить как основы кеширования на средних и больших проектах.

ЗЫ: А масштабирование базы надо делать заранее. Чтоб потом не кодить с пеной у рта. Так что начинайте прям сейчас ;)

Да, еще замечанице. Это отличная теория, но, как всегда, на практике иногда бывает все не так просто :)
Возьмем ваш пример избранных песен. Пусть у меня 100 песен в избранном и я хочу посмотреть этот список. Тогда сначала пойдет запрос в кеш на лист… а потом 100 запросов в кеш на песни. Иногда такое неприемлемо (например этот список не мой, а общий, и он висит на главной). Иногда рациональней закешировать все и сразу, пожертвовав атомарностью. Просто делать это надо аккуратно и с умом :)

«мы используем его, т.к. он». Кто он?

Интересна не тока теория, но и практика, как это сделано. Не секрет, что не все хорошо могут понять в теории, некоторым нужен пример реализации (а ещё желательно не тривиальный, а по сложнее)

Когда вы создаёте базу данных под некоторым реляционным сервером БД, то в этой базе данных автоматически создаётся набор таблиц описывающий структуру ваших данных. То есть и ваши сущности и связи между ними. Называется этот набор — Dictionary. По сути — создать базу данных это и есть создать такой описательный набор таблиц (мета-словарь). К нему всегда можно доступиться.

Таким образом, если не изобретать велосипед, а прочесть учебник и сакцентироваться на грамотном проектировании таблиц хранящих непосредственно экземпляры сущностей, то вы, во-первых, избавитесь от низкопроизводительных многоэтажных запрсов, во-вторых, почувствуете на себе всю мощь кеширования правильно настроенного SQL сервера, в третьих — cэкономите время на разработке и отладке собственных доморощенных решений, и, в четвёртых, заметно сэкономите деньги и время того, кто платит за проект. :-)

Вы как-нибудь решаете проблему блокировок кеша?
Т.е., кеш пуст, приходит одновременно 100 пользователей, необходимо перестроить кеш. Перестройка кеша длится, допустим, 1 секунду. Остальные 99 пользователей ждут или тоже перестраивают один общий кеш?)

в новом проекте использую кэширование в виде memcached
есть несколько вопросов по работе с ним, но нигде не смог найти на них ответы. Очень надеюсь, что хабролюди смогут помочь.
Суть вопроса: почему в memcached под php нет возможности делать get_multi delete_multi запросы. Под Perl такое вроде как предусмотрено.

неужели все профи разбежались?

А можно пример многоэтажного запроса?

Когда делали mp3.ru, лечили кэш таблицами. Варианты с листингом ста тысяч треков постранично с сортировкой даже по одной таблице уже тупит ближе к концу, а если джойнить то работать будет до первой тысячи посетителей. Крон тулзы, собирают кэши каждые 5,10,30 минут, заранее отсортированными и денормализованными и все ок ;).