Лучший способ хранить большой набор данных в SQL Server?

Question

У меня есть набор данных, который содержит поле ключа строки и до 50 ключевых слов, связанных с этой информацией. После того, как данные будут вставлены в базу данных, будет очень мало записей (INSERTS), но в основном запросы для одного или нескольких ключевых слов.

Я прочитал « Tagsystems: тесты производительности », который основан на MySQL, и кажется, что 2NF кажется хорошим методом для реализации этого, однако мне было интересно, имел ли кто-нибудь опыт работы с SQL Server 2008 и очень большие наборы данных.

У меня, вероятно, изначально будет 1 миллион ключевых полей, в каждом из которых может быть до 50 ключевых слов.

будет структура

keyfield, keyword1, keyword2, ... , keyword50

будет лучшим решением или двумя таблицами

keyid
keyfield
| 1
|
| M
keyid
keyword

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

Answer 1

Я бы нормализовал шаг дальше.

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

KeyWords
----------
KeyWordId Int Identity(1,1)
KeyWord VarChar(200)

KeyFieldKeyWords
----------------
Keyfield Int
KeyWordId Int

С 1 миллионом ключевых полей по 50 ключевых слов в каждом, это 50 миллионов строк. Будет огромная разница в производительности, если у вас есть таблица с 2 столбцами, каждый из которых является целым числом.

Answer 2

Нормализованный - это, вероятно, ваша лучшая ставка, но наверняка будет знать только симуляция нагрузки. Вы сравниваете 50 все более разреженных индексов по 1 миллиону строк с 1 индексом из 50 миллионов строк. Я подозреваю, что если бы я был гением в MS, пишущем алгоритм для поиска по одному индексу, я бы выбрал значения, которые я искал, так как я прошел длинный путь за один проход.

Но если будет 50 индексов, мне придется сканировать 50 индексов.

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

Answer 3

Пока у вас правильные индексы, 50M строк не так уж много. Я бы просто сохранил его как

CREATE TABLE mytable (
    keyfield nvarchar(200),
    keyword nvarchar(200),
    CONSTRAINT PK_mytable PRIMARY KEY(keyfield, keyword)
)

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

Редактировать: я не должен писать, когда я слишком устал. Это путь.

Answer 4

Я не могу представить такие запросы, как

SELECT  keyfield FROM mytable
  WHERE keyword1 in (value1, value2, ...)
     OR keyword2 in (value1, value2, ...)
     OR keyword3 in (value1, value2, ...)
     ....
     OR keyword5 = in (value1, value2, ...)

Ваш второй вариант выглядит намного лучше Ключевое поле SELECT FROM mytable WHERE в (значение1, значение2, ...)

Вы захотите поэкспериментировать с индексами и механизмами, чтобы добиться максимальной производительности, но вам, вероятно, понадобится один индекс только для ключевых слов.