Earlier this week, Microstrategy made Mark LaRow available to talk about technology. The proximate reason was my recent mention of Microstrategy’s mobile BI emphasis, but we also touched on Microstrategy’s approach to in-memory business intelligence and some other subjects. We didn’t go into the depth of a similar conversation I had recently with Qlik Technologies, but I found it quite interesting even so.
Highlights of the in-memory BI discussion included:
- Microstrategy’s in-memory BI data structure is some kind of simple array, redundantly called a “vector array.” A more precise description was not available.
- While early versions of the capability have been around since 2002, Microstrategy’s in-memory BI capability only got serious with Microstrategy 9, which was released in Q1 of 2009. In particular, Microstrategy 9 was the first time in-memory BI had full security.
- Mark says a core reason for having their own in-memory BI is because Microstrategy has more smarts to predict which aggregates will or won’t be needed. Strictly speaking, that can’t be argued with. Vendors like Infobright would argue they come close enough to that ideal as to make little practical difference – but I’m also cheating by naming Infobright, which is particularly focused in that direction.
- Microstrategy in-memory BI compresses data by about 2X. Mark didn’t know which compression algorithm was used.
- The limitation on what’s in-memory is, of course, how much RAM you can fit on an SMP box. Microstrategy has seen up to ½ terabyte deployments.
- In-memory Microstrategy data structures are typically built during the batch window, for performance reasons. This is not, strictly speaking, mandatory, but I didn’t get a sense that Microstrategy was being used for much that resembled real-time business intelligence.
- Mark said Microstrategy has no interest in using solid-state memory to expand the reach of its in-memory BI. Frankly, if Microstrategy doesn’t change that stance, it’s in-memory BI capabilities are unlikely to stay significant for too many years.
Another key subject we discussed was Microstrategy’s view of dashboards.
- Microstrategy thinks that what customers really want is to have a whole lot of navigational drilldown options into a few big reports. (“50 pages, 50 columns” was mentioned as an example of “big”.) This has been Microstrategy’s approach for three years or so.
- Microstrategy even offers a version of this in Flash, which can be drilled down on with no calls to the server whatsoever.
- This is also Microstrategy’s paradigm on the iPhone and iPad, where it would seem to make particular sense since you aren’t exactly going to tile a portal page into 6 different charts anyway.
- On the iPhone/iPad, this is all native code, with a simple local data structure. In a parallel project, Microstrategy is researching HTML 5.
- Microstrategy would rather call all this “microapps” than “dashboards.”
We also discussed Microstrategy’s approach to alerting. Highlights included:
- Microstrategy 9 introduced an alerting capability that Microstrategy sees as differentiated enough to emphasize in lots of sales cycles.
- Microstrategy’s alerting capability lets you set “thresholds”.
- A typical Microstrategy threshold would be a percentage change in a variable vs. another time period. You get to specify the variable (duh), the percentage, and the time comparison.
- When a threshold is crossed, Microstrategy sends you an alerting email. (There’s something native to Apple that’s an alternative for Apple platforms.)
We discussed one other subject as well, kicked off by my question “So why does Microstrategy spawn all those temporary tables anyway?” Mark and I more or less agreed:
- Microstrategy tries to do bigger queries than some of its competitors like to handle, by relying more on the DBMS for query execution.
- Not coincidentally, Microstrategy is often the favorite BI vendor of analytic DBMS vendors (and even some Hadoop folks) who specialize in very large data sets.