Форум пользователей MySQL

Я разрабатываю веб-сервис занимающийся анализом контента веб-сайтов в сети, для каждого сайта выделяются его ключевые слова (тэги).

В данный момент, не мудрствуя лукаво, keywords сохраняются в той же таблице, что и остальная статистика по сайту:

   Таблица `www`:
    id     int(11)    primary key, auto_increment
    url     varchar(64)     utf8_general_ci, INDEX
    ...
    keywords     text     utf8_general_ci
    ...
    favicon     char(23)     utf8_general_ci
    screenshots     char(23)     utf8_general_ci

Массив ключевых слов хранится в виде:  greeting cards|5,holidays|17,labor|8,greeting|5   , где через символ "|" хранится его вес на странице. Количество ключевых слов для каждого веб-сайта ограничено 15 словами.

И по этому неиндексному полю выполняются запросы вида:
SELECT COUNT(*) AS `count` FROM `www` WHERE `keywords` LIKE '%holidays\\|%' - Запрашиваю кол-во сайтов с нужным ключевым словом и его вхождением.
SELECT `url` FROM `www` WHERE `keywords` LIKE '%holidays\\|%'  - Запрашиваю сами сайты с нужным ключевым словом и его вхождением.

Вполне естественно, что в первый же месяц BETA-выхода, сервис стал загибаться. Сейчас в таблице около 20 000 записей, в сутки прибавляется около 1,5-2 тысяч. В планах - продержаться на MySQL до нескольких(5-10?) миллионов записей, ежедневный прирост более, чем на 4 тысячи сайтов планирую не допускать.


Я вижу для себя такие способы перестроения базы:


Вариант 1:  Убать упоминание о keywords из основной таблицы `www` и вынести keywords в отдельную таблицу вида:
    id                       bigint(20)           primary key, auto_increment
    site_id              bigint(20)           INDEX
    keyword            varchar(256)     INDEX
    ves                    tinyint(2)         

Таким образом запросы примут вид:
SELECT `keyword` WHERE `site_id`='3846',  т.е. выборка будет производиться по индексному полю.

При таком варианте для каждого сайта из таблицы `www` будет создаваться до 15 записей в таблице ключевых слов. Если хранение 2-х миллионов записей о веб-сайтах я могу себе представить, то 30 миллионов записей в таблице мне откровенно кажется утопией. К тому же смущает дублирование одного и того же `keyword` для нескольких `site_id`.



Вариант 2: Опять же убрать упоминания о ключевых словах из основной таблицы и создать две вспомогательных:

а) Таблица соответствия ключевых слов веб-сайту:
    id                             bigint(20)           primary key, auto_increment
    site_id                    bigint(20)           INDEX
    keyword_id            bigint(20)           INDEX
    ves                          tinyint(2)         

б) Таблица самих ключевых слов.
    id                             bigint(20)           primary key, auto_increment
    keyword                  varchar(256)     UNIQUE


При такой структуре запросы примут такой вид:
Запрос, количества сайтов с заданным ключевым словом вначале определяет id ключевого слова в таблице "б" и затем запрашивает в таблице "а" количество записей WHERE `keyword_id`= id из таблицы "б"
Запрос выбирающий сайты по ключевому слову также вначале определяет id ключевого слова в таблице "б", затем запрашивает в таблице "а" `site_id` сайтов в которых присутствует ключевое слово и лишь после этого выбирает сайт из основной таблицы `www` по первичному ключу id.

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



Посоветуйте пожалуйста верное направление. Я представляю себе, что проблема наверняка достаточно типовая и избитая для DBA больших баз, но на данный момент не нашел такого 100-процентного типового и правильного решения.

Версия сервера: 5.0.51a-24+lenny4
Расположено на VDS, ОС: Debian


Заранее благодарю за внимание)