MYSQL БД Лучший способ хранения ключевых слов и индекса URL

Question

Какой из этих методов будет наиболее эффективным способом хранения, поиска, обработки и поиска большого (миллионы записей) индекса сохраненных URL-адресов вместе с указанными ключевыми словами.

Пример 1: ( Использование одной таблицы)

TABLE_URLs-----------------------------------------------
ID        DOMAIN        KEYWORDS
1         mysite.com    videos,photos,images
2         yoursite.com  videos,games
3         hissite.com   games,images
4         hersite.com   photos,pictures
---------------------------------------------------------

Пример 2: (отношение один к одному из одной таблицы в другую)

TABLE_URLs-----------------------------------------------
ID        DOMAIN        KEYWORDS
1         mysite.com
2         yoursite.com 
3         hissite.com
4         hersite.com
---------------------------------------------------------

TABLE_URL_KEYWORDS---------------------------------------------
ID        DOMAIN_ID     KEYWORDS
1         1             videos,photos,images
2         2             videos,games
3         3             games,images
4         4             photos,pictures
---------------------------------------------------------

Пример 3: (отношение один к одному из одной таблицы в другую (с использованием справочной таблицы))

TABLE_URLs-----------------------------------------------
ID        DOMAIN
1         mysite.com
2         yoursite.com
3         hissite.com
4         hersite.com
---------------------------------------------------------

TABLE_URL_TO_KEYWORDS------------------------------------
ID        DOMAIN_ID     KEYWORDS_ID
1         1             1
2         2             2
3         3             3
4         4             4
---------------------------------------------------------

TABLE_KEYWORDS-------------------------------------------
ID        KEYWORDS
1         videos,photos,images
2         videos,games
3         games,images
4         photos,pictures
---------------------------------------------------------

Пример 4: (отношение многие ко многим из URL-адреса в идентификатор ключевого слова (с использованием справочной таблицы))

TABLE_URLs-----------------------------------------------
ID        DOMAIN
1         mysite.com
2         yoursite.com
3         hissite.com
4         hersite.com
---------------------------------------------------------

TABLE_URL_TO_KEYWORDS------------------------------------
ID        DOMAIN_ID     KEYWORDS_ID
1         1             1
2         1             2
3         1             3
4         2             1
5         2             4
6         3             4
7         3             3
8         4             2
9         4             5
---------------------------------------------------------

TABLE_KEYWORDS-------------------------------------------
ID        KEYWORDS
1         videos
2         photos
3         images
4         games
5         pictures
---------------------------------------------------------

Насколько я понимаю, пример 1 занял бы наибольшее количество места для хранения, однако поиск по этим данным был бы быстрым (повторение ключевых слов сохранялось несколько раз, однако ключевые слова располагаются рядом с соответствующим доменом)

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

Может ли кто-нибудь подсказать мне, какие идеи лучше всего использовать при разработке базы данных, которая может обрабатывать огромные ресурсы? объемы данных? С предвидением, что вы можете захотеть отобразить URL с ассоциированными ключевыми словами ИЛИ найти одно или несколько ключевых слов и вызвать наиболее релевантные URL

Answer 1

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

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

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

Наконец, поддерживать такую ​​структуру также намного проще; добавление или удаление ключевых слов может быть сделано с помощью операторов insert и delete, в то время как другие структуры требуют, чтобы вы выполняли манипуляции со строками в списке с разделителями, что опять-таки утомительно, подвержено ошибкам и неэффективно.

Answer 2

Ничего из вышеперечисленного.

Просто создайте таблицу с 2 строковыми столбцами:

CREATE TABLE domain_keywords (
    domain VARCHAR(..) NOT NULL,
    keyword VARCHAR(..) NOT NULL,
    PRIMARY KEY(domain, keyword),
    INDEX(keyword, domain)
) ENGINE=InnoDB

Примечания:

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

«База данных Huse»? Я предсказываю, что эта таблица будет меньше вашей Domains таблицы. То есть эта таблица не является вашей главной заботой о «огромных».