HANA Row Based Transaction in Scale-Out

[Former Member]

Hello People,

Can someone verify my understanding of OLTP (row based) transactions on SAP HANA scale out? All transactions should be directed to the Master Indexserver and not any of the slave nodes? I had read that the Master node maintains the row-based tables in memory and handles those requests. I know I can direct jdbc/odbc connections to a slave indexserver but I don't know if this is really accomplishes anything other than redirecting to the master indexserver.

Would it make any sense to distribute OLTP traffic across the various slave nodes of a scale-out cluster? I think from a high availability standpoint the client should failover to the next master node in the Landscape configuration but I am not sure about whether attempting to load balance OLTP queries even makes sense.

Would this also hold for Monitoring Tables/Views?

Thank you,

Sergio

[lbreddemann · Accepted solution]

Hi Sergio

The scale-out model in SAP HANA is based on the data structure of the tables involved.

It is not based on how you use the tables.

So, if you distribute the data over several nodes and do "OLTP"-ish stuff with it, you get OLTP scale-out.

And no, you don't want to setup every table that ever sees OLTP-ish transactions as a row store table.

Really, row store tables should be the exception, when column store really cannot be used.

That's what we also do in SoH, BWoH, etc.

Monitoring views (I assume you mean the M_... views, right?) are handled per indexserver and only eventually accumulated on query time.

However, I fail to see how they are relevant to a load balancing scenario.

Therefore: yes, distributing your connects in a scale-out scenario even with OLTP-ish workload can definitively make sense.

- Lars

[Former Member · Accepted solution]

Lars,

If I could extend or clarify the question a bit, if you do not partition the table on different nodes will it stay with the master indexserver and any queries you initiate on slave nodes will simply query the master node? The reason I ask is I had read on the Scaling section of  SAP BW on HANA cookbook that stated row store data is preserved only on the master node. Maybe my reading interpretation is wrong. Here is the reference.

SAP BW on HANA Cookbook

For the monitoring views(M_...) does each slave node has a copy of these tables/views or is it pulled from the master node when the slave nodes are queried?

Thank you very much for your insight Lars!!!

[lbreddemann · Accepted solution]

Even if you don't partition the column store tables, you can still choose to re-locate them to a different node. That way, you can achieve storage (in indirectly processing-) load balancing even without partitioning.

However, the row store data for BW on HANA is set to be on the master node only, that's correct.

As I mentioned before, these tables are rather selectively chosen to be row store tables, based on the access pattern we know for them.

As you can tell, this assumed access pattern everybody had in mind, when BW on HANA was first released even turned out to be not the hard discriminator for row store usage. In fact, a lot of tables that had initially be assigned to the row store are stored as column store tables in more recent versions of BW on HANA.

Bottom line here: you cannot generalize from the BW on HANA (or any other cookbook) on what you can or not can do with column store tables.

Stick with column store tables as long as possible. That should be the default choice for table type (and yes, the default table type parameter is still left to 'ROW', I know that, but this is in no way a general recommendation on the table type to be used).

For the monitoring tables: "slave" nodes really are not just copies of "master" nodes or anything like that. They are full working indexservers in their own right. "Master" and "Slave" in this matter is about the "nameserver" processes.

Therefore: if you see data in a monitoring table that indicates it came from host X, then you can be pretty sure that this information had just been pulled over from host X to the host your session is connected to.

- Lars

[Former Member · Accepted solution]

Thanks again!