Отказ от реляционной модели

FriendFeed (а это нагруженная система, конкурирует с Twitter) описала собственную модель данных. С ростом базы (MySQL) столкнулись с естественными проблемами - индексирование занимает много времени, join-ы работают все дольше и дольше. В качестве ответной меры решили отказаться от реляционной модели представления данных и хранить просто свойства объектов (как в Amazon, кстати). Вот приводимый пример записи:

{
"id": "71f0c4d2291844cca2df6f486e96e37c",
"user_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
"feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
"title": "We just launched a new backend system for FriendFeed!",
"link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",
"published": 1235697046,
"updated": 1235697046,
}

Реально для хранения используется тот же самый MySQL:

CREATE TABLE entities (
added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
id BINARY(16) NOT NULL,
updated TIMESTAMP NOT NULL,
body MEDIUMBLOB,
UNIQUE KEY (id),
KEY (updated)
) ENGINE=InnoDB;

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

Индексы в такой модели - это отдельные таблицы.

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