Menu
Do in-memory OLAP engines have advantages over the traditional OLAP engines backed by enough RAM to contain the entire cube(s)?
For example, if I use a MOLAP engine (SSAS) and GB / TB of RAM where the entire cube (or even star-schema) is RAM resident, what is the difference compared to something like TM1 / SAP HANA?
528
A modern in-memory database allows all types of data to be stored in a single system, including structured transactions and unstructured data such as voice, video, free-form documents, and emails – all with the same fast access capability.
In-memory OLAP is an approach where the analytical data is loaded into the memory for on-line calculations and queries. Thus, queries operation becomes faster, then in such systems as ROLAP, MOLAP and HOLAP.
In-memory databases are faster than traditional databases because they require fewer CPU instructions. They also eliminate the time it takes to access data from a disk. In-memory databases are more volatile than traditional databases because data is lost when there is a loss of power or the computer's RAM crashes.
Aggregation Level. You can also improve OLAP performance when you set the cube's aggregation level. When you build a cube, you set the aggregation level according to the desired speedup in processing queries. (Speedup describes how much faster queries run with precreated aggregations than without aggregations.)
Basically it comes down to the following:
A system that is really optimized for "in-memory" operations takes into account several aspects like random access, memory page size, different cache levels (CPU, ...) etc.
This leads to a maximum use of the possibilities that RAM offers and HDD does not offer which in turn makes for excellent performance.
A traditional engine which is optimized for filesystem access is usually taking into account several aspects relevant to files/OS handling of filesystem etc.
Even when such an engine loads everything into its cache (memory) it still operates on the data AS IF it were on disk which makes sense since the code must work in situations where not everything fits into memory too. Using the same implementation for both situation makes for better testing/stability/bug-fixing/maintainability etc. BUT this leads to "not taking advantage" of all that makes RAM access different from file/disk access. Such an engine usually can be made faster IF it implements RAM specific optimizations so that it offers in each world (RAM versus disk) the best ... I am not aware of any engine doing that ...
178
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
