Архитектура базы данных для комментариев

Question

[invite]

Добрый день.

Возникла странная дилемма в реализации комментариев на сайте.

Предполагается, что будет существовать большое количество статей (собственно не статей, но суть не в этом), причем актуальные (часто запрашиваемые) только небольшая часть из них, с небольшим периодом времени эти актуальные переходят в архив (без возможности добавления новый комментариев) и появляются новые. Как лучше организовать хранение в реляционной базе данных для всех комментарием, с учетом, что главный показатель — это скорость обработки/выдачи?

Собственно пока мысли вокруг двух вариантов:
— Общая таблица комментариев (смущает возможное уменьшение скорости выдачи в процессе роста таблицы)
— Отдельная таблица для каждой статьи

Допускаю возможность, что я смотрю не под тем углом на это дело.

Answer 1

[Алексей]

Одной таблицы хватит. Зачем городить что-то? Выборка по ключу (ид статьи) очень быстрая (у меня для примера, в таблице около 4 миллионов записей, выборка десятка записей по ключу занимает около 0.03 сек).
А вот куча таблиц (особенно, если статей много) быстро забьют кэш таблиц сервера БД.

Самые тормоза будут при добавлении комментариев в таблицу, я бы рекомендовал (в случае мускула) включать delay_key_write в таблице.

Comments

[invite]

Понял, смутило только «выборка десятка записей», это выбор для десяти записей, либо выбор самих десяти записей. Если десяти записей, то это просто выбор, без лимита?

[Алексей]

Выбор самих десяти записей. Всего порядка сотни подходящих записей, это с лимитом в 10 штук.

Answer 2

[bishai]

Однозначно одна таблица.

Answer 3

[Wott]

А вы не смущайтесь и попробуйте.
Одна таблица вполне нормальный вариант. Миллионы записей не представляют проблемы для простой выборки. Главное не убить дурацкими запросами, поскольку комментарий будет скорее всего text, а они при выборке в MEMORY не создаются. Посему нельзя что бы в запросе temporary на таблицу с ними создавалось.

Answer 4

[Dmitry Dedukhin]

Одна таблица InnoDB легко справится с несколькими десятками и даже сотнями миллионов записей — нужно лишь достаточное количество оперативной памяти на сервере.
Главное — не делать в ней лишних ключей, чтобы при добавлении записи не было масштабного перестроения индексов.
Если же есть задача поиска по тексту комментариев, то либо смотреть в сторону полнотекстовых индексов MyISAM (который гораздо хуже работает при одновременной записи и чтении), либо использовать специализированные решения вроде Sphinx.