Возникла странная дилемма в реализации комментариев на сайте.
Предполагается, что будет существовать большое количество статей (собственно не статей, но суть не в этом), причем актуальные (часто запрашиваемые) только небольшая часть из них, с небольшим периодом времени эти актуальные переходят в архив (без возможности добавления новый комментариев) и появляются новые. Как лучше организовать хранение в реляционной базе данных для всех комментарием, с учетом, что главный показатель — это скорость обработки/выдачи?
Собственно пока мысли вокруг двух вариантов:
— Общая таблица комментариев (смущает возможное уменьшение скорости выдачи в процессе роста таблицы)
— Отдельная таблица для каждой статьи
Допускаю возможность, что я смотрю не под тем углом на это дело.
Одной таблицы хватит. Зачем городить что-то? Выборка по ключу (ид статьи) очень быстрая (у меня для примера, в таблице около 4 миллионов записей, выборка десятка записей по ключу занимает около 0.03 сек).
А вот куча таблиц (особенно, если статей много) быстро забьют кэш таблиц сервера БД.
Самые тормоза будут при добавлении комментариев в таблицу, я бы рекомендовал (в случае мускула) включать delay_key_write в таблице.
Понял, смутило только «выборка десятка записей», это выбор для десяти записей, либо выбор самих десяти записей. Если десяти записей, то это просто выбор, без лимита?
А вы не смущайтесь и попробуйте.
Одна таблица вполне нормальный вариант. Миллионы записей не представляют проблемы для простой выборки. Главное не убить дурацкими запросами, поскольку комментарий будет скорее всего text, а они при выборке в MEMORY не создаются. Посему нельзя что бы в запросе temporary на таблицу с ними создавалось.
Одна таблица InnoDB легко справится с несколькими десятками и даже сотнями миллионов записей — нужно лишь достаточное количество оперативной памяти на сервере.
Главное — не делать в ней лишних ключей, чтобы при добавлении записи не было масштабного перестроения индексов.
Если же есть задача поиска по тексту комментариев, то либо смотреть в сторону полнотекстовых индексов MyISAM (который гораздо хуже работает при одновременной записи и чтении), либо использовать специализированные решения вроде Sphinx.
Средний
Средний
