Overview of the SAP HANA DB architecture:
A holistic view on enterprise data has become a core asset for every organization. Data is entered in batches or by-record via multiple channels, such as enterprise resource planning systems (e.g., SAP ERP), sensors used in
production environments, or web-based interfaces. For example in a sales process, orders are created, modified, and deleted. These orders are the basis for production planning and delivery. Hence, during the sales process records are looked up, inserted, and updated. This kind of data processing is typically referred to as Online Transactional Processing (OLTP). OLTP has been the strength of current disk-based and row-oriented database systems.
Upon closer inspection, a supposedly simple sales process exhibits a significant amount of complex analytical processing. For example, checking the availability of a product for delivery as part of a sales process requires aggregating expected sales, expected delivery, and completion of production lots, as well as comparing the resulting inventory with the customer demand. Similarly, a sales organization would be interested in profitability measures for planning based on most recent sales and cost information. This kind of workload is considered Online Analytical Processing (OLAP). Periodical tasks, such as quarter-end closing or customer segmentation, are executed by replicating data into a read-optimized data warehouse. For those types of reporting, column-stores have become more and more popular .
Additionally, analytical applications require procedural logic, which cannot be expressed with plain SQL, e.g., clustering the sales numbers of different products or classifying customer behavior. The natural approach is to transfer all the data needed from the database to the application and process it there. Therefore, optimized data structures and metadata cannot be used and intermediate results have to be transferred back to the database if they are needed in the following business process steps.
Ideally, a database shall be able to process all of the above-mentioned workloads and application-specific logic in a single system. This observation sparked the development of the SAP HANA database (SAP HANA DB). Historically, the in-memory columnar storage of the SAP HANA DB is based on the SAP TREX text engine and the SAP BI Accelerator (SAP BIA), which allows for fast processing of OLAP queries.
The high-performance in-memory row-store of the SAP HANA DB is derived from Par Time and specially designed to address OLTP workload. The persistence of the SAP HANA DB originated from the proven technology of SAP’s MaxDB database system providing logging, recovery, and durable storage. As of today, the SAP HANA DB is commercially available as part of the SAP HANA appliance. In the next section, we give a brief overview about the architectural components of the SAP HANA DB. Section 3 discusses the ability to execute analytical application-specific logic. In section 4 we outline how the SAP HANA DB accelerates traditional data warehouse workload. We discuss how we address challenges on transactional workload in enterprise resource planning systems in section 5 and summarize our work on the SAP
HANA DB in section 6.
Architecture Of SAP HANA :
