about HANA modeling

[Former Member]

I've read so many topics and manuals, but I've realized I need your advice.

Now I want to implement the concept of "new" budgeting data model with HANA.

The main question is budgeting systems often should be very well optimized both for read and write operations.
Here I see the combination of row store and column store tables - first for writing, second for reading.
But I see everywhere that combining these two types in one data model is fully restricted (due to slow performance issues).
Can you suggest any method to combine these tables in one data model?

I've found only database triggers: partitioned row fact table (for insert), trigger on insert and partitioned column store table (for reading).

Rescpectfully,

Nikita

[former_member209292]

Hello everyone,

You can also read this very interesting white paper from Vishal Sikka.

Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth

http://delivery.acm.org/10.1145/2220000/2213946/p731-sikka.pdf?ip=169.145.128.31&acc=ACTIVE%20SERVIC...

Regards
Patrick

[former_member184768]

Hi Nikita,

In addition to what Lars already mentioned, the columnar table in HANA is also optimized for write operations in the DELTA memory of the table. The faster write (to Delta memory) and faster read (from Main Memory) has already been implemented by HANA.

So the columnar table would be the right choice to go with. I think SAP has already implemented HANA with columnar table architecture (not very sure as I haven't seen it yet, but I am very sure it would be that way) for business suite which is expected to have faster write operations.

Regards,

Ravi

[lbreddemann]

Hi Nikita,

to me row store is always the last resort in HANA.

If for some reason it is really unfeasible to go with the column store, then row store comes into play.

Of course column store has major benefits when reading data, while comparatively the amount of work to do when changing data in the row store is smaller.

However, you use HANA because you want to leverage all the features like partitioning, compression, intra-statement parallelity etc.

All this is available when dealing with column store tables, but not with row store tables.

Also, row store tables cannot be used in any of the modelled views and using SQL that mixes tables from row and column store suffers from the decreased performance due to the switch of execution engines during the statement execution. (to switch execution engines, temporary result sets need to be materialized and handed over to the other engine - this takes time).

Therefore, I would rather design the whole data model with column store tables and only when it really becomes clear that e.g. the load of data changes cannot be handled properly by the column store, only then I'd go for the row store tables.

- Lars