Библиотека Интернет Индустрии I2R.ru

Оптимизация производительности многих систем - в том числе и OLAP Services - подразумевают нахождение оптимального соотношения между рядом факторов. Если вы пытаетесь ускорить исполнение той или иной операции, возможно, где-то вы потеряете в производительности. При работе с OLAP Services перед нами стоит дилемма: снизить время построения куба или время обработки запроса. Рассмотрим, как изменение различных факторов, определяющих производительность - выбор режима хранения данных и уровня агрегирования, задание запросов, создание партиций и использование PivotTable Services - может повлиять на время построения куба и время выполнения запросов.

Режимы хранения данных

При построении куба необходимо прежде всего выбрать режим хранения, который определяет способ организации данных на диске. Выбор того или иного режима влияет на требуемый объем свободного дискового пространства и скорость поиска и извлечения информации. Существует три режима: многомерный OLAP (MOLAP), реляционный OLAP (ROLAP) и гибридный OLAP (HOLAP). В режиме MOLAP дисковое пространство на OLAP-сервере организовано более эффективно: данные хранятся в проиндексированном, многомерном формате. ROLAP создает реляционные таблицы для хранения агрегатов в Хранилище данных и обращается к базе данных этого Хранилища, чтобы получить данные из таблиц фактов или агрегатов при обработке пользовательских запросов. HOLAP представляет собой гибрид MOLAP и ROLAP; агрегаты данных хранятся в многомерном формате на OLAP-сервере, но для доступа к информации таблицы фактов происходит обращение к БД Хранилища данных. В большинстве случаев рекомендуется применять MOLAP, так как скорость обработки запросов при его использовании значительно выше, чем в случае с ROLAP или HOLAP, и, кроме того, он превосходит ROLAP при построении кубов. Тем не менее в некоторых случаях использование MOLAP нецелесообразно, например, если вы хотите использовать возможность обратной записи в OLAP-куб. Эта функциональность позволяет пользователю изменять информацию в OLAP-кубе с целью прогнозирования или исполнения сценариев "что, если...". Если вы настраиваете партицию куба для обратной записи, эти данные автоматически записываются в реляционную таблицу в БД Хранилища данных. При этом данная опция затрагивает только данные обратной записи; остальные же партиции хранятся в соответствии с режимом хранения, который был избран при построении куба.

Использование инструментов OLAP в реальном времени (realtime OLAP) - второй случай, когда не стоит прибегать к MOLAP. Если вы хотите настроить OLAP Services для поддержки realtime OLAP, следует строить куб, основанный на ROLAP-партициях без агрегатов данных. Пользователь может создавать MDX-запросы, после чего последовательно обновлять на экране результаты запросов, чтобы отслеживать, как изменяются данные.

Уровень агрегирования

Производительность OLAP-инструментов можете также повысить, установив оптимальный уровень агрегирования. При построении куба устанавливается уровень агрегирования в соответствии с желаемым повышением скорости обработки запросов. (Это ускорение показывает, насколько быстрее выполняются запросы, для которых агрегаты были определены заранее, по сравнению с запросами без агрегатов.) Это повышение скорости зависит от величины I/O, которое требуется для обработки запросов. Максимально возможное количество агрегатов - это произведение числа элементов каждого изменения. Например, если в кубе два измерения, в каждом из которых по три элемента, максимально возможное число агрегатов равно 9 (3х3). Как правило, это число чрезвычайно велико, так что расчет всех агрегатов заранее нежелателен - для их хранения потребуется дисковое пространство, а для создания агрегатов - время. Предположим, что куб содержит 4 измерения по10,000 элементов в каждом. Максимальное число агрегатов тогда составит 1016. Для расчета агрегатов, позволяющих увеличить скорость на 20 процентов, OLAP Services выбирают те из них, которые являются ключевыми (которые распределены по кубу), то есть уменьшают время, необходимое для определения других агрегатов при обработке запроса.

Чтобы достичь предельной эффективности выполнения запросов, то есть получить 100-процентное ускорение, очевидно, требуется задать максимально возможный уровень агрегирования. Тем не менее при данном подходе не стоит рассчитывать на приемлемое соотношение "время построения куба - производительность обработки запросов". Незначительное ускорение можно получить, вычисляя агрегаты заранее. Тогда OLAP Services могут быстро вычислять агрегаты во время выполнения запроса, а сервер будет кэшировать эти агрегаты. Microsoft рекомендует применять агрегаты, опираясь на информацию об их использовании при обработке пользовательских запросов. Это позволяет повысить производительность примерно на 25 %. Для этого необходимо включить регистрацию запросов на сервере, так чтобы пользователи имели доступ к кубу. После того, как будет собрана исчерпывающая информация о том, как пользователи манипулируют данными куба, OLAP Manager сможет настроить агрегирование, основываясь на сведения об их использовании.

Регистрировать запросы можно, запустив OLAP Manager и щелкнув правой клавишей мыши на имени сервера в визуальном представлении дерева (tree-view panel). Далее необходимо кликнуть на Properties и выбрать вкладку Query Log. По умолчанию сохраняется каждый десятый запрос. Возможно, чтобы получить полную картину о задании запросов, потребуется сохранять все запросы. В этом случае нужно изменить значение по умолчанию на 1 и нажать кнопку Clear Entire Log, чтобы очистить лог. (Следует обратить внимание на то, что эта установка приводит к снижению производительности.) После того, как вы используете OLAP-приложения на протяжении нескольких дней, снова запустите OLAP Manager. Щелкните правой клавишей мыши на имени куба, который вы хотите оптимизировать, и выберите Usage-Based Optimization для запуска "Мастера оптимизации" (Usage-Based Optimization Wizard). Вторая страница Мастера позволяет задать различные критерии оптимизации запросов. Можно отсортировать запросы по дате, длительности, частоте, владельцу и назначению.

После того, как вы указали критерии фильтрации, нажмите Next, чтобы увидеть список выбранных запросов. После чего нажмите Next, чтобы добавить или заменить существующие агрегаты. Специалисты Microsoft предлагают добавлять существующие агрегаты. Дальнейшие шаги аналогичны последовательности действий при работе с Storage Design Wizard.

Партиции

В случае применения корпоративной версии SQL-сервера возможно создание нескольких партиций одного OLAP-куба. Партиция куба - это отдельно управляемая единица хранения данного куба. Каждая партиция имеет свой уровень агрегации и режим хранения. Наиболее общее использования партиций - возможность инкрементального обновления (incremental update feature). Благодаря тому, что каждая партиция агрегируется отдельно, можно минимизировать время нарастающей загрузки, создав специальную партицию, которая содержит только вновь загружаемую информацию.

Загрузка куба - это не единственный процесс, в котором OLAP Services используют систему с несколькими процессорами. При обработке запроса OLAP Server порождает подпроцесс (отдельную нить) для каждого сегмента куба. Эти подпроцессы (нити) могут исполняться одновременно в системе с несколькими процессорами. Сегмент и партиция - не одно и то же. Речь идет о тех сегментах, которые можно увидеть в сообщениях типа Writing to segment 1 или Writing to segment 2, выдаваемых OLAP Manager при обработке куба. Сегмент содержит в кубе 64 кб агрегатов листевого уровня (leaf-level aggregations). Агрегат листевого уровня - это уникальная комбинация элементов измерения листевого уровня. При обработке записей факт-таблица для загрузке в куб OLAP Services добавляет каждую запись в агрегат листевого уровня. Поскольку агрегат листевого уровня крайне редко содержит связанную запись факт-таблица, OLAP Services хранит только агрегаты листевого уровня, которые имеют значения. В сегментах OLAP Services хранит непустые агрегаты. Если в кубе две партиции, каждая с двумя сегментами, MDX-запрос может породить до четырех нитей.

PivotTable Services

Производительность определяется тем, как PivotTable Services использует память. PivotTable Services используют память сервера для хранения информации об элементах измерений и кэширования значений в ячейках из результатов запросов. Самое важное - выставить достаточный объем кэш-памяти. Размер клиентского кэша - свойство connection - управляет кэшем.

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

Таким образом, используя информацию об элементах измерений, PivotTable Services также влияет на производительность обработки OLAP-запросов. Когда вы устанавливаете соединение, PivotTable Services загружает все элементы в более низкие уровни измерений куба. Если какие-либо уровни измерений содержат больше элементов, чем вы указали, PivotTable Services отыскивает соответствующие элементы только если необходимо во время обработки запроса. Предельное значение по умолчанию равно 1000, однако его можно изменить с помощью строкового параметра соединения при установке клиентского соединения. Вам может понадобиться изменить это значение в случае, если вы знаете, что пользователи будут делать большое количество запросов на низших уровнях иерархии измерений. Если ваши разработчики использовали многомерные ADO (ADO MD) для написания клиентского OLAP-приложения, вы можете установить этот параметр.

Производительность всегда играет важную роль, вне зависимости от того, занимаетесь ли вы построением кубов на сервере, создаете OLAP-приложения или разрабатываете MDX-запросы. Взяв на вооружение приведенные в данной статье советы, вы сможете удивить пользователей высокой производительностью.