#BWonHANA: Extended Storage and Dynamic Tiering
There is a bit of confusion around the terminology of extended storage and dynamic tiering within HANA. This short blog attempts to resolve this. Details can be found in a PDF presentation attached to OSS note 1983178.
Extended Storage (Only)
This has been introduced and demo’ed in last year’s Teched in Amsterdam with a follow-up and bigger demo here. The notion of an extended tableis introduced which is technically based on IQ technology. The underlying IQ server needs to be installed, updated, maintained separately from HANA. Within BW 7.4 SP5 on HANA SP7, it was possible to pilot this mechanism, namely in the context of tables underlying the PSA and write-optimized data stores.
Dynamic Tiering
HANA’s dynamic tiering capability is planned to be shipped with SP9. In combination with BW 7.4 SP8, it substitutes the pilot setup described above. There will still be extended tables but the separate IQ server is replaced by an ES server that is integrated in the HANA installer, update, management, back-up and recovery mechanisms. There will be a designated node on the HANA hardware running that ES server. This setup will be released for general availability (GA). There will be no migration options from the pilot to the GA version. Details can be found in a PDF presentation attached to OSS note 1983178 or the online documentation.
This blog has been cross-published here. You can follow me on Twitter via @tfxz.
PS (May 2016): Please have a look at updated published by Klaus Nagel on this topic.
So if I understand correctly, the ES server is based on IQ technology but is stripped down to provide just what ES requires rather than a full disk-based RDBMS.
I presume this means that all PSA and write-optimized DSOs can be considered as ES from a HANA sizing perspective. Do we have any idea what this means from an overall sizing perspective?
Suppose we have a customer with a huge PSA, would they perhaps need a RAM cache in IQ that's 10% of the PSA size rather than 100% in HANA? If so, this means that customers who haven't done a good job of housekeeping over the last 10 years could move to HANA first, then do the housekeeping after. That sounds like a huge benefit.
Also, I presume that in the future, there will be in most companies a cold store on the IQ NLS? Therefore there will be 3 data tiers - hot (HANA), warm (ES), cold (NLS)?
Does this also mean that the non-active concept is also effectively not required and will be deprecated?
Hi John,
regarding the potential confusion reg. NLS and active/non-active please have a look at slides 20-24 in the BW 7.4 SP8 roll-out slides, esp. slide 20.
Reg. sizing: yes, BW-on-HANA sizing (OSS note 1736976) accommodates the new "warm tier".
Regards
Thomas
Notice that, at this point, the ES nodes, from a CPU/RAM perspective, will have HANA-like sizing requirements (think about it as a HANA node with more disk attached to it). The esserver and indexserver will be two complementary services of the HANA DB that need to run (at this point) in separate nodes. So NLS will still be more HW-efficient, if the requirement is pure archiving. If the customer does want to possibly change data at some point in time, ES is the way to go.
Great read.. Indeed, Very helpful...
Hi Thomas, great blog!
In the presentation which is available in note 1983178 its says on slide 12 '... Enable ES for additional BW InfoProviders – also on data slices/partitions...'. Then, when comparising ES / NLS on slide 13 it says '... Complete tables/partitions...'.
Is it correct that I can define something like 'older 3 months' for a DSO in order to move this data automatically to ES?
Thanks!
//Olaf
Hi Olaf,
this is currently not possible with the BW-integration of DynamicTiering/Extended Storage. But we are planning to enable these scenarios as well in upcoming BW and HANA releases.
Best regards, Klaus
Hi,
What would be your preference ? Unload priority 7 or extended tables ? I personally have the Impression that Extended tables offer some kind of better control on System resources compared to UNLOAD PRIORITY 7 (warm data).
Kind regards, Philipp
Nice Read