Являются ли Mondrian / OLAP неправильным инструментом для соединения больших размеров / наборов?

Question

Резюме: Большинство примеров, которые я видел, объединений MDX включали объединение относительно небольших наборов, скажем, с десятками или сотнями элементов в каждом. Но я также хочу попробовать объединить (в частности, «непустое объединение») наборы, каждый из которых содержит тысячи или десятки тысяч элементов, и это пока не работает должным образом. Мне интересно, можно ли это заставить работать, или мне, возможно, нужно подумать об использовании чего-то другого, кроме Mondrian / OLAP.

Если говорить конкретно, у меня есть куб, который записывает взаимодействия между фирмами (n = 7000) и клиентами (n = 27000). В настоящее время и фирма, и клиент являются абсолютно плоскими иерархиями; есть уровень All и уровень отдельных компаний, между которыми нет других уровней. Существует центральная таблица фактов и отдельные таблицы измерений для фирм и клиентов.

По крайней мере, мои пользователи хотят получать сводные отчеты по этим направлениям, объединяя все непустые взаимодействия между фирмами и клиентами:

select
  [Measures].[Amount] on columns,
  NonEmptyCrossJoin([Firm].Children,
                      [Client].Children) on rows
from MyCube

Но этот запрос и его варианты не работают в моей тестовой установке Mondrian. Либо я получаю исключение OutOfMemoryException (в куче Java объемом 2 ГБ), либо Java, похоже, проводит слишком много времени в mondrian.rolap.RolapResult $ AxisMember.mergeTuple (TupleCursor). (Я могу предоставить более полную трассировку стека, если это поможет.) Под «невероятно длинным» я подразумеваю, что Java будет обрабатывать запрос часами и часами, прежде чем я сдаюсь.

Первоначально я ожидал, что вышеупомянутый запрос будет выполняться нормально, потому что концептуально это можно сделать несколько эффективно, просто выполнив SQL-запрос по следующим строкам:

select Firm, Client, Sum(Amount) as n
from fact, firm, client
where fact.firmid = firm.firmid and fact.clientid = client.clientid
group by Firm, Client

(На самом деле, если я выполню что-то подобное прямо в MySql, выполнение займет не более 15 секунд.)

Но из журналов отладки Мондриан, похоже, не пытался выполнить эту оптимизацию. Вместо этого он, кажется, выполняет объединение внутри, и таким образом, что это оказывается особенно медленным. Я установил mondrian.native.crossjoin.enable = true в моих mondrian.properties, но это не похоже на один из типов соединения, который Mondrian способен «сделать нативным». (Если я включу mondrian.native.unsupported.alert = ERROR, я получу соответствующее исключение.)

Мне остается задуматься, нужно ли мне запретить пользователям пытаться объединяться с такими большими размерами / наборами или Мондриан, возможно, не тот инструмент, который я ищу здесь. Но, может быть, я просто делаю что-то не так.

Answer 1

Я не уверен на 100%, но вы пробовали установить:

mondrian.native.nonempty.enable = true

Кажется, эта оптимизация подталкивает некоторые операции до уровня sql - похоже, это может помочь.

Answer 2

Чтобы продолжить, я попытался настроить аналогичный куб в Sql Server Analysis Services (Sql Server 2008), и похоже, что icCube считает, что разные инструменты OLAP работают по-разному:

Еще до того, как я много узнал о передовых практиках SSAS, производительность этого типа MDX значительно улучшилась. Запрос по этим направлениям

select
  [Measures].[Amount] on columns,
  NON EMPTY
  crossjoin([Firms].[Firm Name].Children,
            [Clients].[Client Name].Children)
  on rows
from MyCube

превратился из нежизнеспособного с Мондрианом в примерно десять секунд под Sql Server. Возможно, это связано с тем, что MS Business Intelligence Development Studio помогает мне создать куб MOLAP по умолчанию, или, возможно, в SSAS имеется более интеллектуальный планировщик запросов.

В любом случае, возможно, это достаточно быстро для меня. Если нет, я еще не уверен, насколько более оптимизированный SSAS может получить в этом случае. (Одна неутешительная вещь заключается в том, что даже когда я повторно запускаю запрос, это все равно занимает около 10 секунд; я надеялся, что кэширование может иметь более драматический эффект.)

Тангенциально, вы можете заметить, что в только что процитированном MDX я заменил мой оригинальный NonEmptyCrossJoin обычным перекрестным соединением в сочетании с NON EMPTY. Это потому, что, по крайней мере, в мире Sql Server, NonEmptyCrossJoin, очевидно, считается устаревшей плохой практикой. (Это отмечено в справочнике по языку Microsoft MDX . Mosha, один из бывших разработчиков SSAS, описывает ситуацию в статье под названием MDX: NonEmpty, Exists and evil NonEmptyCrossJoin . Краткая версия что NonEmptyCrossJoin имеет сбивающую с толку семантику и ограниченное применение, и начиная с Sql Server 2005 или около того, оптимизатор запросов стал достаточно умным, чтобы сделать ваш запрос быстрым без NonEmptyCrossJoin.) Поэтому я заменил более современный утвержденный эквивалент в приведенном выше MDX. (Он по-прежнему работает и с NonEmptyCrossJoin, хотя NonEmptyCrossJoin вообще не ускоряет процесс.)

Answer 3

Я отвечу на часть OLAP.Там три больших семейства инструментов OLAP.ROLAP, MOLAP и HOLAP.

ROLAP, Relational, построены на базе данных отношений.MDX-запрос, если кеш пропущен, выполняется в реляционной базе данных с помощью оператора SQL.У них есть преимущество масштабируемости за счет делагнации, но их производительность зависит от базовой базы данных.QoS может быть сложным, так как это дБ QoS.

MOLAP, InMemory, скопируйте данные во внутренние структуры (память).Здесь QoS, время ответа, более стабильно и быстрее, поскольку вся обработка выполняется на одном сервере.Проблема с MOLAP - это масштабируемость, так как вы можете получить нехватку памяти (> 100 млн.).

HOLAP - это смесь ROLAP и MOLAP.У меня нет прямого опыта, но теоретически они могут принести лучшее из обоих миров.

Глядя на цифры, у вас не должно возникнуть проблем с инструментами MOLAP, это действительно маленький куб.

Итак, прежде чем покинуть мир OLAP, дайте шанс серверам MOLAP.Для получения списка серверов OLAP вы можете проверить wikipedia

Answer 4

Mondrian OLAP не поддерживает большие базы данных.

Что ж, я разрабатываю инструмент OLAP Bitmap Join Index (BJIn OLAP), который представляет собой инструмент OLAP, основанный на Java с открытым исходным кодом.При этом используется синтаксис SQL-дисперсии, а не MDX.

Документация здесь

Пробная версия здесь