5 ms·
I've been doing OLAP for over 20 years, so I can say with authority that OLAP is generally a bag of hurt. The tooling sucks, the languages suck, the costs suck
by intrasight 5y ago
I've been doing OLAP for over 20 years, so I can say with authority that OLAP is generally a bag of hurt.
The tooling sucks, the languages suck, the costs suck. The name itself harks back to seemingly a time before
computers. "Online"? As opposed to paper tablets?
- deleted 5y ago[deleted]
- myohmy 5y agoOLAP is legacy hell. I built an MDX query to solve a report problem, but now I can't replace it because my seniors failed to deconstruct it because it is stupid difficult to wrap your head around. So now it sits in limbo until I can find time to do the work myself. Let me just take a look at my calendar and find my next free week... oh, there is none.
- papandada 5y agoI keep feeling like this is room for a better language than MDX... And DAX isn't it either.
- intrasight 5y agoMDX is brilliant but challenging - especially if you don't work with it on a regular basis.
- papandada 5y agoThat's my experience for sure. I haven't thought all that hard about this but I wish there was a language lessened that wall of incomprehension I face every infrequent time I go back to MDX -- that's what I mean by room for another language.
- intrasight 5y agoA great deal of effort by very clever people went into MDX. Well one clever individual anyway - Mosha Pasumansky - whom I had the pleasure of once meeting. He moved on to working on BigQuery at Google - so yeah, MDX is dead.
- goodpoint 5y agoOnline as opposed to batch.
- intrasight 5y agoI know. But still, you must agree, a stupid name. The rest of the IT industry would say "real-time vs batch". And OLAP is batch for most implementations.
- bradleyjg 5y agoReal-time is engine control software not a webpage with a spinner.
- purerandomness 5y agoThe name was coined way before "online" meant what it means today.
- dredmorbius 5y agoIt's far less online contrasted to what, than analytic processing contrasted to transaction processing. OLAP was a departure from OLTP, online transaction processing, the mainstay of business transactional networks. And of course, both are contrasted to batch processing which occurs later or after the fact, though in practice, much OLAP was specific triggered reports or ad hoc analysis, at least from the world as I saw it. Where OLTP and OLAP differ is in that OLTP deals with a transaction at a time, typically following a single entity or account through a single transaction or operation. The data loads are small though the transaction counts are high, and there's virtually no summation of information. Database optimisation is built around these needs. OLAP, in theory, was based around realtime or near-realitime access to transactional data, but the analysis looked across entities (typically accounts, products, divisions, regions, time, etc.), and relied heavily on summarised data (counts, sums, means, medians, min, max, standard deviation, occasionally other metrics). This was typically rationalised by either defining views, or (more often in my experience) by precomputing what were thought to be sufficient and useful summary statistics. (In practice, neither ambition ever seemed to be reliably met, requiring returning to source or disaggregated data.) From a statistical stadpoint, one of the chief failures of OLAP is that it attempts to substitute summarisation for sampling. In practice, a small sample of a very large dataset is quite frequently orders of magnitude more easily compiled and analysed, with very little loss of information. Even aggregate computations can often be closely estimated by this method. The article explicitly makes most of these points, FWIW.