About

Transparent partition

Transparent partition

 

Позволяют пользователям манипулировать данными, хранящимися в отдаленных местах, как если бы они были частью локальной базы данных. В этом смысле они очень похожи на механизм VIEW в реалиционных БД. Удаленные данные берутся из источника всякий раз, когда пользователь, находящиеся в получателе, делает соответствующий запрос. Пользователям не требуется знать, где хранится информация, так как они видят ее как часть своей локальной базы данных.

 

 

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

 

Прозрачные области, разделяемые схемами источника и получателя, не обязательно должны быть абсолютно одинаковыми. Главное требование – установить их соответствие друг другу. Это значит,что необходимо указать, каким образом каждое аналитическое направление и элемент источника будут отображены в соответствующих аналитических направлениях и элементах получателя.

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

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

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

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

 

Преимущества :

Требуется меньше пространства на диске, так как информация хранится в одной базе данных.

Данные, запрашиваемые из получателя, всегда последние по времени.

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

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

Распределение данных невидимо для конечного пользователя и его инструментов.

Данные можно загружать и из источника, и из получателя.

 

Недостатки :

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

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

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

Некоторые административные операции можно выполнять только на локальных данных. Например, если архивируется получатель, то при этом не архивируется источник данных. Следующие административные операции выполняются только на локальных данных:

•    CLEARDATA;

•    DATACOPY;

•    EXPORT;

•    VALIDATE;

•    BEGINARCHIVE и ENDARCHIVE;

•    прочие операции по преобразованию в Диспетчере приложения;

 

Настройки производительности для Transparent Partitions

 

  • Разделение плотных аналитических направлений в прозрачном разделе может значительно замедлить скорость работы. Причина в том, что плотные аналитические направления используются для определения структуры и содержания блоков данных. Если база данных разделена только по плотному аналитическому направлению у получателя, системе потребуется составление блоков данных путем выполнения сетевых запросов удаленных данных в прозрачном разделе, помимо ввода-вывода данных для локальной части блока.
  • Загрузка данных в источник из получателя значительно снижает скорость работы. Данные по возможности следует загружать в источник локально.
  • Время извлечения информации замедляется, так как пользователи запрашивают данные через сеть
  • Для контроля работы можно использовать параметр ENABLE_DIAG_TRANSPARENT_PARTITION в файле essbase.cfg

 

Использование в расчетах Transparent Partitions

Когда выполняется расчет на transparent partition, Essbase выполняет расчет с использованием существующих значений локальных данных и зависимых от партиции. Когда расчет доходит до данных из партиции, то он работает в режиме bottom-up, если выполняется условие по оптимальному использованию кеша калькулятора. Увеличение его размера значительно повышает производительность расчетов, за счет уменьшения итераций по выборке данных из источника – это можно наблюдать, просматривая лог расчета, в сообщениях об использовании кеша калькулятора в целевой БД. Так же расчет сильно зависит от top-down формул на элементах.

Если вы абсолютно уверены в том, что ваш расчет не зависит от данных, лежащих на удаленной БД , можете смело использовать команду SET REMOTECALC OFF

 

 

 

 

 

Hyperion Essbase Optimization: Настройки кеша калькулятора

What is the Calc Cache?

Calc Cache – занимает ключевое место в связке между ядром Essbase и другими промежуточными облостями памяти Essbase BSO. Он используется калькулятором не для хранения данных, но содействует агрегации, когда требуется рассчитать и создать блок верхнего уровня. Continue reading “Hyperion Essbase Optimization: Настройки кеша калькулятора”

Описание иерархий

Связи между направлениями и элементами.

Essbase использует иерархическую ( поколения(generations) и уровни(level); и корни (roots) и листья(leaves)) и «родительские» описание ( родители(parents), дети(children), братья(siblings); потомки(descendants) и прародители(ancestors)) для определения ролей и связей элементов в измерениях в описании метаданных МДБ.

 Member Generation and Level Numbers


Родители (parents), дети (children) и братья (siblings)

 

Потомки(descendants) и прародители(ancestors)

Узлы(roots) и листья (leaves )

Поколения (generations) и уровни (levels)

Элементы направлений и Измерения

В данном разделе объясняются понятия Outlin’a, измерений и направлений в многомерной базе данных (МБД).

Измерения(направления) – это самый верхний уровень в описании метаданных МБД. Описание метаданных (Outline) содержит в себе древовидную структуру с выделенными связями консолидации. Например, на картинке , элемент Year – это направление ( с типом Time) и Qtr1 это элемент.

Essbase имеет как стандартные так и атрибутивные направления.

Стандартные направления – это центральный компонент бизнес планирования , напрямую отображающее предметную функциональность реализованную в модели. Примеры стандартных измерений : Time, Accounts, Product Line, Market и Division. Измерения изменяются гораздо менее чаще, чем элементы, из которых они состоят.

Аттрибутивные направления связаны со стандартными измерениями. Через атрибутивные направления можно группировать и анализировать элементы стандартного направления основываясь на характеристиках этого элемент. Например, можно анализировать продажи по типу, цвету, вкусу, продаваемой продукции, которая может иметь другую группировку элементов в основной иерархии.

Элементы направления – это независимые друг от друга сущности измерений. Например , Product A, Product B, and Product C могут быть элементами направления Product. Каждый элемент должен иметь уникальное имя (данное поведение определяется настройками МБД), и иметь множество псевдонимов (10?32?) определенных в алиасных таблицах. Essbase хранит данные элементы ассоциировано и сменем этого элемента, и это напрямую влияет на перестройку модели в случае массового переименования элементов. Так же данные могут быть рассчитаны динамически , на основании формулы, хранимой в свойствах элемента.


 

Hello world!

Снова вернулся к работе с Essbase. Это первый пост за полтора года молчания, надеюсь что не последний и что таких долгих перерывов больше не будет .

Небольшие планы по информационному заполнению блога
– есть задумка начать перевод dbag’a и уже есть некоторые наработки , выложу в ближайшее время.
– начал писать документ – компиляцию мирового и личного опыта по оптимизации производительности Essbase, думаю, что в каком-то виде он будет здесь опубликован
– есть идеи , об использовании Essbase Java API как бизнес инструмент по написанию правил, так что когда будут первые наработки – обязательно выложу их здесь
Так что следите за обновлениями.

p.s.  старый блог поддерживаться не будет – отдам его в хорошие руки