Форум MySQL

Добрый день.

Есть сайт, с внутренней перепиской.
Сообщения пишутся в табличку вида:

CREATE TABLE `messages`(     `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,     `from_id` INT(10) UNSIGNED NOT NULL,           `where_id` INT(10) UNSIGNED NOT NULL,      `message` VARCHAR(512) NOT NULL,     `isread` BOOL DEFAULT FALSE,     `cr_time` DATETIME NOT NULL,         PRIMARY KEY (`id`),     KEY `users` (`from_id`, `where_id`),     KEY `isread` (`isread`) )TYPE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=0  COMMENT = 'Таблица сообщений';

Все бы ничего, но в день отправляют порядка 50 тыс. сообщений.
Чувствую с такой скоростью заполнения я скоро получу раздутую базу и огромные тормоза.
Собственно подскажите как лучше и правильнее организовать переписку на миллиард ;)

Буду рад советам, ссылкам, замечениям по текущей таблице.
Спасибо!

вряд ли кто подскажет, такого рода информация уже попадает под рамки "свои секреты"
___
количество писем в почтовом ящике ограничено?
существует ли рассылка сообщений, или только переписка?

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

Есть вариант разбить базу на споты, т.е. хранить в каждой базе например по миллиону сообщений.

message_1 - для первого миллиона message_2 - для второго миллиона message_# - для N миллиона

Пока не очень понятно как их клеить, если например в одной переписке сообщения будут разбросаны по разным таблицам. Боюсь что такой подход может отрицательно сказаться на производительности.

У MySQL есть штатная сегментация таблиц partitional - лучше воспользоваться ей.

>Все бы ничего, но в день отправляют порядка 50 тыс. сообщений.
>Чувствую с такой скоростью заполнения я скоро получу раздутую базу и огромные тормоза.
>TYPE=MyISAM
InnoDB (правильно настроенный, т.е. сервер должен быть заточен под InnoDB, все остальные таблицы базы данных тоже - иначе потребуется много памяти)

Таблицу пилите на две: messages и messages_text - весь текст выносите во вторую таблицу. Первая таблица будет меньше по объему - запросы с ней будут протекать быстрее.

>`cr_time` DATETIME NOT NULL,
Замените на UNSIGNED INT, используйте UNIXSTAMP-метку.

where_id - это поле для каких целей предназначено?

Здравствуйте, cheops!

Спасибо за ответы.

1) Да, решил воспользоваться стандартным partitional по id. Миллион записей на партицию.
2) Про messages и messages_text спасибо! Возвращаясь к 1 пункту хочу уточнить, партиции для двух таблиц делать лучше одинакового размера? Или для messages_text использовать более мелкие куски?
3) >>`cr_time` DATETIME NOT NULL, Замените на UNSIGNED INT, используйте UNIXSTAMP-метку.
Расскажите пожалуйста почему именно такое решение? Во всех проектах использую поле Date или datetime. Почему не стандартный механизм timestamp?
4) `from_id` - кто шлет, `where_id` - кому шлет.

2. Пока разбейте одинаково, если будете пользоваться InnoDB в разбивке смысла не много, у InnoDB свой механизм разбивки табличного пространства.
3. Экономите 4 байта на запись, если записей очень много - экономите объем, чем меньше таблица - тем быстрее. Причем меньше не только данные, но индекс, а по дате индексировать придется. Всякие ситуации бывают иногда объем индексов сопоставим с объемом данных - искать в таком объеме не на многим эффективнее сканирования таблицы. Стандартный механизм TIMESTAMP переработали - он теперь использует такой же формат, что DATETIME, из особенностей автообновление при INSERT/UPDATE-запросах. Используйте только если вам действительно нужно обновление даты, при UPDATE-запросе (мне кажется не ваш случай). Кроме того, обновляется только один TIMESTAMP-столбец таблицы - первый. В общем довольно много подводных камней, которые постоянно нужно держать в голове. Я в последние годы никогда к TIMESTAMP не прибегал - слишком не прозрачно.

Большое спасибо!
Последний пожалуй вопрос.
Как в текущую структуру бд добавить удаление сообщений?

У меня вариант добавить два флага удаления. 1 для автора сообщения. 2 для получателя.

Насколько правильное решение?