Деякі рекомендації щодо підвищення продуктивності OLAP-кубів, Інші СУБД, Бази даних, статті

Intersoft Lab

При виборі індексів для Сховища даних, слід пам’ятати, що якщо ви використовуєте бази даних Сховища для створення OLAP-кубів, то вибрані вами індекси впливають на час обробки самих кубів. Взагалі, вирішите, не додати чи індекси для кожної таблиці фактів або вимірювань і описати зв’язки між цими таблицями. Крім того, подумайте про створення зведених індексів за всіма зовнішніми ключам в таблиці фактів і індексів для кожного зовнішнього ключа в таблицях вимірів.

Для досягнення максимальної продуктивності слід правильно вибрати режим зберігання – MOLAP, HOLAP, або ROLAP. Як правило, продуктивність при використанні MOLAP або HOLAP приблизно однакова, а застосування ROLAP в будь-якому випадку її знизить. Можливо, слід провести тест, щоб визначити, який з режимів зберігання даних (MOLAP або HOLAP) дозволить домогтися більшої продуктивність.

З одного боку, MOLAP вимагає великих обсягів дискового простору, ніж HOLAP і ROLAP, які приблизно рівні за цим показником, хоча для HOLAP, швидше за все, необхідно найменше пам’яті.

Вибираючи рівень агрегування для кубів, краще не виходити за рамки інтервалу від 25% до 60%. Як правило, при значеннях, близьких до 60%, підвищиться швидкість обробки запитів, крім того, створювані куби не будуть настільки великими, що для їх побудови потрібно занадто багато часу і місця на диску. Рівні агрегування вище 60%, як правило, вимагають величезних обсягів дискового простору і в більшості випадків не призводять до суттєвого збільшення швидкості обробки запитів.

Для досягнення найвищої продуктивності SQL-сервер з Сховищем або вітриною даних і OLAP-сервер повинні бути на різних машинах.

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

Заплануйте оновлення інформації в кубах в періоди найменшою завантаження сервера, щоб не ускладнювати роботу користувачів.

Об’єм пам’яті, який використовується OLAP-сервером, можна встановити, викликавши пункт меню “Properties” і вибравши вкладку “Environment”. Параметр “Minimum allocated memory” за замовчуванням дорівнює половині обсягу вашої оперативної пам’яті (RAM). Стандартне значення параметра “Memory conservation threshold” дорівнює загальному обсягу RAM на сервері.

Якщо ваш сервер використовується для обробки одного з декількох кубів – що настійно рекомендується – можливо, слід встановити значення “Minimum allocated memory”, рівне приблизно 90% пам’яті вашого сервера. У цьому випадку зникне необхідність у визначенні простору, доступного для роботи OLAP-сервера.

Кількість оброблюваних OLAP Service ниток можна встановити, викликавши пункт меню “Properties” і вибравши вкладку “Environment”. Параметр “Maximum number of threads” за замовчуванням дорівнює подвоєному кількості процесорів на вашому сервері (тобто, якщо у вас чотири процесори, то це значення буде рівне восьми). Максимальне значення цього параметра дорівнює 1000.

Слід з’ясувати, наскільки завантажені ваші процесори, визначивши значення System Object:% Total Processor Time і System Object: Processor Queue Length. Якщо ці значення свідчать про те, що процесори без перезавантаження, можливо, варто збільшити кількість ниток. Чим більше їх число, тим вище потенційна продуктивність сервера.

Якщо ви вирішили зробити подібне зміна, використовуйте Performance Monitor до і після кожного кроку, щоб з’ясувати, не викликали ви браку ресурсів. Продовжуйте збільшувати кількість ниток до тих пір, поки продуктивність не перестане рости, за умови, що потужності процесорів достатньо.

Якщо на сервері є велика кількість RAM, можливо, вам захочеться збільшити “Read-ahead buffer size”, який можна встановити, викликавши пункт меню “Properties” і вибравши вкладку “Processing”. Значення, встановлене за замовчуванням, дорівнює 4 Мб. Цей параметр використовується для зберігання інформації, яка в майбутньому може знадобитися OLAP-сервера. Чим більше розмір цього буфера, тим більша ймовірність того, що містяться в ньому дані дійсно знадобляться.

Як і у всіх інших випадках при зміні конфігурації сервера, проводите тест, щоб виявити зміни продуктивності. Можливо, доцільно поступово збільшувати значення цього параметра на 2 Мб до тих пір, поки продуктивність не перестане рости або почне падати.

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

При використанні майстра “Storage Design Wizard” необов’язково дотримуватися наведених рекомендацій. Ви можете експериментувати з різними компромісними варіантами, підвищуючи продуктивність або знижуючи обсяг використовуваного дискового простору. Якщо у вас багато місця на диску і час оновлення даних в кубі не принципово, можливо, слід підвищити кількість агрегатів даних, що містяться в кубі.

Створюючи OLAP-куб, використовуйте майстер “Usage Analysis Wizard”, щоб проаналізувати оброблювані запити, а також майстер “Usage-Based Optimization Wizard”, щоб підвищити продуктивність.

Якщо у вас корпоративна версія SQL-сервера (Enterprise version), можливо, слід поділити OLAP-куби на партіціі для підвищення продуктивності. Партиція являє собою окремо керований елемент зберігання. Кожна партиція може мати свій власний режим зберігання даних і рівень агрегування. Використання партіцій має ряд переваг:

OLAP і Analysis Services пропонують майстер “Usage-Based Optimization Wizard”, який використовує так званий лог запитів (Query Log). Query Log призначений для оптимізації агрегації куба, грунтуючись на фактичному використанні даних користувачами. За замовчуванням в балці реєструється 1 з 10 запитів. Майстер використовує запити, записані в балці, для вироблення рекомендацій, спрямованих на оптимізацію агрегатів кубів.

Існує два варіанти, за допомогою яких Query Log може вплинути на продуктивність серверів OLAP і Analysis Services. По-перше, одного з 10 запитів може не вистачити, щоб оптимізувати всі запити до кубу. Значення ж 1 з 2 або 1 з 5, можливо, виявиться більш відповідним.

Ви можете змінювати це значення в інтервалі від 1 з 1 до 1 з 10.000. Для цього виконайте наступні інструкції:

  1. Перебуваючи в Analysis Manager (або OLAP Manager), клацніть правою кнопкою миші на відповідному сервері і виберіть “Properties”, а потім “Logging Tab”.
  2. Використовуючи опцію “Write to long once per __ queries”, ви можете вказати необхідне значення (1-10,000).

Звичайно, часта реєстрація запитів може негативно позначитися на продуктивності сервера. Тому слід обмежити розмір зберігається в Query Log інформації. Ви можете зберігати результати за кілька годин, кілька днів або навіть кілька тижнів, поки не відчуєте, що зареєстрували необхідну кількість запитів і Wizard має достатньо інформації для вироблення рекомендацій. Але як тільки цей тест завершено, не забудьте вимкнути Query Log (це можна зробити в діалоговому вікні, яке було описано вище).

Як ви могли здогадатися, причина другого варіанту впливу Query Log на продуктивність полягає в тому, що для підтримки логу він використовує ресурси процесора і пристроїв введення / виведення. Якщо обробляються декілька запитів, використання логу не зробить значного впливу на продуктивність. Але якщо постійно виконується багато запитів, можливо, слід відключати цю опцію і використовувати її тільки тоді, коли необхідно зібрати дані для оптимізації, здійснюваної майстром “Usage-Based Optimization Wizard”.

Дуже часто час обробки куба може бути істотно знижений за рахунок використання опції “Optimize Schema” в меню Tools. Коли ця опція включена, автоматично відслідковуються і видаляються непотрібні зв’язку між таблицями фактів і вимірювань. Зменшивши кількість непотрібних зв’язків, можна значно знизити час обробки куба.

Для того щоб дана опція працювала ефективно, необхідно виконати наступні умови:

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*