Illustrating the Need for In-Memory Technology

Objectives

After completing this lesson, you will be able to:

  • Illustrate in-memory technology
  • Describe SAP HANA as an application platform

SAP HANA In-Memory Technology

In-Memory Computing

Improved hardware economics and software innovations have made it possible for SAP to deliver on its vision of the real-time enterprise with in-memory business applications.

The Past: Disk-Centric, Singular Processing Platforms

Increased data volume causes major bottlenecks in data transfers. For example, input/output (I/O) transfer rates from storage disks to servers have not kept up with data volumes. Disk-centric computing creates significant bottlenecks in data management. As a result, users experience slowed down online transactions and batch processes.

To overcome performance bottlenecks in the past, IT systems have become very complex decentralized architectures. This decentralized design has compromised business user flexibility, and added significant costs to keep all the business data synchronized.

The Present: Low Latency Computing Driven by In-Memory Technology

Keeping all the business data in one central location, and available for all business users 24x7 is the solution, but it was not possible until the modern hardware became available. This modern hardware architecture enabled in-memory computing, and SAP HANA was built from the ground up to support this new architecture.

Row Store Versus Column Store

SAP HANA is an ACID-compliant, in-memory database. ACID is an acronym that means the database can support Atomicity, Consistency, Isolation, and Durability. This is a primary requirement of a database, which ensures that it is 100% reliable for mission-critical applications. The database must guarantee data accuracy and integrity even when there are lots of simultaneous updates across multiple tables.

The traditional database systems (without in-memory technology) focus on one workload: OLTP or OLAP. With SAP HANA, this has changed because it handles transactional and analytical workloads very well. The SAP HANA database stores the data in a columnar way, therefore organizing the data in DRAM in an optimal way for the CPU to access.

Queries from analytical applications that are sent to the database often require only a subset of the overall data in the table. Usually, only a limited number of columns are required. With the column store, only the required columns are searched, so you avoid unneeded search activity in the memory.

With column store, SAP HANA scans columns of data so quickly that additional indexes are usually not required. This helps to reduce complexity by avoiding the need to constantly create, drop, and rebuild indexes. Column store tables are optimal for parallel processing, as each core is able to work on a different column.

The column store is seen as optimal for analytical processing (OLAP), but with the inclusion of the delta store, the column store also provides optimal performance for transactional processing (OLTP). A delta store is added to every column store table and is write-optimized. In this way, a columnar table is fast for read and write operations.

Column- and Row-store Tables in SAP HANA

The SAP HANA database supports both column-based and row-based tables. However, the table storage is optimized for column tables. When creating a table, you need to decide whether the table should be column- or row-store, depending on the use case.

Use a column table when:

  • Performing aggregations on a small number of columns.
  • Performing searches based on the values in only a few columns.
  • The table has a large number of columns.
  • The table has a large number of rows and mostly columnar operations are performed.
  • Achieving a high column compression rate is required.

Tables that are stored in the column-store are read-optimized. These tables have better compression rates than tables stored in the row store. Furthermore, some features of the SAP HANA database, such as partitioning, are available only for column tables.

Column-based storage is used for large tables with bulk updates. However, in a compressed column table the update and insert performance is slower than on row tables. SAP has addressed this slower update and insert of columnar tables by introducing a delta store. Every table has a write-optimized uncompressed delta store. This makes columnar tables have fast read and write capabilities.

You can join row tables with column tables in the SAP HANA database. However, it is more efficient to join tables of the same storage type.

Use a row table when:

  • You want to process single records at once, or many selects and updates.
  • You want to access complete records.
  • Columns contain mainly distinct values.
  • You do not need aggregations or fast search.
  • The number of rows is small.

Row-store tables are mostly small tables that have frequent, single updates. Row-store tables will be completely loaded into memory at the start of the SAP HANA database. On row-store tables you will find indexes to improve the read performance. The indexes are recreated at every start of the SAP HANA database, so they are always optimal.

You can change an existing table from one storage type to the other (ALTER TABLE ALTER TYPE).

SAP HANA as an Application Platform

SAP HANA is different by design. It stores all data in-memory and in a compressed columnar format.

Because SAP HANA has this different design, it does not require sums, indexes, materialized views, or aggregates. This reduces the database footprint. Everything is calculated on demand and in the main memory. This process makes it possible for companies to run online transaction processing (OLTP) and analytical applications (OLAP) on the same SAP HANA database system at the same time. It allows for any type of real-time processing, specific queries, and analysis.

In addition, SAP has built solutions to all well-known problems of columnar databases, such as concurrency (SAP HANA uses MVCC), and row-level insert and update performance (SAP HANA uses various mechanisms, such as a delta store). SAP also added engines inside SAP HANA to provide the following functions:

SAP HANA supports the following open standards:

  • Representational State Transfer (REST)

  • JavaScript Object Notation (JSON)

  • OLE DB for OLAP (ODBO)

  • Multidimensional expressions (MDX)

  • Open Database Connectivity (ODBC)

  • Java Database Connectivity (JDBC)

SAP HANA Platform

The SAP HANA platform combines database, data processing, and application platform capabilities. It provides libraries for predictive planning, text, spatial, and business analytics to enable business to operate in real time.

SAP HANA is an in-memory database management system, but it also contains many additional features for specific use cases. Examples are spatial processing, search, text mining, and integrated libraries. Some of these features can be used when running traditional applications on SAP HANA. Others are used in entirely new in-memory applications.

  • Virtual online analytical processing (OLAP):

    Processing large amounts of data for analytical purposes, support of complex calculations, modeling, and data mining.

  • Data virtualization: Access data across organizational, application, and data storage boundaries to gain full business visibility.

  • Text analysis: Feature enabled with full-text index to discover and classify entities in documents, supporting many entity types, analysis, and languages.

  • Search: Support for search on single or multiple columns of almost any visible data type, and standard string search.

  • Geospatial: Analyze spatial data for your business, build geospatial applications, and geo-content and services.

  • Graph: Support for graph processing, allows you to execute typical graph operations on the data stored in an SAP HANA system.

  • Web: Web-based development workbench, without installing further tools.

These features enable new scenarios and use cases. Running traditional applications on SAP HANA already provides significant advantages compared to traditional disk-based DBMS. By adapting applications to the innovative data model and architecture of SAP HANA, the advantages are even more comprehensive and enable entirely new business scenarios.

Customers use SAP HANA in different scenarios. In addition to the optimization potential, the way in which SAP HANA is integrated into the system landscape also impacts aspects like system architecture, administration, operations, and security. Therefore, it is essential to include all stakeholders in the scenario discussion.

SAP HANA Extended Application Services, Advanced Model

SAP HANA extended application services, advanced model provides a comprehensive platform for the development and execution of native data-intensive applications.

SAP HANA functions as a comprehensive platform for the development and execution of native data-intensive applications that run efficiently in SAP HANA, taking advantage of its in-memory architecture and parallel execution capabilities. Structured accordingly, applications can gain from the increased performance provided by SAP HANA because of the integration with the data source.

SAP HANA extended application services, advanced model is a polyglot application platform that supports several programming languages and execution environments, for example, Java and Node.js. The JavaScript for SAP HANA extended application services, classic model is supported by a framework running in the Node.js runtime.

In simple terms, SAP HANA extended application services, advanced model is basically the Cloud Foundry open-source Platform-as-a-Service (PaaS) with a number of tweaks and extensions provided by SAP. These SAP enhancements include the following:

  • Integration with the SAP HANA database

  • OData support

  • Compatibility with SAP HANA extended application services, classic model (XSC)

  • Additional features designed to improve application security

SAP HANA extended application services, advanced model (XSA) also provides support for business applications that are composed of multiple micro-services. These are implemented as separate Cloud Foundry applications, which combined are also known as multi-target applications (MTA), which include multiple modules like an equivalent of Cloud Foundry applications.

SAP HANA Extended Application Services Engine

SAP HANA extended application services is the application server for native SAP HANA-based web applications. It is installed with the SAP HANA system and allows developers to write and run SAP HANA-based applications without the need to run an additional application server. SAP HANA extended application services is also used to run web-based tools that come with SAP HANA, for instance for administration, lifecycle management, and development.

Server on the Classic Model of SAP HANA Extended Application Services

The classic model of SAP HANA extended application services is the original implementation of SAP HANA extended application services. The server on the classic model of SAP HANA extended application services can run as a separate server process or embedded within the index server.

The SAP Web Dispatcher, which runs as a separate database service on the host of the system database, is used to route incoming HTTP requests from clients to the correct XS classic server based on virtual host names. This is part of network configuration. In addition to the system-internal Web Dispatcher, you can implement an external Web Dispatcher for load distribution. See the section on using the SAP Web Dispatcher for load balancing with tenant databases.

Note

SAP HANA XS Classic and the SAP HANA Repository have been deprecated for SAP HANA. See also SAP Note 2465027 – Deprecation of SAP HANA extended application services, classic model, and SAP HANA Repository. In addition, check SAP Note 2695472 – Statement on SAP HANA XS Classic and the SAP HANA Repository and SAP Cloud Platform, SAP HANA Service.

Runtime for the Advanced Model of SAP HANA Extended Application Services

The SAP HANA extended application services for development, modeling, and tooling will be changing. Going forward, they will be based on the SAP HANA extended application services, advanced model (XSA). The advanced model of SAP HANA extended application services represents an evolution of the application server architecture within SAP HANA. It builds on the strengths and expands the scope of the classic model of SAP HANA extended application services.

The runtime for the advanced model of SAP HANA extended application services consists of several processes for platform services and for executing applications. For more information about the individual services, see the SAP HANA Administration Guide.

The runtime for the advanced model of SAP HANA extended application services runs either on dedicated hosts or together with other SAP HANA components on the same host.

Note

SAP recommends that customers and partners who want to develop new applications use the advanced model of SAP HANA extended application services (XSA). If you want to migrate existing applications from the classic model of SAP HANA extended application services to run in the new advanced runtime environment, first check the features available with the installed version of SAP HANA extended application services, advanced model. If the features of the advanced model of SAP HANA extended application services match the requirements of the classic application that you want to migrate, then you can start the migration process. For more information, see the SAP HANA XS Advanced Migration Guide.

Additional Information Sources

Further SAP HANA documentation and information can be found in the following resources:

SAP HANA Database Administration Curriculum

The following courses are prerequisites to become C_DBADM_2404 certified in the area of SAP HANA database system administration:

Log in to track your progress & complete quizzes