Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Задача. Текущая платформа MS AS 2000 Ent Ed. Есть DWH под 100 млн. фактов по звонкам абонентов сотовой сети. Есть измерение Абоненты на 5 млн. членов. Есть мера Distinct Count по Абонентам. Оптимизирован и в принципе летает. Клиент хочет ответ на следующий вопрос «Сколько уникальных абонентов позвонило только 1 раз за указанный период (период выбран в измерении Дата)». Сейчас работает через MDX-запроc, который спускается через Descendants вниз по измерению Абонентов и подсчитывает кол-во уникальных абонентов у которых Distinct Count=1. После оптимизации считается за несколько минут. В принципе клиент считает скорость расчета удовлетворительной, но хотелось бы оптимизировать. Вопрос. Не решал ли кто сходные задачи, например «Количество покупателей купивших 1 товар за указанный период». Интересны использованные методы оптимизации. Интересно мнение пользователей и Microstrategy. Я пригляделся и вижу, что возможны частные оптимизации путем модернизации DWH и заведения хитрого измерения «Абоненты звонившие 1 раз за день (месяц)». Насколько я понимаю в ROLAP’ах такие задачи можно решать только так. Интересен опыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2004, 02:12 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Vopros postavlenii vami - ochen tipichnen. V obschei postanovke on zvuchit - "opredelit kolichestvo listovih elementov izmereniya A, imeyuschih znachenie meri B = N" ispolzovat distinct count mozhet priiti v golovu tolko esli delat ne prosto "v lob", a esli deistvitelno delat "chez z...u". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2004, 13:06 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2backfire. Я понимаю, вы человек горячий. Однако вы ничего не сказали о том как просто решается "типичная задача", мне кажется вы просто не знаете таких решений. Мне тоже сначала показалось, что инженер, который делал меры ошибся в проектировании. Однако люди с сертификацией MSCE не так часто ошибаются как может показаться на первый взгляд. С ходу я не нашел простого и эквивалентного решения другого вида. Отмечу, DC по Абонентам есть в кубе для решения обычной задачи уникальных абонентов по услугам и т.д. Иными словами, эту меру не создавали для только данной задачи, но решили использовать для другой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2004, 14:43 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Еще моменты. DC используется в MDX для отработки итогов по группам Абонентов. Этим можно пожертвовать и использовать обычный Count. Однако это не дает прироста производительсноти. Просто мера DC сильно используется и кеш очень горячий. Основной провал происходит конечно изза беготни по измерению в 5 млн. членов. Как бы от этого уйти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2004, 14:59 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Основной провал происходит конечно изза беготни по измерению в 5 млн. членов. Как бы от этого уйти. Можно попробовать вначале убрать абонентов которые вообше не звонили в это время. Чем более грнулярно время - тем больше это будет оптимизировать. Т.е. если slice по времени на уровне "день" или еще лучше "час", то из 5 миллионов останется несколько тысяч, а их уже можно отфильтровать по обычному. Filter(NonEmptyCrossJoin(Descendants(Abonents.CurrentMember, Abonents.Name), Measures.Calls = 1) Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 02:36 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Скорее всего в 5 утра я что-то не догоняю. Я не вижу тут оптимизации. Аналогичное выражение для FoodMart Count(Filter(NonEmptyCrossJoin(Descendants([Product].CurrentMember,[Product].[Product Name])), [Measures].[Unit Sales]<100)) Descendants все равно генерить большой set. В моем случает 5 млн. NonEmptyCrossJoin c одним set не влияет на выражение. Включение в NonEmptyCrossJoin времени исказит число мемберов с [Measures].[Unit Sales]<100, т.к. полученный set будет по числу иметь больше комбинаций. Вероятно я что не понял в предлагаемом решении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 04:41 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Descendants на определенный уровень не материализует set (хотя если вычисление идет на клиенте, надо будет его закачать). После прохода NonEmptyCrossJoin елементов в set останется гораздо меньше, поэтому Filter должен бежать быстрее. В случае с [Unit Sales] < 100 эту оптимизацию делать нельзя, потому что NULL < 100, но в случае с [Calls] = 1 оптимизация делать можно, потому что NULL != 1. Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 04:49 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Догнал, 5 утра хоть спички в глаза. NonEmptyCrossJoin c одним set не выводит в конечный set те элементы, которые имеют Measures в null Я сейчас тестирую на своей маленькой БД на 100 тыс. абонентов. Однако оптимизация действует и для сложных равенств. Например такое выражение счиается за 3 сек. count(filter(NonEmptyCrossJoin(Descendants([Абоненты].CurrentMember,[Абоненты].[Abonent 1])),[Measures].[Количество]=2 or [Measures].[Количество]=1)) Такое за 20 сек. count(filter((Descendants([Абоненты].CurrentMember,[Абоненты].[Abonent 1])),[Measures].[Количество]=2 or [Measures].[Количество]=1)) Результат обнадеживает. Неплохо бы отметить такую оптимизацию в Books Online. Там вообще не сказано, что NonEmptyCrossJoin можно запустить с 1м параметром. Syntax NonEmptyCrossjoin(«Set1», «Set2»[, «Set3»...][, «Crossjoin Set Count»]) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 06:06 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Меня опередили :-) Моша, спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 10:10 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
To Ivanov Однако вы ничего не сказали о том как просто решается "типичная задача", Владимир, а Вы показали тот запрос, который по-вашему мнению был предметом оптимизации? По опыту предыдущего общения с вами у меня сложилось мнение, что от Вас "снега зимой не выпросишь". Что же Вы ожидали, что я Вам сразу "тузов покажу"? А как же "радость общения"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 14:04 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Моше конечно большое спасибо. Отметим, что и backfire сходный прием показал Моша. Причем дал интересные комментарии. /topic/76094&hl=nonemptycrossjoin Заметим, что о nonemptycrossjoin c одним set и его поведении в данном случае ранее не рассказывалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 14:16 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Можно и еще дальше оптимизировать count(filter(NonEmptyCrossJoin(Descendants([Абоненты].CurrentMember,[Абоненты].[Abonent 1]), {[Measures].[Количество]},1),[Measures].[Количество]=2 or [Measures].[Количество]=1)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 14:24 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Странно, Владимир, что Вы с этой проблемой раньше не встречались. Торможения начинаются на гораздо меньших измерениях при весьма достойном железе. Альтернативой, в принципе, может являться создание "фактов-флагов" на конец периода при закачке. А потом просто Sum. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 18:06 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Кстати, сертификация MSCE какое к AS отношение имеет??? Там энзамен-то один был 70-019 и тот, скажем прямо не супер. Или это что-то вроед IQ - теста?:-))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 18:08 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
To DmitriyS То был скорее "тест на дебильность", да и к тому же по 7-ке, а в ней как вы знаете NonEmptyCrossJoin и множеством других фишек и не пахло. Жаль, что по MS AS 2000 нет и близко такого экзамена. Надеюсь, что с Юконом ситуация изменится в лучшую сторону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 18:44 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2DmitryS. Дело в том, что я зная как вычисляется MDX стараюсь избегать на нем сложных формул бегунков. Проблемы стараюсь решить на уровне DWH. Что-то вроде ваших "фактов-флагов". В этой задаче придется вероятно делать также, т.к. клиент хочет смотреть данные из 1 мес, а это все равно все Абоненты обходить. Пока MDX клиентский и без хранения своих вычислений, это детская игрушка для простых задач. Правда местами очень полезных. По сертификации. Мое мнение, что сам OLAP это мальнькая часть BI-решения. Основной труд это построение сложных DWH, калькуляции в них, очистка данных и т.д. В моем случае это обычно MS SQL. Поэтому и девелоперы с сертификацией MSCE причем девелоперской. Хотя практика показывает, что от несертифицированных практиков с 10 летним стажем типа г-на Фрейдина толку на порядок больше чем от молодого сертифицированного инженера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 21:12 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Владимир: Интересно мнение пользователей и Microstrategy. Я пригляделся и вижу, что возможны частные оптимизации путем модернизации DWH и заведения хитрого измерения «Абоненты звонившие 1 раз за день (месяц)». Насколько я понимаю в ROLAP’ах такие задачи можно решать только так. Интересен опыт. Такой отчёт строится исключительно визуальными средствами за 3 минуты. В отчёте 3 объекта - фильтр на метрику "Количество заказов", фильтр на промежуток времени и метрика Distinct Count Клиентов. SQL генерируется очень простой. Я взял построил отчёт на примере проекта из Microstrategy Tutorial. авторReport: New Report Data Rows: 1 Data Columns: 1 Cache Used: No Execution Start Time: 05/10/2004 21:58:48 Execution Finish Time: 05/10/2004 21:58:52 Total Duration: 0:00:03.56 SQL Duration: 0:00:03.56 Analytical Duration: 0:00:00.00 Other Processing Duration: 0:00:00.00 Number of Rows Returned: 1 Number of Columns Returned: 1 Number of Temp Tables: 2 Total Number of Passes: 7 Number of SQL Passes: 7 Number of Analytical Passes: 0 DB User: Data DB Instance: Tutorial Data Tables Accessed: LU_ORDER ORDER_FACT SQL Statements: Pass0 - Duration: 0:00:00.00 create table ZZTH600IFA0MQ000 ( CUSTOMER_ID SHORT) Pass1 - Duration: 0:00:01.76 insert into ZZTH600IFA0MQ000 select a12.[CUSTOMER_ID] AS CUSTOMER_ID from [ORDER_FACT] a11, [LU_ORDER] a12 where a11.[ORDER_ID] = a12.[ORDER_ID] and a11.[ORDER_DATE] in (#2001-01-08 00:00:00#, #2001-01-09 00:00:00#, #2001-01-10 00:00:00#, #2001-01-11 00:00:00#, #2001-01-12 00:00:00#, #2001-01-13 00:00:00#, #2001-01-14 00:00:00#, #2001-01-15 00:00:00#, #2001-01-16 00:00:00#, #2001-01-17 00:00:00#, #2001-01-18 00:00:00#, #2001-01-19 00:00:00#, #2001-01-20 00:00:00#, #2001-01-21 00:00:00#) group by a12.[CUSTOMER_ID] having count(a11.[ORDER_ID]) = 1.0 Pass2 - Duration: 0:00:00.02 create table ZZTH600IFA0OT001 ( WJXBFS1 SHORT) Pass3 - Duration: 0:00:01.76 insert into ZZTH600IFA0OT001 select distinct a12.[CUSTOMER_ID] AS WJXBFS1 from [ORDER_FACT] a11, [LU_ORDER] a12, [ZZTH600IFA0MQ000] pa1 where a11.[ORDER_ID] = a12.[ORDER_ID] and a12.[CUSTOMER_ID] = pa1.[CUSTOMER_ID] and a11.[ORDER_DATE] in (#2001-01-08 00:00:00#, #2001-01-09 00:00:00#, #2001-01-10 00:00:00#, #2001-01-11 00:00:00#, #2001-01-12 00:00:00#, #2001-01-13 00:00:00#, #2001-01-14 00:00:00#, #2001-01-15 00:00:00#, #2001-01-16 00:00:00#, #2001-01-17 00:00:00#, #2001-01-18 00:00:00#, #2001-01-19 00:00:00#, #2001-01-20 00:00:00#, #2001-01-21 00:00:00#) Pass4 - Duration: 0:00:00.02 select count(*) AS WJXBFS1 from [ZZTH600IFA0OT001] pa2 Pass5 - Duration: 0:00:00.00 drop table ZZTH600IFA0MQ000 Pass6 - Duration: 0:00:00.00 drop table ZZTH600IFA0OT001 Оптимизацию возможно осуществить средствами СУБД. Здесь пример на MS Access. Если использовать более продвинутую СУБД, то можно сгенерировать 1 запрос с использованием Derived Table. Будет быстрее. Ну, и, понятное дело - индексы должны быть в порядке. А зачем клиенту быстрые ответы на такой запрос? Не очень понятна ценность ответов на них. Слишком уж простой запрос. Возможно, эти результаты ещё дальше обрабатываются как-то? Строится множество таких клиентов и что-то дальше смотрится? Поделитесь. И неужели Вы CDR закачиваете в MS AS? 100 млн. - что-то маловато для 5 млн. абонентов. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 22:16 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
To Ivanov Во-первых не MSCE, a MCSE . Во-вторых, по MSSQL уже как 4-й год существует сертификация MCDBA Ну и наконец - для девелоперов есть MCSD. Согласен с вами, что кубики в OLAP и клиентская программа - это лишь вершина айсберга. Под капотом должно быть серьезное DWH-решение. Но не будь MS AS где бы мы сейчас были - я не думаю, что с Cognos или Oracle... Хотя практика показывает, что от несертифицированных практиков с 10 летним стажем типа г-на Фрейдина толку на порядок больше чем от молодого сертифицированного инженера А это кто такой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2004, 22:34 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Константин. Исходных данных наверное под 1 млрд. записей. Просто они уже несколько агрегированны на момент закачки, вот и сжались. Нет желания сражаться с Unisys в рекордах под MS AS. Ваш метод понятен, но мне кажется он не рабочий на объеме свыше 10 млн. фактов. запрос having count очень тяжелый, я думаю сервер на 2х ксеонах будет его считать больше ночи. То что делает MS AS и то лучше. Он хоть перебирает абонентов, но не таблицу фактов. У меня пока такая идея. Клиенту нужен отчет в большинстве случаев по текущему периоду. Соотвественно я могу пометить абонента как "Постоянные клиенты", "Эпизодичные клиенты". Эпизодичных будет не так много. А затем только для этой группы можно применить формулу на манер Моши. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 15:01 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Владимир, Предположим каждая запись таблицы фактов - это звонок абонента. Делаем вычисляемую колонку в таблице фактов с константой 1 и создаем на ее основе показатель со стандартной агрегацией. При закачке 100 миллионов записей общий итог по этому показателю будет соответственно - 100 миллионов. При наложении фильтра по измерению Дата этот общий итог уменьшается (становится равен числу звонков за выбранный период). Теперь в OLAP-клиенте перетаскиваем в область строк измерение с абонентами и раскрываем его до листьев. В отчете всего одна колонка - количество звонков по каждому абоненту (напритив кого-то например - 24 звонка, напротив другого - 0, напротив третьего - 1 и т.п.). Если мы подсчитаем, в скольких строках стоит число 1 - это будет решением твоей задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 17:03 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Владимир: А всё-таки ответа на мой вопрос о бизнес-смысле такого простого запроса не последовало. Я по-прежнему думаю, что запрос должен быть сложнее для принятия решения. Про having count и больше ночи я не верю. Поинтересуйтесь у Jimmy какие запросы с таблицами фактов на десятки миллионов записей у него Sybase ASE под Microstrategy ворочает. И это сервер с самым тупым оптимизатором из всех, что я встречал. 2Jurii: При наложении фильтра по измерению Дата этот общий итог уменьшается (становится равен числу звонков за выбранный период). Теперь в OLAP-клиенте перетаскиваем в область строк измерение с абонентами и раскрываем его до листьев. То есть, все пять миллионов строк потенциально (предположим, что период мал, все звонили, и не более одного раза)? Сколько тянуть, интересно будем? А сколько это всё будет на экран выводиться? Мне кажется, такой запрос должен на сервере выполняться. Иначе клиент уйдёт в даун. Я уже получал такое на Cognos PowerPlay на более скромных объёмах. Пользователи писали кипятком после перетаскивания измерения клиентов в 20 тысяч листьев в отчёт, когда комп зависал минут на двадцать. При отсутствии возможности остановить этот беспредел - картина удручающая. На кривые руки просьба не намекать, я уже понял, что я безнадёжен и всё такое :) С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 17:51 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, Мне кажется, такой запрос должен на сервере выполняться. Иначе клиент уйдёт в даун Разумеется, я имею в виду работу через тонкого клиента, где вся нагрузка перекладывается на сервер, и например в Web-браузер можно выводить по 10 строк отчета с возможностью листания. Я уже получал такое на Cognos PowerPlay на более скромных объёмах. Пользователи писали кипятком после перетаскивания измерения клиентов в 20 тысяч листьев в отчёт, когда комп зависал минут на двадцать Вы тут говорите про PowerPlay для Windows. Я тестировал этого клиента, выводя в отчет миллион строк и тысячу колонок (то есть миллиард ячеек), но все же не будем на этом заостряться - для задачи Владимира я предлагаю PowerPlay Web. Мой подход состоит в том, чтобы превратить те строки, в которых единички - в нули, а потом воспользоваться опцией скрытия нулей, посмотрев до и после выполнения этой опции, сколько всего строк в отчете... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 18:03 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Jurii: ОК. Пусть даже и так, но я же не зря спросил Владимира о том, какая задача решается. Просто посчитать количество таких клиентов можно, но что дальше? Я имею в виду, какие решения можно принимать на основе этого числа? Допустим, Вы даже получите список таких абонентов (скажем, 1 миллион человек). Дальше что будете с ним делать (напомню, он у Вас в веб-браузере в виде 100 тысяч страниц по 10 строк на страницу)? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 18:43 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, Я имею в виду, какие решения можно принимать на основе этого числа? Ну решений наверное можно принять много... Например: 1) Это может быть один из ключевых показателей в системе сбалансированных показателей, каждый месяц это число вычисляется, и его вручную соответствующий менеджер вводит в продукт Cognos Metrics Manager :) 2) Этих абонентов можно рассматривать как малоактивных, или как неопытных - их список можно выгрузить из PowerPlay Web в формат CSV, после этого специальная программа разошлет им SMS-сообщения с предложением куда-либо позвонить, и потом можно будет отслеживать, уменьшится ли число этих малоактивных абонентов с приходом следующего периода 3) Можно накладывать дополнительные фильтры на эту выборку и анализировать разные вещи типа сколько человек позвонили один раз за границу на огромную сумму, и после этого например купили другую сим-карту, оставив большую сумму долга на старом номере, либо определить людей, которые этот единственный раз позвонили на сервисный номер сотового оператора (типа эти абоненты не разобрались, как пользоваться телефоном), и т.д... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 19:17 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Jurii: 1) Это может быть один из ключевых показателей в системе сбалансированных показателей, каждый месяц это число вычисляется, и его вручную соответствующий менеджер вводит в продукт Cognos Metrics Manager :) Воистину :)) 2) Этих абонентов можно рассматривать как малоактивных, или как неопытных - их список можно выгрузить из PowerPlay Web в формат CSV, после этого специальная программа разошлет им SMS-сообщения с предложением куда-либо позвонить, и потом можно будет отслеживать, уменьшится ли число этих малоактивных абонентов с приходом следующего периода Чтобы работать с такими списками нужна система хранения немного попродвинутее, чем текстовые файлы в формате CSV. А как дальше сравнивать как на этих абонентов подействовала Ваша рассылка SMS? Скажем, надо для этого списка посмотреть сколько раз за период каждый из абонентов позвонил более 1 раза, менее одного раза, 1 раз. То есть надо ответить на такой запрос: для списка абонентов, которые за период Х сделали всего один звонок, показать тех, которые после посылки им SMS за период Y после рассылки сделали более одного звонка. Это звучит уже более интересно. Однако, можно навернуть ещё дальше - можно сегментировать этих абонентов по причине отсутствия звонков (например, есть абоненты, которые любят в отпуск отдыхать в недоступных цивилизации местах, где сотовый телефон не работает, для таких нужно посмотреть, может быть это их нормальное поведение для данного периода времени). Представим теперь, что надо собрать такой отчёт. Фишка в том, что это работа с множествами. У меня возникает сомнение в том, что это задача для OLAP. Применение SQL не вызывает никаких сомнений, а вот OLAP - не знаю. 3) Можно накладывать дополнительные фильтры на эту выборку и анализировать разные вещи типа сколько человек позвонили один раз за границу на огромную сумму, и после этого например купили другую сим-карту, оставив большую сумму долга на старом номере, либо определить людей, которые этот единственный раз позвонили на сервисный номер сотового оператора (типа эти абоненты не разобрались, как пользоваться телефоном), и т.д... Да, да согласен. Можно, но г-н Иванов не делится постановкой задачи. Может её в бизнес-виде и не существует? И опять-таки, вышеперечисленные задачи, по моему мнению лучше решать стандартным SQL, а не притягивать за уши OLAP. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2004, 19:55 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, И опять-таки, вышеперечисленные задачи, по моему мнению лучше решать стандартным SQL, а не притягивать за уши OLAP Использование стандартного SQL - это классический подход. OLAP хорош тем, что можно сделать куб по этим данным, иметь в кубе много измерений и показателей (включая показатель типа Distinct Count для абонентов), и потом крутить все это во всех разрезах (например смотреть динамику по дням или часам суток, сколько было уникальных абонентов). Производительность будет везде в стиле OLAP (не более 5 секунд на запрос), но вот Distinct Count будет притормаживать на холодном Кэше. Я делал кубы с количеством листьев до миллиона в одном измерении (но правда на скромном железе). Первый запрос по DC выполнялся несколько минут, потом при кручении куба кэширование доводило запросы по DC до секунд и мгновений. 5 миллионов листьев закачавать в одно измерение я не пробовал. Некоторые OLAP-сервера (например Cognos PowerPlay) в таких случаях предлагают опцию External Rollup - посчитать DC вне куба, на уровне РСУБД, и потом залить эти вычисления в нужные ячейки куба - при этом никаких тормозов при работе с кубом не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 10:53 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Jurii: Просто это область, где безраздельно властвуют реляционные СУБД, SQL и средства ROLAP. Все потуги MOLAP выполнить на этих объёмах запросы средней сложности (а не просто посчитать какую-нибудь сумму в разрезе нескольких измерений), не говоря уже о сложных запросах, на которых и можно принимать решения, приводят к вопросам поиска обходных путей типа выгрузки данных в текстовые файлы и внешнего агрегирования DC. Это вопросы масштабируемости, которая в MOLAP доходит до определённого объёма, дальше которого идти очень рискованно. Что бы ни говорили про Т*3 и подобные лабораторные тесты. Я не ставлю под сомнение значимость MOLAP, нужно просто понимать рамки применимости технологии. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 11:31 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, Я не ставлю под сомнение значимость MOLAP, нужно просто понимать рамки применимости технологии. Видимо по этой причине лидеры рынка OLAP/BI в своих линейках имеют и MOLAP, и Query & Reporting. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 12:27 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Jurii: Видимо по этой причине лидеры рынка OLAP/BI в своих линейках имеют и MOLAP, и Query & Reporting. Наверное. Некоторые (Microstrategy, BusinessObjects) без MOLAP умудряются обходиться. Довольно успешно, кстати. В целом, у MOLAP, несомненно, есть своя ниша. Надо правильно позиционировать его и не терять время на попытки решить олапом задачи, которые ему пока не по зубам. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 12:35 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2 Константин: Некоторые (Microstrategy, BusinessObjects) без MOLAP умудряются обходиться. Довольно успешно, кстати. Насчет MSTR - не знаю, но насчет BO я слышал о трудностях, которые проявлялись в некоторых их проектах на больших обхемах данных (сказывалось отсутствие MOLAP-функциональности)... В целом, у MOLAP, несомненно, есть своя ниша. Надо правильно позиционировать его и не терять время на попытки решить олапом задачи, которые ему пока не по зубам. То же самое можно сказать и про решения без MOLAP :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 13:07 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Насчет MSTR - не знаю, но насчет BO я слышал о трудностях, которые проявлялись в некоторых их проектах на больших обхемах данных (сказывалось отсутствие MOLAP-функциональности)... Трудности есть у всех. Нельзя бегать по рынку и кричать "у меня нет трудностей" - никто в это давно уже не верит. Чем обусловлены трудности ВО - отсутствием ли MOLAP или ещё чем-то нам судить, не работая с ним, довольно тяжело. Одно мне известно - в России ВО - довльно успешный продукт (в отличие от тех же Cognos и MSTR, это надо честно признать). В целом, у MOLAP, несомненно, есть своя ниша. Надо правильно позиционировать его и не терять время на попытки решить олапом задачи, которые ему пока не по зубам. То же самое можно сказать и про решения без MOLAP :) Бесспорно. Существует принцип, который называется бритва Оккама. Кратко - не плоди лишнего. Это к тому, что если задача решается нормально без OLAP, то надо её решать без него, если не решается - можно уже думать о его использовании. По-моему так :) С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 13:20 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Нельзя бегать по рынку и кричать "у меня нет трудностей" - никто в это давно уже не верит. С этим никто не спорит. Разумный подход - заранее предвидеть какие сложности могут встретиться, и заранее проработать решения этих сложностей. Чем обусловлены трудности ВО - отсутствием ли MOLAP или ещё чем-то нам судить, не работая с ним, довольно тяжело Я с BO немного работал. В том что касается производительности - это полный аналог Cognos Impromptu или ReportNet (да не обидятся на меня за это разработчики ReportNet, в котором как говорят имеют место значительнейшие улучшения по генерации SQL-запросов визуальными средствами по сравнению с Impromptu, а уж про абсолютную тонкость клиентского приложения я вообще не говорю). На этом форуме обсуждались типичные проблемы ROLAP-продуктов - отсутствие гарантии высокой скорости отклика на больших объемах данных (особенно в запросах с функциями агрегирования), неудобство работы с несбалансированными иерархиями, проблемы в консолидации данных из разных источников (джойнить их налету проблематично) и т.д. Кратко - не плоди лишнего. Это к тому, что если задача решается нормально без OLAP, то надо её решать без него, если не решается - можно уже думать о его использовании. А я вот обычно подхожу с другой стороны - если задача нормально решается с помощью OLAP - то и надо ее решать на OLAP, если нет - тогда можно думать о дедовских средствах :) Хочу подчеркнуть, что под термином OLAP я имею в виду не все OLAP-продукты, а только Cognos PowerPlay в связке с модулем Impromptu (если бы я имел в виду MS AS или Oracle Express, то не так заметна была бы разница в трудоемкости разработки между OLAP и традиционными подходами с SQL). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 13:56 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Понятно. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2004, 14:33 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Владимир Иванов: Ваш метод понятен, но мне кажется он не рабочий на объеме свыше 10 млн. фактов. запрос having count очень тяжелый, я думаю сервер на 2х ксеонах будет его считать больше ночи. То что делает MS AS и то лучше. Он хоть перебирает абонентов, но не таблицу фактов. Я тут поэкспериментировал немного. Создал у себя на ноутбуке базу данных в СУБД Терадата. Закачал в таблицу фактов 10 миллонов записей. Пример довольно простой (меня ограничивал тот факт, что на ноуте у меня стоит демо-версия Терадаты с ограничением доступного дискового пространства в 1 гигабайт, поэтому индексов я не строил кроме первичного инндекса, который в Терадате обязательно есть в каждой таблице). Скорее всего, у Вас таблица пошире, но слишком у Вас оценки пессимистические по поводу скорости запроса. Вот, что получилось у меня: Скрипт для генерации тестовых данных на VBA: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Создание таблицы фактов: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Скрипт для загрузки в неё сгенерированных данных (используется утилита FASTLOAD): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Загрузка длилась около 13 минут. Код: plaintext Elapsed time: 00:01:15 Что вполне понятно - для подсчёта записей требуется выполнить full scan таблицы. Теперь смотрим сколько клиентов у нас за всё время делали покупки (звонки): Код: plaintext Результат - 4194304 записей. Немного не дотянули до 5 млн, но близко. Elapsed time: 00:07:07 Действительно, тяжёлый запрос. Но у нас ноутбук (однопроцессорный) памяти всего 512 мег и всего один диск. И full scan, поскольку индексов нету на поле cust_id. Дальше оформляю в Microstrategy метаданные (минут 10 на создание атрибутов, метрик и отчёта). Никаких кубов создавать не нужно. Поэтому приступаем к выполнению отчёта. Его я, кстати, немного изменил, поскольку в силу равномерного распределения в промежуток времени длиной в 10 не попало клиентов, сделавших всего одну покупку, поэтому я взял диапазон от 1 до 5 покупок. Название отчёта звучит "Количество клиентов, сделавших от 1 до 5 покупок за 10 дней". Вот результаты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. В результате получили 114912 клиентов. Обратите внимание на время выполнения запроса - 0:00:35.24 - т.е 35 секунд. Ограничение на промежуток времени сильно сократили время подсчёта клиентов, несмотря на то, что есть derived table с агрегацией и джойн с таблицей фактов. Посмотрим на план запроса: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. Видим, что шаги 3 и 5.2 эффективно используют первичный индекс с партишионингом. Видим также, что сканирование партиции на шаге 5.2 является самой дорогой операцией. То, что сканируем маленький кусочек таблицы, а не всю (как в случае с запросом на подсчёт уникальных клиентов по всей таблице фактов), позволяет нам значительно повысить производительность. Понятное дело, что чем больший промежуток времени мы зададим, и чем больше записей в таблице фактов, тем дольше будет выполняться наш запрос. Этот же отчёт за период в 90 дней выполнился за 0:06:35.48. Однако всё же позволю заметить, что это не двухпроцессорный сервер, а ноутбук и речь идёт не о целой ночи а о гораздо меньшем времени. В случае сервера можно говорить о довольно сильном ускорении. Во-первых это дисковый массив. Соответственно много дисков, что позволяет иметь большее количство единиц параллелизма, а партиции, которые каждая единица будет обрабатывать будут меньше. Соответственно, за счёт параллельной обработки и сокращения количества данных в партициях можно будет достичь ускорения как минимум на порядок, а то и больше. Соответственно, если речь будет идти не о 10, а о 100 миллионах записей, то мы получим примерно такие же цифры, как и приведённые выше. Вы всё ещё стираете старым порошком? Тогда Мы идём к Вам! С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2004, 03:01 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Константин. Бизнес смысл очень простой. Абоненты звонившие редко или впепрвые в ЗАДАНОМ РАЗРЕЗЕ тарифов и услуг это абоненты пробующие воспользоваться данными тарифами или услугами, т.е. новые клиенты на такие услуги. Надо всячески стимулировать, чтобы их интерес перешел из любопыства в постоянные заказы. Однако для этого их нужно идентифицировать. Твой подход мне все равно кажется битым. Вложенный запрос ниже сканирует не ИЗМЕРЕНИЯ, а ФАКТЫ. Такой не хилый скан будет при любом перевороте комбинаций измерений. Время Терадаты для такого запроса сходно с MS SQL, однако советую посмотреть, что будет если фактов станет 100 илн. Замечу еще, что MS AS не сканирует факты для таких задач, а только измерения. При работе под терминалом результаты сравнимы с Терадатой которая качает по всем фактам и будет почти в геометрическойпрогрессии от числа фактов терять скорость. MS AS зависит только от числа мемберов в измерении. select count(distinct a11.cust_id) WJXBFS1 from dmtb_sales a11 join (select a11.cust_id cust_id from dmtb_sales a11 where a11.day_id between 1 and 10 group by a11.cust_id having count(a11.tran_id) between 1.0 and 5.0 ) pa1 on (a11.cust_id = pa1.cust_id) where a11.day_id between 1 and 10 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2004, 18:49 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Владимир: Твой подход мне все равно кажется битым. Да, нет, нормальный. Не для ноутбука, конечно, но на нормальном сервере с нормальным дисковым массивом всё будет хорошо работать. 100 млн. записей - это не очень большой объём. Тем более, для Терадаты, для которой сканы не такая большая проблема, как для других баз. Вложенный запрос ниже сканирует не ИЗМЕРЕНИЯ, а ФАКТЫ. Такой не хилый скан будет при любом перевороте комбинаций измерений. А я и не утверждал, что сканируется измерение. Однако стоит заметить несколько вещей: 1. В данном запросе сканируется не вся таблица, а только одна партиция (каждая партиция содержит данные за несколько дней): Код: plaintext 1. 2. 3. 4. 5. 6. 7. Соответственно, количество строк в таблице, будь оно хоть и 100 млн. не влияет сильно на скорость. Тем более, никак не экспоненциально. Что подтвердил мой следующий эксперимент. На 20 млн строк запрос отработал за 0:01:02.70 (примерно, минута и 3 секунды). Объясняется это очень просто - в партиции стало ровно в два раза больше данных. Можно сделать оценку, что на 100 млн. записей запрос отработает за 5 минут с небольшим (конечно, от демографии данных тоже будет зависеть). Понятно, что при увеличении временнОго интервала сканировать придётся больше и, соответственно, время отклика будет тоже расти. Но, опять-таки не экспоненциально. 2. При сочетании измерений и наложении на них фильтров, сгенерируется дополнительное условие WHERE (например для выборки тех клиентов, которые купили определённое количество определённых продуктов ), что будет ускорять выполнение запроса. Я, например сделал ещё одно ограничение на номера продуктов (между 1 и 100): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Как видишь, запрос выполнился за 5 с половиной секунд. Вполне в рамках стандарта OLAP. Продолжение следует :) С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2004, 23:54 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Jurii: Некоторые OLAP-сервера (например Cognos PowerPlay) в таких случаях предлагают опцию External Rollup - посчитать DC вне куба, на уровне РСУБД, и потом залить эти вычисления в нужные ячейки куба - при этом никаких тормозов при работе с кубом не будет Юрий, я немного недопонимаю, как можно DC посчитать заранее вне куба для пересечения всех измерений и для всевозможных периодов, по которым может захотеть потенциально построить отчёт пользователь. В нашем случае - 5 миллионов абонентов, 100 миллионов звонков за период, скажем в 1 месяц. Плюс ещё какие-то измерения. Так вот, объясните, пожалуйста, как можно рассчитать DC заранее для всех возможных периодов, которые входят в этот месяц? Вы представляете сколько периодов разной длины укладываются в один месяц? И в какие ячейки куба это будет попадать? Скажем в какую ячейку куба попадёт DC за период с 5 по 18 число, а в какую - с 6 по 19? Тут что-то не так... Допускаю, что если вы этот месяц побъёте, скажем, на недели, для каждой недели посчитаете DC и положите это в соответствующие ячейки. Но если пользователю понадобится посмотреть, что было в период от середины первой недели до середины второй, то как Вы себе представляете решение этой задачи? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2004, 01:45 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, Юрий, я немного недопонимаю, как можно DC посчитать заранее вне куба для пересечения всех измерений и для всевозможных периодов, по которым может захотеть потенциально построить отчёт пользователь. External Rollup - не панацея. ER при работе с неаддитивными показателями типа DC можно сравнить с MS AS - для ячеек куба можно просчитать, но потом свертку провести будет нельзя (то есть если за один день - 100 абонентов, за другой - 110, то ER не позволит понять, сколько было за 2 дня). Стандартный DC, вычисляемый в кубах Cognos, свертки делать позволяет, но при большом числе листьев требуется разогреть кэш чтобы дойти до мгновенного отклика на запросы пользователей. Как видишь, запрос выполнился за 5 с половиной секунд. Вполне в рамках стандарта OLAP. Стандарт OLAP - это не более 5 секунд :) Кстати, а что будет, если пользователи MSTR + Teradata параллельно работают, делают аналогичные отчеты, но с немного разными параметрами (за разные периоды времени, по разным типам клиентов и услуг, с разными фильтрами)... Как будет себя вести среднее время отклика на запрос? Я думаю именно в этом основная разница между ROLAP и настоящим OLAP (который MOLAP)... И еще интересный вопрос: допустим примем во внимание, что в ROLAP круто настроено кэширование - пользователь один раз сделал запрос, он выполнился за минуту, если сделать такой же запрос еще раз - то он вероятно выполнится мгновенно. Но что произойдет, если в промежутке между двумя запусками одного и того же запроса в таблицу фактов легла одна новая запись? Помогает ли в данном случае кэширование сделанное до того как эта запись попала в базу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2004, 09:11 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
External Rollup - не панацея. Понятное дело - скорее, костыль. Который в нашем случае не помогает. ER при работе с неаддитивными показателями типа DC можно сравнить с MS AS - для ячеек куба можно просчитать, но потом свертку провести будет нельзя (то есть если за один день - 100 абонентов, за другой - 110, то ER не позволит понять, сколько было за 2 дня). Именно это я и имел в виду. 2Владимир: Я и твою схему тоже не въехал. MS AS плохо себе представляю. Как ты можешь за любой период посчитать DC, бегая только по таблице измерений клиентов, и не затрагивая фактов? Я понимаю, что можно хранить свёртку для заранее известных периодов где-то рядом с листьями измерения (кстати, такое можно и в реляционной таблице измерения сделать, но я противник таких крайностей - денормализация в конечном счёте не самая полезная штука), но, вот как этот расчёт сделать для произвольных периодов, не трогая фактов на самом детальном уровне, я не понимаю. Объясни, пожалуйста в двух словах. Стандартный DC, вычисляемый в кубах Cognos, свертки делать позволяет, но при большом числе листьев требуется разогреть кэш чтобы дойти до мгновенного отклика на запросы пользователей. Юра, очевидно, речь идёт о свёртке за фиксированные периоды? Что будет, если периоды переменные? Как тут кэш может помочь, я не очень понимаю. Если, скажем у тебя все пользователи один и тот же запрос делают за один и тот же период - это понятно, один раз посчитал агрегат и выдаёшь пользователям, но если все запросы разные, тебе придётся каждый раз DC на лету считать. И, хоть убей, не понимаю, при чём тут кэш. Я думаю именно в этом основная разница между ROLAP и настоящим OLAP (который MOLAP)... Да, не бывает настоящего OLAP, как и реляционных баз данных не бывает. Ни одна, понимаешь, не подчиняется всем правилам Кодда. Что за детский сад? По существу: Кстати, а что будет, если пользователи MSTR + Teradata параллельно работают, делают аналогичные отчеты, но с немного разными параметрами (за разные периоды времени, по разным типам клиентов и услуг, с разными фильтрами)... Как будет себя вести среднее время отклика на запрос? Для параллельной работы в Терадате много чего предусмотрено. Начать с того, что любой запрос выполняется параллельно. Если два пользователя сканируют одну и ту же таблицу и им обоим нужны одни и те же куски этой таблицы одновременно, то эта таблица будет сканироваться только один раз, а результаты получат оба пользователя (три, четыре и т.д.). Понятное дело, что рост нагрузки не может не скзаться на производительности. Она будет падать в любой системе (разговоры о том, что "настоящий" OLAP не будет тормозить лучше не начинайте, если бы так было, все бы ставили OLAP на калькуляторы и сотовые телефоны). Как с этим бороться? Во-первых, в арсенале реляционных СУБД за всю историю накопился целый арсенал по тьюнингу производительности (обратитесь, например, к ораклоидам, они Вам много про это расскажут, набор средтсв более-менее стандартный - материализованные представления, различные индексы). Второе, Терадата линейно масштабируется. Это значит, что если нам нужно удвоить производительность, мы можем это сделать тупо расширив систему вдвое (понятное, дело, что надо сначала попробовать её повысить другими способами). Потом, есть такая штуковина, как Priority Scheduler, который позволяет разным классам пользователей выделять разное количество системных ресурсов (кстати, в Cognos такое есть?) чтобы лучше гарантировать заявленное время отклика системы тем пользователям, кому это критично. И еще интересный вопрос: допустим примем во внимание, что в ROLAP круто настроено кэширование - пользователь один раз сделал запрос, он выполнился за минуту, если сделать такой же запрос еще раз - то он вероятно выполнится мгновенно.Да, такое возможно. Но что произойдет, если в промежутке между двумя запусками одного и того же запроса в таблицу фактов легла одна новая запись? Помогает ли в данном случае кэширование сделанное до того как эта запись попала в базу? А объясни мне для начала, для чего это нужно. В виде примера какой-нибудь бизнес-задачи. Тогда обсудим этот случай. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2004, 11:37 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, External Rollup - не панацея. Понятное дело - скорее, костыль. Который в нашем случае не помогает. Я бы сказал, что ER - это резервный вариант, для супер-хитрых аргегаций ну и для случаев с DC. Что касается ограничения в анализе только по структуре иерархии времени заложенной в куб - для кого-то это проблема, а для кого-то - нормальное решение (далеко не всем нужны нестадартные временнЫе периоды). Юра, очевидно, речь идёт о свёртке за фиксированные периоды? Что будет, если периоды переменные? Как тут кэш может помочь, я не очень понимаю. Тесты показывают, что самая сложная операция - расчет DC когда в кубе не наложены фильтры (то есть смотрим агрегированные данные за несколько лет). Когда делаем Дрилл-Дауны и Слайс & Дайс - расчет DC происходит все быстрее. Свертка обычно делается за небольшие периоды (например с 17 апреля по 25 мая), и она выполняется быстро. Видимо при первом расчете DC что-то грузится в оперативную память на OLAP-сервере... Да, не бывает настоящего OLAP, как и реляционных баз данных не бывает. Ни одна, понимаешь, не подчиняется всем правилам Кодда Но при этом есть принцип 80 на 20 - думаю крутые OLAP-продукты и РСУБД соответствуют этому названию более чем на 80%, хотя не обязательно на 100%, и для реальных задач этого достаточно. Понятное дело, что рост нагрузки не может не скзаться на производительности. Она будет падать в любой системе (разговоры о том, что "настоящий" OLAP не будет тормозить лучше не начинайте, если бы так было, все бы ставили OLAP на калькуляторы и сотовые телефоны). Не согласен. В OLAP уже почти все заранее просчитано, и каждый запрос пользователя - это малое количество вычислительных операций. А в ROLAP даже при наличии кэширования - вычислений (и нагрузка на сервер) на порядки больше. Может производительность и падает в любой системе, но в OLAP она падает во много раз медленнее чем в ROLAP (при этом пользователям OLAP приходится платить за это тем, что имеет место оффлайн, кубы надо обновлять). Потом, есть такая штуковина, как Priority Scheduler, который позволяет разным классам пользователей выделять разное количество системных ресурсов (кстати, в Cognos такое есть?) Хороший вопрос, никогда не задумывался... Есть радикальный способ - перекрыть на время доступ некоторым группам пользователей, насчет более тонкого способа - надо подумать. Помогает ли в данном случае кэширование сделанное до того как эта запись попала в базу? А объясни мне для начала, для чего это нужно. В виде примера какой-нибудь бизнес-задачи. Тогда обсудим этот случай. Я полагаю, что сила OLAP - это высокая производительность, но за это платят оффлайном. В ROLAP хуже дела с производительностью, выше требования к железу, но зато возможен онлайн-доступ к реляционным данным. Мой вопрос в том, можно ли с живой базой настроить кэширование так, чтобы ROLAP-запросы приближались по скорости выполнения к OLAP? Если же Вы скажете, что ROLAP надо вешать на ХД и обновлять это ХД не каждую минуту а реже - тогда этот вопрос снимается (и кубы, и ХД в этом случае будут подвержены оффлайности). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2004, 18:52 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Юрий: Тесты показывают, что самая сложная операция - расчет DC когда в кубе не наложены фильтры (то есть смотрим агрегированные данные за несколько лет). Да, это даже из здравого смысла следует, что на большем объёме данных DC более ресурсоёмкая операция. Ведь, чтобы сделать подсчёт уникальных элементов, надо выполнить как минимум полный перебор всех элементов. Когда делаем Дрилл-Дауны и Слайс & Дайс - расчет DC происходит все быстрее. Понятное дело, drill-down сокращает множество, которое надо перебирать. Свертка обычно делается за небольшие периоды (например с 17 апреля по 25 мая), и она выполняется быстро. Что значит, обычно? Смотря кем, и смотря у кого какие задачи. Видимо при первом расчете DC что-то грузится в оперативную память на OLAP-сервере... Наверняка, ЧТО-ТО грузится :) Реляционная база хотя бы план запроса показать может, а вот OLAP непонятно как работает - как узнать что он там внутри делает? 2Владимир: Твой подход мне все равно кажется битым. Вложенный запрос ниже сканирует не ИЗМЕРЕНИЯ, а ФАКТЫ. Такой не хилый скан будет при любом перевороте комбинаций измерений. Время Терадаты для такого запроса сходно с MS SQL, однако советую посмотреть, что будет если фактов станет 100 илн. Замечу еще, что MS AS не сканирует факты для таких задач, а только измерения. При работе под терминалом результаты сравнимы с Терадатой которая качает по всем фактам и будет почти в геометрическойпрогрессии от числа фактов терять скорость. MS AS зависит только от числа мемберов в измерении. Я таки загрузил 100 млн. строк в Терадату. Выполнил обсуждаемый выше запрос с фильтром на 10 дней и 100 продуктов. Запрос выполнялся в Терадате 3 минуты 5 секунд. Запрос на периоде в 30 дней выполнился за 8 минут 34 секунды. На периоде в 60 дней - за 21 минуту 17 секунд (правда, эксперимент я немного испортил, поскольку в это время ещё что-то делал параллельно с выполнением запроса). В любом случае, геометрической прогрессии я здесь не вижу. При этом надо заметить, что процессор был занят в среднем не более, чем на 25 процентов. Основная нагрузка была на диск. Это означает, что, если у меня в наличие будет 4 диска, то я имею возможность сократить время выполнения данного запроса в четыре раза даже, если останусь на одном процессоре. Это оценка довольно грубая, реальный выигрыш от добавления дисков может быть больше. Если это - дисковый массив из 10 зеркальных пар, то выигрыш будет ориентировочно в 20 раз. А по поводу сканирования только элементов измерения я всё-таки не понял - как же можно обойтись без сканирования фактов? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2004, 01:11 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Константин. Спасибо за комментарии, благодаря им я смог довести вычисление нужных показателей на MS AS до времени отклика 1 секунда. По порядку. Мне изначально показалось, что задачу нужно решать в DWH. Ваши примеры запросов показали, что они вполне могут реально выполняться на SQL серверах. Первый запрос на 5 млн. фактов на моем нотике MS SQL выплюнул за 57 секунд. Правда я немного "покрутил ручки" в MS SQL. Результат обнадежил. На 100 млн. фактов запросы сложнее вашего (все периоды, все абоненты, все услуги) выполняются примерно за 5 минут. Время не чистое на сервере шли и другие задачи. Как видно MS SQL опережает Терадату как процессор запросов или как минимум на том же уровне. Хотя тест не чистый. Далее я конечно мог создать ROLAP в MS AS, но я этого делать не стал. Я просто сделал несколько запросо чтобы они давали все нужные развертки, слил их в отдельную витрину и построил сверху MOLAP куб. Его соединил с основным через вирутальный куб. Время отклика 1 сек. Ну не молодец ли я? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2004, 16:18 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Владимир, Как видно MS SQL опережает Терадату как процессор запросов или как минимум на том же уровне. Хотя тест не чистый. А какая конфигурация у твоего ноутбука? Я просто сделал несколько запросо чтобы они давали все нужные развертки, слил их в отдельную витрину и построил сверху MOLAP куб. Его соединил с основным через вирутальный куб. На мой взгляд это похоже на External Rollup в OLAP-сервере Cognos PowerPlay (и при этом как известно не решается задача вычисления показателя за произвольный период времени или по произвольному подмножеству элементов других измерений - свертка) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2004, 17:40 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Владимир: Спасибо за комментарии, благодаря им я смог довести вычисление нужных показателей на MS AS до времени отклика 1 секунда. Не за что. И совершенно бесплатно :) Ваши примеры запросов показали, что они вполне могут реально выполняться на SQL серверах Было в видно с самого начала. Правда я немного "покрутил ручки" в MS SQL. Интересно бы узнать в кратце, что за ручки крутил. На 100 млн. фактов запросы сложнее вашего А можно пару примеров?. И как оценивается сложность? Ведь больше кода не обязательно означает более сложный запрос. Как видно MS SQL опережает Терадату как процессор запросов или как минимум на том же уровне. Откуда видно, не понял? Далее я конечно мог создать ROLAP в MS AS, но я этого делать не стал. Я просто сделал несколько запросо чтобы они давали все нужные развертки, слил их в отдельную витрину и построил сверху MOLAP куб. Его соединил с основным через вирутальный куб. А как насчёт поддерживаемости этого хозяйства? Что происходит при обновлении данных? Сколько лишнего пространства нужно для хранения отдельной витрины? А если построенных свёрток не хватает, тогда как? JuriiНа мой взгляд это похоже на External Rollup в OLAP-сервере Cognos PowerPlay (и при этом как известно не решается задача вычисления показателя за произвольный период времени или по произвольному подмножеству элементов других измерений - свертка) Мне тоже кажется, что не решается. В противном случае я тоже могу свёрток насоздавать прямо в базе, только кубов генерировать и поддерживать не надо будет. И время отклика будет нормальное. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2004, 00:48 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Юра. Константин прав. Роллап не спасет. Это примочка для простейшей задачи. Тут приходится считать данные несколько проходов используя таблицы с промежуточными результатами. Иными словами, все OLAP это фантики по сравнению с DWH. 2Константин. Если сравнивать MOLAP и ROLAP, то выигрыш MOLAP хотя и большой, но всего на порядок. По аналогичным тестам Unisys видим что MOLAP опережает ROLAP и простой SQL-запрос в 8-12 раз на одном железе. Однако не в 100-1000 раз. Иными словами, можно стрелять в факты иногда SQL-запросами особенно когда они такие, что MOLAP-агрегаты плохо помогают. Вы к слову не поняли суть идеи оптизации под MOLAP, которую мы обсуждали со специалистами Microsoft. Факты сканировать действительно не нужно, сканируются агрегаты хождением по дереву Абонентов. То что предлагает Моша вполне работоспособный вариант для торгой сети с номенклатурой 500 тыс. позиций. Будет считаться через MDX и работать быстро хоть на 1 млрд. фактов и не нужно без конца строить дисковые массивы. У меня просто случай экстремальный. Или вы хотите сказать, что у вас тоже что не день так 100 млн. фактов и измерение на 5 млн. членов. :) Что я крутил в MS SQL. Во-первых джентельменский набор действий конфигурации сервера (память, диски, буфера и т.д.). Но главное не этом. Я избавился от вложенного запроса, который MS SQL выполняет всегда плохо (поэтому Rollup от Cognos мертворожденный инструмент для MS SQL). Я построил небольшую группу специально идексированных таблиц между которыми переливал данные как по своему Query Plan. В 3 прохода результат получился удовлетворительный. Чистое TSQL программирование. Надо сказать, что не ожидал я от MS SQL такой прыти в быстродействии в последнюю пару лет. Эх блокировки еще бы поправили бы. Сервер-то почти не меняется, но быстро растет скорость за счет нового железа. Я сейчас ночью оптимизил калькуляцию Лукойла. Точнее делал review кода. По привычке на автомате везде делал оптизацию слегка корректируя код. Было 6 часов, стало 2 минуты (прибил пару бутылочных горлышков). Но это калькуляция большой производственной группы. С другой стороны какая разница 6 часов или 2 минуты, ночь-то 8 часов. Я правда считаю что смысл есть, сокращаются циклы тестирования и юзер пусть радуется как ребенок когда отчет строится быстрее чем он успевает думать, а не наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2004, 08:15 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Владимир, Роллап не спасет. Это примочка для простейшей задачи. Иными словами, все OLAP это фантики по сравнению с DWH. Только не надо путать External Rollup (Свертка, про которую я говорил) и термин ROLAP. Rollup потому и назван External, что вычисления/агрегации происходят вне OLAP-кубов, в том числе их можно делать в DWH. Если сравнивать MOLAP и ROLAP, то выигрыш MOLAP хотя и большой, но всего на порядок. По аналогичным тестам Unisys видим что MOLAP опережает ROLAP и простой SQL-запрос в 8-12 раз на одном железе. Я бы так сильно не преуменьшал пользу MOLAP. Если брать один конкретный запрос или отчет - то оптимизированный ROLAP не сильно отстанет от MOLAP. Но ведь понятно что в жизни у пользователей есть потребность в получении серии ответов на их вопросы, зачастую эти вопросы - непредсказуемы, и для каждого запроса заранее ROLAP нереально оптимизировать. поэтому Rollup от Cognos мертворожденный инструмент для MS SQL Ты имеешь в виду, что если OLAP-клиент PowerPlay делает свертку на основе неаддитивного показателя типа Distinct Count из куба MS AS, то результат получится неверным, поскольку сам MS AS этого не умеет и передаст OLAP-клиенту неверный результат выполнения запроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2004, 10:14 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
на основе неаддитивного показателя типа Distinct Count из куба MS AS, то результат получится неверным, поскольку сам MS AS этого не умеет и передаст OLAP-клиенту неверный результат выполнения запроса? В этой ситуации MS AS не возврашает неверный результат, а возвращает ошибку "Aggregations are not supported for the DISTINCT COUNT measure". Пример из Foodmart database: Код: plaintext 1. 2. Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2004, 22:21 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Владимир: Вы к слову не поняли суть идеи оптизации под MOLAP, которую мы обсуждали со специалистами Microsoft. Факты сканировать действительно не нужно, сканируются агрегаты хождением по дереву Абонентов Не понял, явно это написал и попросил объяснить. Но объяснения не получил :( Можете, всё-таки, объяснить? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2004, 10:22 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Константин. В MS AS через язык MDX можно обращаться к агрегатам, если агрегата нет, MS AS его досчитает on fly используя соседние агрегаты. Поэтому для решения в MS AS данной задачи можно просто обходить измерение Абонентов и спрашивать агрегации count по ним. В данном случае это работает не слишком здорово. Абонентов много, а MDX считается на клиенте. Сами агрегаты мелкие, т.е. не слишком эффективные, возможно их и просто нет. Однако если бы это было измерение Номенклатура с хорошей структурой в несколько уровней и до 500 тыс. элементов картина сразу бы поменялась. Хорошие агрегаты по уровням, относительно не много элементов. Обход их не столь проблематичен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2004, 21:52 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Это я понимаю, но я не понимаю, как можно Distinct Count по произвольному периоду в агрегатах держать. Про фиксированные понимаю, а вот для проихвольного периода всяко надо в факты идти. Ведь DC по соседним агрегатам не посчитать. Или не так? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 01:04 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Во-первых для нашей задачи достаточно простого Count, а не DC, раз мы ходим по Абонентам. Во-вторых, MS AS едиственный MOLAP, который умеет физически агрегировать DC и довычислять его on fly. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 01:39 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Владимир, Я вот чего не понимаю насчет Distinct Count: Как говорит г-н Моша: В этой ситуации MS AS не возврашает неверный результат, а возвращает ошибку "Aggregations are not supported for the DISTINCT COUNT measure". В то же время Константин спрашивает (видимо не понимая ответ Моши): но я не понимаю, как можно Distinct Count по произвольному периоду в агрегатах держать И ты отвечаешь: Во-вторых, MS AS едиственный MOLAP, который умеет физически агрегировать DC и довычислять его on fly. Ты согласен с ответом Моши? Или ты имеешь в виду только вычисление DC для фиксированных узлов/листьев измерений, которые заложены в иерархию куба? И вопрос к твоим знакомым из отдела маркетинга Microsoft: знают ли они алгоритмы работы с DC, заложенные в другие OLAP-сервера, например в Cognos PowerPlay, когда говорят о "единственности MS AS"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 09:34 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Во-первых для нашей задачи достаточно простого Count, а не DC, раз мы ходим по Абонентам. Вот этого я тоже не понимаю. Если, конечно мы зафиксируем задачу на уровне хождения только по агрегатам, привязанным к измерению Абонентов, то да, согласен, для каждого абонента храним сколько он звонков сделал за предопределённый период времени (в соответствии со структурой последнего). Если же требуется информация по произвольным периодам, то я не знаю, как для решения этой задачи могут помочь агрегаты - DC суть неагрегируемая величина. Ну, а по поводу уникальности MS AS ссылка на достоверный источник о его единственности в плане этой замечательной возможности не помешала бы. Если мне не изменяет склероз, то Distinct Count - это стандартная фича в Cognos PowerPlay (естественно, по заранее определённым уровням иерархии, правильно, Юра?) С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 11:49 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, Если мне не изменяет склероз, то Distinct Count - это стандартная фича в Cognos PowerPlay Да, DC - это стандартная функциональность PowerPlay, показатель DC делается несколькими кликами мышки (нужно просто указать координаты уровня иерархии, элементы которого будут подсчитываться - измерение, в котором он находится, и его уровень). В кубе PowerPlay может быть более одного (несколько или много) показателей типа DC. естественно, по заранее определённым уровням иерархии, правильно, Юра? А вот тут Вы либо не правы, либо нечетко сформулировали. Что значит "по заранее определённым уровням иерархии"? Например, у меня есть показатель DC - Количество клиентов, и ось времени Год-Месяц-День. Я легко могу с помощью операции СВЕРТКА в интерфейсе конечного пользователя вычислить Количество клиентов за произвольный период времени (с любой даты по любую). Это одно из сильнейших конкурентных преимуществ Cognos над MS AS. Пользователям MS AS нужно ждать выхода Юкона, в нем должна появиться возможность свертки, но Юкон как известно выйдет в лучшем случае через год... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 12:24 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Константин, я советую вам на досуге поиграться с MDX. Там есть много продуктивных идей. В Юконе он станет серверным и скорее всего станет "де-факто" стандартным языком для MOLAP. В формуле обсуждавшейся выше прописано, что обходить по Абонентам. Конечно в отчете измерение Абоненты ракрыто редко, если выбраны другие измерения формула все равно сканирует Абонентов, но учитывает выбранные значения в других измерениях. Если говорить о DC в Cognos и MS AS, то ограничения MS AS связанны с наличием того что в MS AS мы имеем настоящий ФИЗИЧЕСКИЙ DC, а в Cognos он on fly - т.е. эмуляция реальной агрегации. Понятное дело что при кубе с большим количеством фактов и измерений MS AS делает на DC всех, т.к. ФИЗИЧЕСКИ агрегирует DC. Такая агрегация довольно сложна, т.к. не аддитивна, я сомневаюсь, что кроме MS в ближайшее время кто-то будет иметь такой же DC. Наличие ограничения на DC по произвольному периоду несущественно, если у вас хорошо проработанное измерение Времени и оно содержит в себе стандратные периоды (месяцы, декады, недели, дни). Пользователю в 95% случаев нужен отчет не за произвольный период, а за отчетный период или его стандартный квант. Поэтому я даже в обычных отчетах не рекомендую использовать произвольные периоды, т.к. стандартные быстрее работают и их удобнее выбирать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 16:15 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Владимир, Понятное дело что при кубе с большим количеством фактов и измерений MS AS делает на DC всех, т.к. ФИЗИЧЕСКИ агрегирует DC. Не согласен. количество фактов и измерений практически не влияет на скорость расчета DC. Самый важный фактор - это количество листьев, которые обсчитываются. К счастью много листьев (больше миллиона) бывает в кубах не так часто, и еще реже по ним считают DC. Наличие ограничения на DC по произвольному периоду несущественно Пользователю в 95% случаев нужен отчет не за произвольный период, а за отчетный период или его стандартный квант Это конечно так, но бывает 5% случаев, когда требуется произвольный период :) Напомню кстати, что DC в Cognos агрегируется ФИЗИЧЕСКИ с помощью External Rollup, и при этом пропадает возможность делать отчеты с этим показателем за произвольный период. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 17:13 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Количество фактов не влияет только MS AS, точнее влияет только на процессирование. В других системах для подсчета DC нужно все время доставать до фактов, т.к. DC не аддитивен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 17:34 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Пользователю в 95% случаев нужен отчет не за произвольный период, а за отчетный период или его стандартный квант. Поэтому я даже в обычных отчетах не рекомендую использовать произвольные периоды, т.к. стандартные быстрее работают и их удобнее выбирать. Кому как. Очень часто необходимы расчеты скользящего среднего и прочие развитые аналитики. Не согласен. количество фактов и измерений практически не влияет на скорость расчета DC. Самый важный фактор - это количество листьев, которые обсчитываются. К счастью много листьев (больше миллиона) бывает в кубах не так часто, и еще реже по ним считают DC. Размер таблицы фактов еще как влияет. Из практики - DC как раз и считается по большим измерениям, где лимон листьев - обычное дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 17:47 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
To Владимир & backfire: В других системах для подсчета DC нужно все время доставать до фактов, т.к. DC не аддитивен. Размер таблицы фактов еще как влияет. Не знаю как во всех системах, но в Cognos PowerPlay вряд ли нужно доставать до фактов - думаю существует более хотрый алгоритм. У меня есть кубик с демо-данными для розницы (140 миллионов записей, по 100 тысячам товаров, по 10 тысячам владельцам дисконтных карт, за 3 года, есть еще кассы и кассиры). Когда я работаю с DC для касс и кассиров - все летает, поскольку их немного, когда подсчитываются более ветвислые товары и клиенты - там DC притормаживает на неразогретом кэше)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 18:45 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
2Юра. Если это так, то Cognos умеет делать физ. агрегацию DC. Однако ты ранее это сам отрицал. 2backfire. У нас клиенты довольно часто используют скользящие показатели. В нашем типовой методичке по внедрению по ним страниц 20. Скользящий показатель не обязательно должен работать на группе выбранных периодов по дням как произвольный период. Если вы об этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 20:14 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Я хотел еще добавить, что в AS, Distinct Count может быть определен не только по измерению (dimension) а по любой колонке в fact table. Т.е. если надо посчитать сколько было distinct Web page visitors скажем на microsoft.com, то не обязательно создавать измерение Visitor (которое будет много миллионов элементов). Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 21:52 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Иванову. Объясните тогда пожалуйста, какой прок от предаггрегаций DC если нам надо иметь данные за май, апрель и март? Эти месяцы не относятся к одному кварталу, поэтому наличие аггрегаций DC ни для уровня дня ни для уровня месяца ни квартала не помогут при определении и MS AS как миленький должен будет спуститься до голых фактов и шерстить их. Если я в свох рассуждениях щаблуждаюсь, то проясните пожалуйста, ы чем я не прав. Второй часто встречаемый Use Case - количество клиентов покупавших товары или А, или Б, или С в рассматривемом периоде. При этом не существует группы товаров, которая образована А, Б и С ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 21:56 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
backfireОбъясните тогда пожалуйста, какой прок от предаггрегаций DC если нам надо иметь данные за май, апрель и март? Эти месяцы не относятся к одному кварталу, поэтому наличие аггрегаций DC ни для уровня дня ни для уровня месяца ни квартала не помогут при определении и MS AS как миленький должен будет спуститься до голых фактов и шерстить их Согласно этой логике, даже если надо получить DC за квартал а аггрегация на уровне месяц, то надо "шерстить факты". Однако это не так. MS AS все равно может воспользоваться такой аггрегацией (хотя по другому чем в случае с аддитивными мерами). Ну а Юкон может пользоваться аггрегациями и для того чтобы ответить на вышеперечисленные вопросы. Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 22:03 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Моше Сможет или уже может? /topic/75245&pg=-1#556357 Где можно пообщаться, чтобы не повлечь нарушения НДА. На английском писать влом :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 22:10 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Согласно этой логике, даже если надо получить DC за квартал а аггрегация на уровне месяц, то надо "шерстить факты". NonEmptyCrossJoin - достаточно мощная штука и умеет хорошо "шерстить факты" без создания меры типа DC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2004, 22:14 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Владимир, Когда я работаю с DC для касс и кассиров - все летает, поскольку их немного, когда подсчитываются более ветвислые товары и клиенты - там DC притормаживает на неразогретом кэше)... Если это так, то Cognos умеет делать физ. агрегацию DC. Однако ты ранее это сам отрицал. Я и сейчас отрицаю, что Cognos делает полную физ. агрегацию DC - если бы это было так, то размер кубов был бы не такой компактный. Возможно он делает частичную агрегацию. Но скорее всего Cognos использует хитрый алгоритм, например налету смотрит, какие клиенты покупали что-то в один период времени, в другой период, сравнивает эти списки клиентов и вычисляет DC - при этом не нужно опускаться до работы с таблицей фактов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2004, 10:28 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Mosha Ну а Юкон может пользоваться аггрегациями и для того чтобы ответить на вышеперечисленные вопросы. backfireСможет или уже может? Уже может. backfireГде можно пообщаться, чтобы не повлечь нарушения НДА. Скоро выйдет Beta 2 без NDA. Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 09:41 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Моше Ну хотя бы намекните, когда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 10:13 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Цитирую оффициальные источники: "We are still on track to deliver Beta 2 during the first half of 2004 (in the coming months)." Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 10:16 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
To Mosha "first half of 2004 " Т.е. в ближайшие 35 дней? Ну что же посморим... и порадуемся, если до наступления 01.07.2004 мы сможем в этом форуме открыто обсуждать Yukon. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 11:23 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Обсуждать Юкон можно уже давно. Для этого есть закрытые форумы для участников тестирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2004, 02:55 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Иванову. Только вот вы там почему-то не пишете, я то же. Тоже на английском влом писать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2004, 10:22 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Почему пишу. Есть и русскоязычный, ближе чем вы думате. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2004, 23:20 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Поделитесь пожалуйста ссылочкой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2004, 20:17 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
В почту. Только без гарантии. Запуск в зверинец не от меня зависит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2004, 00:48 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
это я писал чуть вышеЯ таки загрузил 100 млн. строк в Терадату. Выполнил обсуждаемый выше запрос с фильтром на 10 дней и 100 продуктов. Запрос выполнялся в Терадате 3 минуты 5 секунд. Запрос на периоде в 30 дней выполнился за 8 минут 34 секунды. На периоде в 60 дней - за 21 минуту 17 секунд (правда, эксперимент я немного испортил, поскольку в это время ещё что-то делал параллельно с выполнением запроса). В любом случае, геометрической прогрессии я здесь не вижу. При этом надо заметить, что процессор был занят в среднем не более, чем на 25 процентов. Основная нагрузка была на диск. Это означает, что, если у меня в наличие будет 4 диска, то я имею возможность сократить время выполнения данного запроса в четыре раза даже, если останусь на одном процессоре. Это оценка довольно грубая, реальный выигрыш от добавления дисков может быть больше. Если это - дисковый массив из 10 зеркальных пар, то выигрыш будет ориентировочно в 20 раз. Поднял сервер с Терадатой в скромной конфигурации - 2 процессора, 3 SCSI-диска. Соответственно, 3 единицы параллелизма. Загрузил 100 миллионов записей. Вот какие результаты получились на запросах distinct count: Собственно, запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Результаты: На 10 днях запрос отрабатывает за 37 секунд На 30 днях - за 2 минуты 8 секунд На 60 днях - за 7 минут 15 секунд Видно, что на 60 днях разница ровно в 3 раза по сревнению с конфигурацией на ноуте с одним диском. То есть, повышение уровня параллелизма даёт пропорциональный выигрыш. Соответственно, мои оценки оказались правильными. Через некоторое время у меня будет сервер немного помощнее. Проведу ещё раз эксперимент, чтобы удебиться в масштабируемости. Попробую нагенерировать для этого побольше записей. Интересно, что будет на миллиарде записей? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2004, 19:30 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Как я уже отмечал выше, нам удалось решить эту задачу на MS AS, введя в эксплуатацию систему с временем отклика 1 секунда. Тем не менее, для себя я сделал поучительные выводы. 1) Сложные запросы поверх 100 млн. записей при построении DWH вытягивает MS SQL нормально, существенно лучше чем 2 года назад. Вероятно это прогресс "железа". Тем не менее на эту технику можно делать ставку. 2) Если ROLAP полность проигрывают MOLAP в оборотных задачах и производных от них, то в сложных вычислениях ROLAP еще боец (вероятно после Юкона это утверждение уже будет не верным). Тем не менее, я сейчас делаю любопытный проектик в ROLAP под MS AS с нелинейкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2004, 00:10 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
с нелинейкой что под этим понимается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2004, 01:54 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Нелинейка - это значит, что применяются неаддитивные (нелинейные) меры. Сейчас любопытный кубик выходит с анализом рекламы на TV. Там делается анализ всплесков покупок после рекламы. Забавная задачка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2004, 22:10 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Конечно "неаддитивные меры" это звучит банально и буднично, но зачем же народ пугайть "своими" терминами. Вам самим то термин SCD не нравился как то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 02:02 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
В продолжение к предыдущим постам... Настроил Терадату в конфигурации с 10 зеркальными парами и двумя процессорами. Соответственно, 10 единиц параллелизма. Каждая единица параллелизма (называется AMP - Access Module Processor) работает со своим диском (с зеркальной парой) и, соответственно, со своим кусочком таблицы. Загрузил 500 млн записей. Соответственно, на каждом диске лежит 1/10 часть таблицы, то есть 50 млн. записей. Выполнил запросы, обсуждавшиеся выше. Получил следующие резцльтаты: Запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Результаты: На 10 днях запрос отрабатывает за 45 секунд На 30 днях - за 2 минуты 35 секунд На 60 днях - за 5 минут 25 секунд Делаем выводы: Мощность сервера по количеству единиц параллелизма выросла приблизительно в 3,3 раза. Количество данных выросло в 5 раз. При этом производительность на том же запросе осталась примерно на том же уровне. Эксперименты продолжаются... С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2004, 16:02 |
|
||
|
Задача на Distinct Count для GSM-логов
|
|||
|---|---|---|---|
|
#18+
Продолжение... Все эксперименты до данного момента были направлены на попытки посмотреть на производительность Терадаты в плане поддержки железа. Теперь посмотрим, что можно сделать в плане индексирования. Построим следующий индекс: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. А теперь выполним наш запрос. Получаем следующие результаты по скорости: На 10 днях - 14 секунд На 30 днях - 41 секунда На 60 днях - 1 минута 21 секунда Получили прирост производительности ещё примерно в 3 раза. Понятно, что не одна секунда, но, очевидно, что время отклика адекватное. При этом я, всё-таки, остаюсь на реляционной БД без необходимости проектировать, процессить, администрировать и подкручивать кубы. Соответственно, нет дублирования данных, нет необходимости всё это администрировать. И мне не надо писать MDX для данного запроса - SQL очень простой, генерируется автоматически. Преимущества налицо. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2004, 19:00 |
|
||
|
|

start [/forum/topic.php?all=1&fid=49&tid=1872432]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
108ms |
get tp. blocked users: |
1ms |
| others: | 259ms |
| total: | 458ms |

| 0 / 0 |
