Каковы размеры адресов OLAP, которые представляют собой числовые диапазоны?

Question

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

Я читаю о OLAP, и, похоже, все это касается торгового пространства для скорости, при котором вы предварительно вычисляете (или вычисляете по требованию) и храните агрегации о своих данных, с помощью определенных измерений. Я понимаю, как это работает для измерений с дискретным набором значений, например {Male, Female} или {Jan, Feb, ... Dec} или {@US_STATES}. Но что относительно размеров, которые имеют совершенно произвольные значения, такие как (0, 1.25, 3.14156, 70000.23, ...)?

Использует ли OLAP использование агрегатов в запросах, попадающих в таблицы фактов, или просто используется для обхода вещей, которые могут быть предварительно рассчитаны? Как, произвольные скопления на произвольных значениях все еще нужно делать «на лету»?

Любая дополнительная помощь относительно получения дополнительной информации о OLAP была бы высоко оценена. На первый взгляд, как Google, так и SO кажутся немного сухими (по сравнению с другими, более популярными темами).

Редактировать: Был задан размер, на котором есть произвольные значения.

• СКОРОСТИ экспериментов: 1,256 м/с, -2.234 м/с, 33,78 м/с
• VALUE сделок: $ 120,56, $ 22,47, $ 9,47

Answer 1

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

Однако, я сказал обычно. В нашей схеме OLAP у нас есть хороший пример столбца, о котором вы думаете: event_time (поле даты и времени, граничащее со вторым). По нашим данным, он будет почти уникальным - в течение той же секунды не произойдет никаких двух событий, но поскольку в нашей таблице много лет, это все равно означает, что существуют сотни миллионов потенциально дискретных значений, и когда мы запускаем наши OLAP, мы почти всегда хотим сдерживать, основываясь на временных диапазонах.

Решение заключается в том, чтобы сделать то, что сказал Дэвид Разник, - вы создаете версию значения в виде «ведра».Таким образом, в нашей таблице, помимо столбца event_time, есть столбец event_time_bucketed, который является просто датой события, с временной частью 00:00:00. Это уменьшает количество различных значений от сотен миллионов до нескольких тысяч. Тогда, во всех запросах, которые ограничивают на сегодняшний день, мы ограничиваем на обоих bucketed и реальный столбец (так как bucketed столбец не будет достаточно точным, чтобы дать нам реальное значение), например:

WHERE event_time BETWEEN '2009.02.03 18:32:41' AND '2009.03.01 18:32:41' 
    AND event_time_bucketed BETWEEN '2009.02.03' AND '2009.03.01' 

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

Для значений плавающей запятой, как вы упомянули, стратегия балансировки может потребоваться немного больше, поскольку вы хотите выбрать метод, который приведет к относительно равномерному распределению значений и сохраняет смежность. Например, если у вас классическое распределение колокола (с хвостами, которые могут быть очень длинными), вы бы хотели определить диапазон, в котором проживает основная масса населения (скажем, 1 или 2 стандартных отклонения от среднего), разделить его на равномерное ведрами, и создать еще два ведра для «все меньше» и «все больше».

Answer 2

Я нашел эту ссылку, удобный http://www.ssas-info.com/

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

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

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

Надеюсь, это поможет.

веселит