Скорость поиска по полному тексту и идентификатору с MySQL

Question

У меня есть БД с двумя таблицами: страницы и теги, которые структурированы следующим образом:

• страницы: page_id, page_text, page_tags (около 60000 записей в любое время)
• теги: tag_id, tag_text
  (около 300000 записей в любое время)

Каждая страница связана с несколькими тегами (используя столбец page_tags). Мой вопрос касается pages.page_tags и, в частности, какой способ является наиболее эффективным для хранения вышеупомянутой ассоциации?

1. Одним из способов было бы заполнение полнотекстового индекса page.page_tags и сохранение там текста связанных тегов, например: мармелад из яблок и фруктов

2. вторым способом будет также полнотекстовый индекс page.page_tags, но сохраняются идентификаторы связанных тегов, например: 132 14 24192 14

3. третий способ - создать третью таблицу: tag_assoc, структурированную следующим образом:

tag_assoc: page_id, tag_id

(где для каждого тега, присутствующего на странице, будет существовать запись с идентификаторами страницы и тега)

---

Какой, по вашему мнению, самый эффективный способ? Особенно в отношении:

• А) скорость поиска по таким запросам: "Принеси мне каждую страницу с тегами: яблоко и апельсин "
• Б) обновление таблиц. Новый страница может попасть в базу данных довольно часто. Это означает, что если новый тег находится на некоторых из этих страниц который не существует в таблице тегов, Я должен добавить это там.

Если бы ни один из них, что бы вы предложили?

Answer 1

Эта страница, хотя и немного устаревшая, содержит приличную информацию о различных подходах к тегированию схем и о том, как каждый из них влияет на производительность. То, как вы подходите к проблеме, во многом зависит как от текущего количества записей, так и от того, как вы ожидаете, что эта сумма изменится в будущем.

Схемы: http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html

Их производительность: http://www.pui.ch/phred/archives/2005/06/tagsystems-performance-tests.html

Answer 2

Если вы используете полнотекстовые индексы, я бы сделал что-то подобное

таблица 1 - страница

pageid 
name
date
category
... etc etc other page meta data here

Таблица 2 - page_fulltext

pageid
page_title_fulltext 
page_body_fulltext 

возьмите для примера у страницы 1 есть page_body_fulltext "быстрые скачки коричневой лисы ленивого пса" на странице 2 есть page_body_fulltext "быстрые рыжие лисицы прыгают ленивого коричневого пса"

выполняя полнотекстовый поиск, вы можете найти отдельные слова тега, а также найти точные строки

то есть вы можете найти ключевые слова "быстрый" или "коричневый" или "лиса"

Но если кто-то ищет "быструю коричневую лису", вы можете сделать это тоже.

в вашем примере вы, вероятно, искали бы все 3 слова и возвращали обе страницы, что было бы неправильно.

также mysql отлично справляется с обработкой полнотекстового поиска, и вы предлагаете, в основном, аналогичную версию того, что mysql мог бы делать очень хорошо самостоятельно

так что в 2 экземпляре вы обрисовали в общих чертах выше А) скорость поиска была бы великолепна, поскольку MySQL делает это очень хорошо Б) мой путь намного быстрее, так как вам не нужно проверять наличие каждого ключевого слова, которое вы вставляете. Просто выполните стандартное обновление / вставку и позвольте mysql справиться с трудностями поиска текста для вас.

моя компания использует метод, который я описал, и он работает очень хорошо ...

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