SAP HANA SPS 09 - Whats New?

SAP HANA Scalability

(Delta from SPS08 to SPS09)
SAP HANA Product Management

2014 SAP AG or an SAP affiliate company. All rights reserved.

November, 2014

Disclaimer
This presentation outlines our general product direction and should not be relied on in making
a purchase decision. This presentation is not subject to your license agreement or any other
agreement with SAP.
SAP has no obligation to pursue any course of business outlined in this presentation or to
develop or release any functionality mentioned in this presentation. This presentation and
SAPs strategy and possible future developments are subject to change and may be changed
by SAP at any time for any reason without notice.
This document is provided without a warranty of any kind, either express or implied, including
but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or
non-infringement. SAP assumes no responsibility for errors or omissions in this document,
except if such damages were caused by SAP intentionally or grossly negligent.

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

Scalability
Setting the stage
Scalability is the ability of a computer hardware/software to take full
advantage of its changed context in a re-scaled situation, e.g. by adding or
reducing resources
Vertical Scalability (Scale-up)
Adding resources within the same computing unit, e.g. #CPUs, #DRAMs
Horizontal Scalability (Scale-out)
Adding multiple computing units and making them work as one logical
computing unit

SAP HANA is designed for scale-up and scale-out since the beginning

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

Scale-up

Micro-Architecture Trends
NUMA (Non Uniform Memory Access)
local

remote
CPU 1

RAM

RAM
Core1

Core2

Core1

Core2

RAM

RAM
Core3

Core4

RAM

each socket has its own memory controller (IMC)

scales well, but there are NUMA-effects

memory access is non-uniform -> local vs. remote access

CPU 1

remote Core3

Core4

RAM
high-speed interconnect

CPU 1

CPU 1

RAM
Core1

Core2

Core1

Core2

RAM

RAM

RAM
Core3

Core4

Core3

RAM

2014 SAP SE or an SAP affiliate company. All rights reserved.

Core4

RAM

Public

HANA Parallel Query Processing

multi-query (multi-plan)

multi-user

intra-pop-parallelism (multi-threads)

intra-plan-parallelism (multi-pops)

Core 1:
Query 1:

Join

Aggregate

Sort

Core 2:
Core 3:

Query 2:

Join

Aggregate

Sort
Core 4:

Query 3:

Join

Aggregate

Core 5:
Core 6:
Jobs over time

HANA global optimizer generates

efficient execution plan for each
query (rule-based, cost-based)
Execution plans are cached and reused by HANA

2014 SAP SE or an SAP affiliate company. All rights reserved.

Each execution plan is split into multiple plan

operators (e.g. join, agg, sort) that are
executed in parallel

Plan operators generate job graphs,

containing job nodes

Job nodes are dispatched for execution to

available treads by the Job Executor

Public

Summary: Vertical Scalability in HANA (scale-up)

Parallelism in HANA
HANA is heavily optimized for state-of-the-art HW architectures
HANA uses massive intra-plan and intra-operator parallelism for query execution
HANA tries to use all available resources for maximal parallelization

Challenge: NUMA-effects on large multi-socket systems

Remark: Virtualization of CPU resources can reinforce NUMA-effects

Job Scheduler
Central place in HANA to execute plan-operator jobs
Re-adjust dynamically the concurrency level avoiding over-parallelization
Can consider additional .ini configuration data to limit the concurrency level

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

Scale-out

Horizontal Scalability (scale-out)

General
Scale-out means expanding to multiple servers rather than a single, bigger server in one database system
Multiple servers (nodes) are switched together to one logical, but physically distributed database system
When to scale-out ?
Overcome hardware limitations of one single server (memory, cpu)
Scale-out aims to distribute data and workload

Attention
Scale-out requires deep knowledge about data, application and hardware
Scale-out increases data center operation costs
Scale-out affects your scaling factor by inter-node communication

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

HANAs Shared-Nothing Architecture

A shared-nothing architecture helps to minimize the inter-node communication in distributed environments
Master node

Topology
Each node runs on its own local data (shared-nothing)
Standby node(s) without own persistence

Data
Volume

HDB net

Log
Volume
Slave node

Shared file system for node fail-over and recovery (HW partner
implementation)
Nodes communicate via internal HDB net protocol
All nodes belonging to the same HANA system must have the
same HW setup

Data
Volume
Log
Volume
Standby node(s)

Auto fail-over

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

10

Minimize Inter-Node Communication with Data Distribution

Data distribution aims to find the best balance between data model, data usage and actual workload to minimize internode communication

Analyze

Distribute

Data model

Table co-location

Types of data, e.g. master data, transactional data and

configuration data

Locate interdependent tables on the same node, e.g. for

referential integrity

Referential integrity between tables

Locate tables within the same statement on the same

node, e.g. for collocated joins or transactions

Data usage
Data interdependencies, e.g. table groups

Horizontal Partitioning

Data access paths

Locate interdependent table partitions on the same node

Workload

Table Replication

Mixed workloads, i.e. read/ write, analytical/transactional

Duplicate tables to multiple nodes, e.g. for master data

referenced by many tables

Update frequency

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

11

HANA Data Distribution

Table Placement
Table Placement is the definition of generic table distribution patterns to control the physical location of (column-)tables
and how many partitions of a table are to be created in a distributed HANA system
Step 1. Classification

In HANA it is possible to classify a table by additional metadata, like schema_name, group name, group_type

The table classification can be set with the create / alter table statement

The table classifications are stored in the table sys.table_groups_

Step 2. Table Placement Configuration

For each table classification you can assign a table placement configuration

A table placement configuration defines, on which node type, disk-volume (SPS09) a table and its partitions shall be located

A table placement configuration also defines when a table shall be partitioned (works only if the table has a partition specification), e.g. initial_partitions,
min_rows_partitioning and repartitioning_threshold

The table placement values are inserted via SQL commands into table _sys_rt.table_placement (HANA studio -> SQL-console)

When is the Table Placement Configuration evaluated

During create/alter table and table redistribute operations

The table placement can be overruled with the location_clause, partition_clause or move_clause information in the DDL statement

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

12

HANA Data Distribution

Table Redistribution
Save and restore old
table locations

Typical operations
use a dedicated user with
required privileges

1. Generate Plan

Review Plan

2. Execute Plan

Collects information about landscape and database

Read plan

Evaluates table placement information and .ini-parameter

Parallel execution of plan items

Apply heuristic algorithm to optimize table placement

Plan is always executed completely

Save execution plan with execution order

SAP
Execute
Plan
2014
SE or an
SAP affiliate company. All rights reserved.

SYS.REORG_PLAN_

No automatic rollback, but restore of old table locations possible

Public

13

HANA Scale-out Solutions

BW on HANA
BW workload characteristics

Mostly OLAP workload in rather static distribution environment

OLAP load benefits from parallel processing on distributed partitions

Symmetric scale-out across the system

Master-Node
OLTP
tables

Master Node

Handles OLTP load and DDL statements: ABAP system tables, meta data,
operational tables and all row tables are stored

Slave-Node

Slave Nodes

BW ABAP

will handle OLAP load exclusively:

App-Server

Master data + cubes/DSOs/PSAs are distributed evenly across all slaves

Cube, DSO and PSA tables are partitioned dependent on the table placement rules

OLAP
tables

Slave-Node
OLAP
tables

Useful information

global.ini [table_placement] method= 2 (keeps row-store tables on the master

node)

note #1908075 (BW scale-out configuration recommendations)

2014 SAP SE or an SAP affiliate company. All rights reserved.

Standby-Node

Public

14

HANA Scale-out Solutions

Suite on HANA
Symmetric hardware across the system

Suite workload characteristics

Mixed OLTP/OLAP workloads across all nodes (2PC, Cross-joins)

Table access patterns dynamic and differ from customer to customer

Master-Node
Table
groups

Dynamic Table distribution

Buffered SQL statements in the statement cache are parsed and prioritized
based on DB statistics

Determine disjoint table groups

Table groups are placed on same node while balancing memory and CPU

Slave-Node
Suite ABAP

Table
groups

App-Server
Slave-Node

Useful information

note #1899817 (Suite scale-out configuration recommendations)

Note #1781986 (Suite on distributed HANA database)

Table
groups

Standby-Node

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

15

Takeaways
Scale-up first !
Scale-up
Most common and easiest way for databases to scale
No changes in the database or application required
HANA parallelism strongly supports latest multi-cpu, multi-core HW architectures

HANA NUMA-aware scheduling and memory allocation is under development

Scale-out
Requires deep knowledge about data and workload to achieve good scaling
Scale-out works good in static distribution environments, like OLAP
Scale-out in mixed OLAP/OLTP environments can be challenging
Optimizing scale-out performance is an iterative task

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

16

How to find SAP HANA documentation on this topic?

In addition to this learning material, you can find SAP HANA

platform documentation on SAP Help Portal knowledge center at
http://help.sap.com/hana_platform.
The knowledge centers are structured according to the product
lifecycle: installation, security, administration, development:

SAP HANA Platform SPS

Documentation sets for SAP HANA options can be found at

http://help.sap.com/hana_options:
SAP HANA Options

SAP HANA Advanced Data Processing

SAP HANA Dynamic Tiering

Whats New Release Notes

SAP HANA Enterprise Information Management

Installation

SAP HANA Predictive

Administration

SAP HANA Real-Time Replication

Development

SAP HANA Smart Data Streaming

References

SAP HANA Spatial

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

17

Thank you
Contact information
Ruediger Karl
SAP HANA Product Management
AskSAPHANA@sap.com

2014 SAP SE or an SAP affiliate company. All rights reserved.

 2014 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate
company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its
affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services
are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or
release any functionality mentioned therein. This document, or any related presentation, and SAP SEs or its affiliated companies strategy and possible future
developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for
any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forwardlooking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place
undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.

2014 SAP SE or an SAP affiliate company. All rights reserved.

Public

19