SAP HANA In-Memory Database Sizing Guideline

Transcription

1 SAP HANA In-Memory Database Sizing Guideline Version 1.4 August 2013

2 2 DISCLAIMER Sizing recommendations apply for certified hardware only. Please contact hardware vendor for suitable hardware configuration. Note that HANA is constantly being optimized. This might have impact on sizing recommendations, which will be reflected in this document. Therefore, check for the latest version of this document and the note. Note that the sizing guideline in this document refers to SAP HANA In- Memory Database only. Additional applications running on top of HANA (e.g. Business Information Warehouse, etc.) are not covered in this document (see note for details on sizing BW on HANA).

3 3 SAP HANA In-Memory Database Sizing Elements SAP HANA sizing consists of Memory sizing for static data Memory sizing for objects created during runtime (data load and query execution) Disk Sizing CPU Sizing

4 SAP HANA In-Memory Database Sizing: Summary 1. RAM 2. Disk RAM = Source data footprint * 2 / 7 * c 1) DISK persistence = 1 * RAM 2) DISK log = 1 * RAM 3. CPU CPU: 300 SAPS / active user 3) 1) c = source database specific compression factor (where applicable see page 7) 2) Additional disk space required for backups, exports, shared volumes - see pp. 8f 3) Based on a sample query scenario in a side-by-side scenario with moderate size. Scenarios with higher complexity require scenario specific CPU sizing see pp. 10f 2012 SAP AG. All rights reserved. 4

5 5 Memory Sizing: Static Data Memory requirements for static data is derived from the database footprint of the corresponding tabes of the source database system Database footprint in source system must be determined using database specific catalog information (e.g. in Oracle: dba_segments; in DB2: syscat.tables). Database specific scripts and more details on how to determine the database footprint can be found in note Average compression factor database table size : HANA memory = 7 : 1 Note that this compression factor refers to uncompressed database tables, and space for database indexes is to be excluded. RAM static = Source data footprint / 7 * c 1) 1) c = source database specific compression factor (where applicable see page 7)

6 6 Memory Sizing: Runtime Objects Additional memory required for objects that are created dynamically when loading new data when executing queries We recommend to reserve as much memory for dynamic objects as for static objects: RAM dynamic = RAM static So the total RAM is RAM = RAM dynamic + RAM static = Source data footprint * 2 / 7 * c 1) 1) c = source database specific compression factor (where applicable see page 7)

7 7 Memory Sizing: Remarks Compression in source database The sizing scripts attached to note do NOT take into account reduced sizes of the source data due to database intrinsic compression except the one for DB6, where compression factors for each table are contained in the database dictionary. This script delivers correct results also for a compressed database. If the source database other than DB6 is compressed, you have to adjust the results of the scripts by a database compression factor. Your DB administrator should be able to help obtaining this factor. Unicode vs. Non-unicode database Migration to HANA is only possible from a unicode system, so the sizing scripts assume a unicode enabled source database. If the scripts are executed on a non-unicode database, we recommend to add an uplift (usually, a disk space uplift for Unicode migration of 50% is assumed).

8 Disk Sizing Disk size for persistence layer: DISK persistence = 1 * RAM Disk size for log files / operational disk space: DISK log = 1 * RAM Note that this only covers disk requirements for the database files. As with any database system, additional space must be reserved for Backup Exports Executables We recommend reserving approximately another 2-3 times the RAM value for these purposes SAP AG. All rights reserved. 8

9 9 Additional Disk Sizing - Details Disk space is required to persistenly store data that is kept in memory. The space to be provided must be capable to hold: Space for at least one process image in case of software failure (1x) Space for one data export (1x) Shared volume (across multiple nodes) for Executables, other data visible for all nodes (up to 1x) The firsttwo components are essential to provide support. Note that any backup data must NOT be stored in this space, but should rather be moved to external storage media.

10 10 CPU Sizing Based on moderate side-by-side Scenario Sizing approach similar to user based CPU sizing of BW and BWA Maximize query throughput by multiuser scenarios with queries of different complexity out of delivered content, million records Assumptions: - three different query complexity classes - three different user profiles (click rate, query complexity) - same distribution of user classes and query complexities as in BW Normalization to query throughput per core resp. active user per core CPU: 300 SAPS / active user Note that the CPU sizing has to be adjusted so that the server load does not exceed 65% in average (i.e. to obtain the maximum number of users per server, the absolute server SAPS capacitiy has to be multiplied by.65).

11 CPU Sizing Complex Scenarios Influencing factors for additional CPU requirements in more complex query scenarios: Data volume Resource requirements for queries increase linearly with amount of records that have to be processed. Query complexity Queries with computationally expensive operations (e.g. large number of calculated attributes / key-figures, large number of key-figures to be aggregated) or complex parallelized execution plans (e.g. a massive number of analytic views underneath a union node ) will take more resources than the sample content queries used in the basic CPU sizing. Consequently, the CPU sizing has to be adapted accordingly. What if query complexity of a customer scenario does not match or cannot be compared with the sample side-by-side scenario? Run throughput tests with customer specific data and queries to derive sizing Request expert sizing (chargeable service) through CSN component SV-BO-REQ SAP AG. All rights reserved. 11

12 12 Example Extract from sizing script output:... ZZYPLANRES.0625 ZZYPLANRESALL.5 ZZYPROT.0625 ZZYTRACE sum Table footprint of source database: MB = 182 GB Assumption: source DB compressed by factor 1.8 RAM = Source data footprint * 2 / 7 = 182 GB * 2 / 7 * 1.8 = 94 GB Disk persistence = 94 GB * 4 = 376 GB Disk log = 94 GB