tanglir, да ни с какого перепугу, а по условиям бизнес-модели. Я ж внятно написал (и как народ читает?!?):

1. Переписка между покупателем и продавцом. Соответственно все письма хранятся.
2. subject - утрированно тематика письма.

Один покупатель может написать одно письмо по данной тематике одному продавцу. Один продавец может ответить(!) письмом одной тематики (в ответ на ваш входящий номер) одному покупателю. Ещё, как пример: организация проведения тендеров. Тематики: получить заявку, подать документы, получить результат жеребьевки. и т.д.
, если сильно "уплощенно".

Dimitry Sibiryakov, ещё раз мои поздравления. Это насчет "любой нормальной СУБД".

Любая нормальная (да и ненормальная) СУБД ложится, как только данные не лезут в память. Индексы для этого и придумали. Любая нормальная (... аналогично) ложится, как только индексы перестают лезть в память... Для этого придумали кластеры, репликации, и балансировщики нагрузок...

В этой лесенке, узкое место определяется соотношением между объемом данных и баблом, потраченным на железо (и спецов) на котором эти данные вертются. Так, к примеру на 286 машинке с 16метрами ОЗУ - какая "нормальная" СУБД НЕ ляжет на таблицах, хотя бы 1млн записей?

Не умеете, троллить - не беритесь. :)

Dimitry Sibiryakov, гы. А зачем?

Запрос покупателя == ЗАКАЗ (он сам по себе уникален) . Ответ продавца == СЧЕТ. Фсё, "поезд ушел". А вот хранить надо.

Ну или система рассылки уведомлений (по сути сильно похожа на любой спам)... аналогично. Заказчик - тематика - рассылка. Когда тематика контекстно зависит от получателя (каждой маше - свой пряник) - получаем аналогичные отношения. И таких примеров "по реальной жизни" - полно.

Dimitry Sibiryakov, я привел только часть того что "придумали"... на вопрос ответите, или так проглотите? :)

Свой сервак, я уже приводил... он к 286 как-то ближее будет... ежели вчё. И с табличками от пары миллионов записей - справляется вполне себе нормально. И их там далеко не одна. Только сервис учета статистики посещений - около 20 таблиц. И только туда ежедневно валится по 100к записей, да но секольку раз (до 6 в среднем), каждая 10-я - апдейтятся. Это "между работой".

Dimitry Sibiryakov, ещё раз повторюсь: "сильно уплощенно"... ну вы же не думаете, что я сейчас весь бизнес процесс вам распишу по методам, классам и хранилищам? :)

pkarklin,
Нет. Это не работа. Это "между работой". Поскольку основная задача сервера - отдавать данные, а не писать их... отдача в районе 100к страниц в сутки (с учетом ботов, живых посетителей около 20к).

страниц в секунду, в типовых пиках - до 5, иногда, за год наблюдал несколько раз - около 50. Один раз (за последний год) на протяжении 2.5 часов шла отдача по 170 в секунду (с 3-х ip). Правда, через 2.5 часа сервак - лег минут на 10.

Вот, в пятницу выложил новую карточку товара (урлы типа mediam.ru/g-...). Теперь "всего":
0. Запись (логирование статистики запроса)
1. Выборка основных данных по урл (собственно товар)
2 , выборка баннеров (1 запрос с джойном 4-х таблиц)
3 , выборка голосовалок (запрос с джойном 2-х таблиц)
4 , выборка данных для показа (2 запроса с джойном 15 таблиц, в т.ч. "больших")
5 , выборка статистики страницы (1 запрос к очень большим таблицам - 1..5млн записей)
6 , выборка статистики поисковых фраз (1 запрос, джойн 5 таблиц того же объема)
7 , выборка "похожих" товаров (1 запрос, джойн 4 таблиц, 3 БД)
8 , выборка "близких (под)разделов", если надо ( 1 запрос, джойн 5таблиц).

Скорость отдачи без кеширований - около 0.2 .. 0.8сек в зависимости от количества отданного. С кешированием 0.1 - 0.2сек.

Ну вот к примеру mediam.ru/g-sok в firebug вижу такое:

GET g-sok, 200 OK, mediam.ru, 39.1 KB, 127.0.0.1:80, 362ms