Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Задача на 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 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32527220&tid=1872432]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
130ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 474ms |

| 0 / 0 |
