Вопрос реализации в таком случае меня больше всего и интересует.
Например. Пользователь 104 написал пользователю 30495, они находятся на разных Шардах. Где хранить письмо, на «чьем» шарде. В какой структуре хранить сообщения? И как каждый из пользователей будет получать доступ(письма) к инбоксу и аутбоксу?
Спасибо за помощь!
Индексы уже сделали для всего чего можно. Места занимают больше чем сами данные :( На такой таблице(по размеру) при постоянном r\w в нее, уже вряд ли спасут какие-то индексы.
Создавать «сложности» для пользователей с отдельной папкой не выход, для пользователя все должно быть прозрачно. Именно поэтому и хотел услышать варианты решения.
P.S. Строить индекс на такой таблице значит выключить сайт на несколько часов — это неприемлемо к сожалению :(
Была мысль вынести некоторые поля в другую таблицу, тем более что тела сообщений и так в другой таблице.
Думаю стоит сделать и то и то. В смысле и архивацию и денормализацию(кажется это так называется)
если у пользователя давно не было переписки старые письма уйдут в архив, и в конечном счете необходимо будет проверять все таблицы до тех пор пока не у него на первой странице не появиться кол-во писем и «новой» таблицы. Таких не много, но все же, может есть идеи как этого избежать?
Используем Redis вместо memcached но суть не в этом :) уже кешируем :)
Поправьте если где-то не там понял,
Message — пишем читаем новые сообщения
Message_archive — помещаем туда все где created_date > now()-1 month
Message_month_year или Message_quart_year — более глубокие архивы
Теперь вопрос на засыпку, как это реализовать?
На уровне контроллеров переносить в архив, а скриптами в «поздние» архивы или все скриптами?
Большое спасибо, очень полезно и интересно. К сожалению, не смог найти ответ на мой вопрос в этой презентации ну или не хватает опыта чтобы адаптировать для своего вопроса. Какие бы вы варианты решения из этой презентации использовали столкнись с такой задачей?
Это первый шаг к масштабированию, а причина почему так случилось, это к сожалению недостаточное кол-во опыта :(
Да, спасибо за мысль. Воспользуемся если ничего другого в скором времени не найдем :(
Как бы её на будущее развить, т.к через пол года — год таблица с архивом будет иметь такую же проблему :(
1. Да
2. Восстановление таблицы со 100М записями с партициями или без них занимает очень много времени :(
3. Создание партиции примерно одинаково по времени как и обычный ALTER, даже ближе к импорту дампа.
Что именно вы имеете ввиду?
Создать например таблицу Messages_07_2012 и переместить туда все письма за июль 2012 года? Как тогда быть если у пользователя есть переписка например в январе, марте, июле и августе. Делать селект из всех таблицы за все годы архивации?
Т.е. ситуация, открывается ИНБОКС, смотрим Message, потом Message_08_2012 и т.д. а вставляем только в Message?
Или вы что-то иное имели ввиду?
Странные DSN(delivery status notification) вам приходят :( в них по RFC должны быть заголовки письма для которого создан отчет. Возможно вас просто спамят «отчетами» для вашего домена.
Например. Пользователь 104 написал пользователю 30495, они находятся на разных Шардах. Где хранить письмо, на «чьем» шарде. В какой структуре хранить сообщения? И как каждый из пользователей будет получать доступ(письма) к инбоксу и аутбоксу?
Спасибо за помощь!