Обработка многих статистических столбцов БД с упорядочением по требованиям

Question

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

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

Вот несколько примеров:

• На целевой странице Music должны отображаться 5 наиболее популярных исполнителей.
• На странице Landing Music должны отображаться 5 самых популярных треков.

Моя первая мысль определила, что мне нужен вычисляемый столбец совокупности. Поскольку я хочу упорядочить эти значения, это означает, что индекс CLUSTERED будет оптимальным для каждого агрегата, по которому я хочу упорядочить. Во-вторых, поскольку DML для столбцов CLUSTERED INDEX может быть дорогостоящим, если они не являются последовательными при вставке, мне нужно сделать это запланированным заданием.

Итак, для любимой статистики художника, вот DDL, который я придумал. Заметил, что мой T-SQL может быть ужасно отключен, но я думаю, что намерения ясны.

CREATE TABLE Stats_ArtistFavourites (
    FavouriteCount INT DEFAULT 0,
    ArtistId INT PRIMARY KEY NONCLUSTERED,
    FOREIGN KEY (ArtistId) REFERENCES Artists
)

CREATED CLUSTERED INDEX IDX_Favourites 
ON Stats_ArtistFavourites (FavouriteCount, ArtistId) DESC

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

Должен ли я начать думать об интеграции OLAP (у меня очень мало опыта работы с кубами OLAP)? Или, может быть, Lucene?

Answer 1

Сканирование по простому индексу похоже на объединение, так как простые индексы содержат индексированное значение вместе со ссылкой на блок таблицы в каждом листе. Чтобы извлечь неиндексированное значение, вам нужно «объединить» таблицу по этой ссылке блока.

Кластерные индексы, напротив, содержат сами данные таблицы в каждом листе, вы получаете неиндексированные значения полей прямо при сканировании.

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

Это будет немного медленнее, чем индекс кластера, так как это будет означать "объединение", описанное выше, но это всего 5 записей, вы вряд ли заметите разницу.

Вы можете даже создать свою статистическую таблицу следующим образом:

CREATE TABLE stats (type INTEGER, score INTEGER, artist INTEGER);
CREATE INDEX ix_stats (type, score);

, это поможет вам легче добавлять новые агрегированные значения.

1 для type здесь может означать, сколько раз художник played, 2, сколько раз он favorited и так далее. Когда вам нужен новый агрегат, вы просто создаете новый тип и INSERT 5 новых строк в таблице вместо изменения ее определения.

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

Answer 2

Рассматривали ли вы использовать RANK? Вы можете быть удивлены производительностью.

Answer 3

Вы можете изучить индексированные представления. http://technet.microsoft.com/en-us/library/cc917715.aspx

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

Первая точка выглядит так, как вы хотите.