3 ms·

This piece reiterates a bunch of the usual misunderstandings of OLAP. Likely because it’s following the DBMS community’s redefinition of OLAP towards cross-tab

This piece reiterates a bunch of the usual misunderstandings of OLAP. Likely because it’s following the DBMS community’s redefinition of OLAP towards cross-tab group-by, and away from the higher end of the OLAP market. The “cube” is just as much a logical construct as a SQL table is, and just because row stores were bad at certain analytics didn’t mean that SQL was. Compressed column-stores hurt OLAP, because update throughput (the “on-line” in OLAP) is relatively bad. Uncompressed / array stores are quite good. The quantity and complexity of SQL necessary for a non-trivial OLAP view is daunting: time-series views (mix YTD and current-period calcs for transactional and balance accounts, get the ratio measures calculated, and handle the joins necessary for calculating and aggregating from the many (easily dozens) of fact tables that have different dimensionality and granularity and need to be joined at their finest detail. The user will want to see a set of metrics for a pair of orgsnizational units, and also as a percentage difference between the two org units. SQL does not have inter-row calculations, so quite a bit of work goes into re-shaping the SQL cursor’s results to something the user wants to see. All that query generation and result transformation is part of the value-add of the “cube” server. So the OLAP cube as a logical construct is definitely not fallen. Just the bad ones. They’re less flexible than SQL but provide way more productivity within the query space they’re built for.

davedx 7y ago
> Compressed column-stores hurt OLAP, because update throughput (the “on-line” in OLAP) is relatively bad. Uncompressed / array stores are quite good. But why do you want high update throughout when you're doing mostly reads? Every definition I read about OLAP says this is one of the fundamental differences, or am I misunderstanding something?
- alexhutcheson 7y ago
  Your users want their dashboards and reports to contain data that's as up-to-date as possible. No one is happy about waiting 24 hours or more for a batch update to run if there are decisions they need to make right now. The difference vs. OLTP is that it might be acceptable for events to take minutes or even hours to be reflected in the database, vs. ~seconds or less for a transaction where the user is interacting and waiting for a confirmation.
  - amylene 7y ago
    Most of the users I work with, when asked why they want more than daily batches, respond with something emotional and not business value. I had a request for real-time updates for a massive metric that is based around monthly usage. Ya just gotta push back, and hep people understand what the trade offs are for real-time. Most people don’t need it.
    - quantified 7y ago
      Absolutely true. The ones that do, do. For example, multiuser planning systems absolutely do. And those were what OLAP was originally intended to support.
- quantified 7y ago
  You’re missing the important definitions from back when OLAP originated. There is a high update rate for the use cases I build software for.

davedx 7y ago

> Compressed column-stores hurt OLAP, because update throughput (the “on-line” in OLAP) is relatively bad. Uncompressed / array stores are quite good. But why do you want high update throughout when you're doing mostly reads? Every definition I read about OLAP says this is one of the fundamental differences, or am I misunderstanding something?

alexhutcheson 7y ago
Your users want their dashboards and reports to contain data that's as up-to-date as possible. No one is happy about waiting 24 hours or more for a batch update to run if there are decisions they need to make right now. The difference vs. OLTP is that it might be acceptable for events to take minutes or even hours to be reflected in the database, vs. ~seconds or less for a transaction where the user is interacting and waiting for a confirmation.
- amylene 7y ago
  Most of the users I work with, when asked why they want more than daily batches, respond with something emotional and not business value. I had a request for real-time updates for a massive metric that is based around monthly usage. Ya just gotta push back, and hep people understand what the trade offs are for real-time. Most people don’t need it.
  - quantified 7y ago
    Absolutely true. The ones that do, do. For example, multiuser planning systems absolutely do. And those were what OLAP was originally intended to support.
quantified 7y ago
You’re missing the important definitions from back when OLAP originated. There is a high update rate for the use cases I build software for.