«дата — дата — дата — факт — факт — факт» — это как? OLAP — это тип информационных систем. SQL — язык такой. OLAP система вполне может выполнять sql- запросы.
Спасибо за статью.
Сам наслышан про такие штуки и всегда внимательно смотрел по сторонам и на банкомат, но пару недель назад попался, карта была скомпроментирована, хорошо, что банк — эмитент заблокировал её во время. А поймали меня скорее всего в одном из банкоматов Росбанка в метро в Москве, либо на Дмитровской, либо на Цветном бульваре.
Ага, типичное мнение. На самом деле плюсы есть, но не очевидны. Управленческая отчётность с данными актуальными «на вчера» позволяет руководству эффективнее руководить. А единственный сервер 1с насиловать — не рационально. :)
Автор, лучше поделитесь секретом, как убедили руководство маленькой компании, что оно им надо. :) А то обычно руководство считает, что проще и дешевле нанять пару симпатичных девочек с экселем, чем настаивать бездушную железяку и держать потом толпу программистов, чтоб что-то поддерживать. :)
Таблицу фактов делают как можно более «узкой», избыточность обычно допускается в таблицах измерений, которые дай бог процентов 5 от общего объема достигают да и то в исключительных случаях.
Я про то, что многомерный анализ на сервере OLTP системы и на структуре данных заточенной под OLTP — это зло. Реально при сильно нагруженной биллинговой системе разумно заморочиться c change data capture и переливать данные в data warehouse в ориентированую на многомерный анализ структуру, а там уже заниматься анализом.
Реально если на биллинговой системе организовать Аналитическую отчётность, всё сразу накроется. Прикиньте десяток аналитиков постоянно запускающих запросы, где аггрегируются показатели за последние пол-года, год, а то и три года. Биллинг подождёт что ли? :)
Обычно все данные выгружаются в одно хранилище. Там уже строится КУБ, всё кроссплатформенно.
Если MySQL у вас является источником данных, то самое разумное — вытащить данные из него в другую БД-хранилище.
Насчёт быстрого доступа к данным я бы поспорил. Основное отличие OLAP от OLTP в том, что типичные запросы работают с большим количеством записей, аж до сотен миллионов. И отчёты, которые строятся часами и etl-процессы идущие всю ночь — это не редкость, а скорее обыденность. Просто типичные модели данных для хранилища строятся так, чтобы сократить это время, вот и всё. Ну и реляционная теория никуда не девается. Просто некоторые вещи, типа нормализации зачастую не требуются, а наоборот возбраняются.
Сам наслышан про такие штуки и всегда внимательно смотрел по сторонам и на банкомат, но пару недель назад попался, карта была скомпроментирована, хорошо, что банк — эмитент заблокировал её во время. А поймали меня скорее всего в одном из банкоматов Росбанка в метро в Москве, либо на Дмитровской, либо на Цветном бульваре.
Если MySQL у вас является источником данных, то самое разумное — вытащить данные из него в другую БД-хранилище.