Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
я только сейчас понял что тело «оборачивается переменными».
с нетерпением жду продолжения
с нетерпением жду продолжения
Жаль что данные случайны — думаю многим было бы интересно пOLAPать реальную статистику Хабра.
Спасибо! Интересно.
Жду продолжения...)
Жду продолжения...)
Ипическая сила! Вот это круто! Спасибо большое.
интересно продолжение… если окажется реально удобным надо будет переписать сбор статистики на проекте :)
Очередной раз спасибо за просвещение… теперь хоть в вики заглянул чтобы посмотреть что такое OLAP
хорошая статья, кратко и понятно
только я бы по больше раскрыл суть измерений, в частности, иерархические, так как в основном то они и используются
только я бы по больше раскрыл суть измерений, в частности, иерархические, так как в основном то они и используются
Звезда, снежинка — все это забавно, конечно =)
Но заметьте, ведь строить таким образом многомерные кубы в системе, в которой количество измерений заранее в принципе неизвестно, непреемлемо. Это не есть хороший метод, ИМХО.
Да и, думаю, вообще неинтересно и уныло использовать такие методы. Я хочу сказать, что много лучше было бы строить кубы на основе метаданных измерений, количество которых может быть произвольным, без использования таблицы для каждого измерения. А данные банально храняться в одной таблице, к которой обращаемся с помощью сгенерированных на основе взаимного расположения измерений и выбранных в них элементах SQL запросов.
Но заметьте, ведь строить таким образом многомерные кубы в системе, в которой количество измерений заранее в принципе неизвестно, непреемлемо. Это не есть хороший метод, ИМХО.
Да и, думаю, вообще неинтересно и уныло использовать такие методы. Я хочу сказать, что много лучше было бы строить кубы на основе метаданных измерений, количество которых может быть произвольным, без использования таблицы для каждого измерения. А данные банально храняться в одной таблице, к которой обращаемся с помощью сгенерированных на основе взаимного расположения измерений и выбранных в них элементах SQL запросов.
И при каждом запросе субд выполняет full scan одной большой таблицы?
Забегая наперед, скажу, что, как минимум, начиная с Analysis Services 2005 — это стало возможно. Другое дело, что не зная наперед о структуре ваших данных, куб не сможет преагрегировать значения, а также вы не сможете эфективно использовать кэш сервера. В результате, если построить куб на чисто «виртуальных» метаданных, то выгоды в скорости запросов будут совсем небольшие (для небольших измерений) или их совсем не будет (если размеры измерений превосходят 2-3 миллиона записей). Но, я часто вижу использование подобных «виртуальных» измерений на продакшн системах, особенно для маленьких, динамических измерений (порядка 10-100 членов).
Как я понял, из реальной базы данных при помощи представлений можно сделать «звезду» или «снежинку». Но насколько этот подход рационален?
Смотря с какой стороны посмотреть. Это, однозначно, экономит вам дисковое пространство, но лимитирует вас в гибкости и скорости загрузки данных в куб. Например, если вам нужно каким-то хитрым образом «очистить» данные перед загрузкой, ваше представление может не справится с задачей. Или если само представление будет очень сложным с точки зрения запроса, загрузка данных в куб будет занимать много времени.
Еще как аргумент — очень часто данные в куб берутся из нескольких источников, что делает невозможным использование только представлений.
Еще как аргумент — очень часто данные в куб берутся из нескольких источников, что делает невозможным использование только представлений.
Бывает так, что к «Реально базе данных» вообще не подобраться. Например DBA какого нибудь ораклового сервера, где АБС-ка крутиться вам просто не разрешит создавать на реальной базе свои вьюшки и вообще выполнять какие-либо запросы. Мало ли чё вы там сджойните и как, а потом банк не сможет целый день работать. В таком случае можнл выгружать новые данные в плоские файлы, а оттуда забирать в хранилище.
все эти советы, зачем строить звезду снежинку, из разряда как поменьше работать не думаю о перформансе
метаданные=тормознутось
в этом и есть задача толкового разработчика — проектирование красивой схемы, а не драгэнддроп и тыканье мышкой
метаданные=тормознутось
в этом и есть задача толкового разработчика — проектирование красивой схемы, а не драгэнддроп и тыканье мышкой
Перезалейте изображения, пожалуйста.
Картинки не отображаются
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создаем OLAP куб. Часть 1