Never used Qlikview, but what I know of it, its main claim to fame is it eliminates the need to pre-build “cubes”, instead lazy-loading data directly from OLTP data structures into internal memory-based structures (a bit like Business Objects operated when I used it last).

I wouldn’t think it would be suitable for large banking or telco datasets (at least without some dimensional pre-processing and hence eliminating one of its selling points) but as I said never used it so I might be wrong.

Tom

Do u have any idea of Qlikview ? How does it tackle with very large (like banks) databases?

thanks for your fast answer. It makes sense and helps to get a clear picture of it.

Ben

PS: I can see the Jedox logo out of my office

All databases and in fact all computing as we know it uses caching, so most every process could be described as in-memory.

When I talk of in-memory OLAP I’m referring to an OLAP model where the whole “database” is loaded into memory, all reading and writing is applied against the in-memory model (with perhaps a redo-log written to disk).

Palo is such a tool, ESSBAse (Hyperion) is not, ESSBase of course uses extensive and sophisticated caching, but it was developed before the days of cheap and abundant memory and uses the disk as its operating store. Palo (and Excel. another in-memory “database”) uses disk as a backup and restore facility not as an operational store.

The ability to write-back (or not) has nothing to do with in-memory “status”, e.g. both Palo and ESSbase allow write-backs.

SQLite can either run in-memory or in conventional cache-disk mode.

The big problem facing in-memory OLAP is the ability to scale to handle very large and sparse datasets, ESSBase for example can deal with these while Palo V2.5 cannot (or at least not as well). But Jedox is to release Palo V3.0 next month which promises to address this issue.

Tom

- Does in memory is for both, ROLAP & MOLAP? you mentioned SQLite as a in memory RDBMS.

- Does in memory needs to have write back to be a “real” in memory solution (TM1, Alea, Palo have write back)

- If a database uses caching, would you say is it already in
memory? The more memory I give MySQL for caching, the more data will be “in memory”. So If I use Mondrian and MySQL, do I have in memory OLAP?

Just a few questions to think about, it would like to hear what you think about it.

Yep, I too struggled a bit with Palo, it didn’t quite gel with my Essbase and ROLAP background. Those who have used TM1 seem to find it very easy to use. That’s a problem with MOLAP in general, no standard way of doing things, no SQL-like standard (MDX anybody?). But I’m now comfortable with it and find it “good enough” for many problem areas.

As for large datasets, I’m not convinced the current V2.0 could handle complex large models, but Jedox are promising significant improvements in speed and in the capabilities of the rule engine with V2.5. And, I’ve found when Jedox promise something they tend to deliver.

I’m an IT professional, with a long history (close-on 30 years) working with “big ticket” software; the FUD of “limited support, limited continuous development funding, etc…” no longer works on me. I’ve seen the likes of Linux,PostgreSQL, MySQL et al. develop into outstanding products, I think Palo has that same potential.

Palo is closer to the MySQL model, in that Jedox offers full support and training to those who need it and is also actively investing the product (e.g. new drill-back capable ETL engine to be added in V2.5).

Which to go for, closed or open source? Depends on an organisation’s attitude to risk, its skills profile, is it an end-user or an IT services provider? The main thing is to keep an open-mind, any CIO/CTO who approves a major new project without at least reappraising the open/closed/cloud/outORin-sourced “balance” isn’t in my opinion acting in the best interests of their organisation.

Tom

Thanks,

Jim