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

Question

Я сделал веб-сканер, и он вставляет различные страницы и ссылки в базу данных.На данный момент домен просканированного URL-адреса является атрибутом на странице и в таблице ссылок.

Я думаю о создании таблицы для доменов, но боюсь, что это замедлит вставку.

На данный момент у меня загружено 1 200 000 ссылок и 70 000 страниц в базе данных, и это будет увеличиваться.

Какое решение лучше?Создать доменную таблицу?Создать индекс в атрибуте домена (это varchar)?

PS: Другая разрабатываемая мной программа будет выполнять запросы в этой базе данных.

Answer 1

Если я правильно понял, у вас есть две таблицы: "ссылки" и "страницы".Вы ничего не говорите о полях в этих таблицах.Было бы неплохо получить больше информации.

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

Еще один совет, вместо одной базы данных, вы можете захотеть иметь две: одну только для вставок и обновлений;а другой для доступа только для чтения (выбирает).

В первой БД удалите все индексы и ограничения.Это даст вам быстрые операции вставки / обновления.

В БД, доступной только для чтения, правильно проектируйте индексы, чтобы ускорить операции поиска.

Конечно, вам нужно как-то синхронизировать две базы данных.Это может потребовать дополнительного кодирования.

Answer 2

Предполагая, что ваш дизайн базы данных выглядит следующим образом:

Page: 
Id | URL

Link:
Id | Page_Id | URL

Если есть многократное повторное использование URL-адресов (например, для TVTropes), я, скорее всего, переформатировал бы дизайн так:

Domain:
Id | URL

Page:
Id | URL_Id

Link:
Id | Page_Id | URL_Id

Когда вы приступите к анализу данных, я бы порекомендовал индекс по URL, в дополнение ко всем обычным.

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

Domain:
Id | Parent_Id | URL_Part

Page:
Id | URL_Id

Link:
Id | Page_Id | URL_Id

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

Answer 3

Я не понимаю, почему вы не нормализуете .
Конечно, это немного повлияет на производительность вставок, но я надеюсь, что узкое место (и или удушение)) будет на уровне загрузки страниц.Если бы это было не так, это указывало бы на то, что вы бьете из Интернета !; -)
Типичные сканеры [вне этих, конечно же, используемых большими SE], даже если они работают на нескольких потоках и даже на нескольких машинах, производят только в общей сложности и длительно несколько десятков страниц в секунду, что хорошониже возможностей большинства серверов СУБД, даже с небольшим количеством разногласий.

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

• гораздо более высокой устойчивой скорости вставки
• большей базы данных (скажем, если ожидается, что она будет расти выше, 100 миллионов строк).

Answer 4

Вам, вероятно, придется немного поиграть, чтобы увидеть, какие результаты вы получите от различных методов.Сколько у вас разных доменов?

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

Я бы лично поместил домены в отдельную таблицу, если есть относительнонебольшое количество