This document provides an overview of efficient transaction processing in SAP HANA. SAP HANA is an in-memory database that aims to provide both transactional and analytical query capabilities on the same data. It uses a layered architecture with data stored in L1, L2, and main stores that represent different levels of processing. Data is merged from L1 to L2 to main stores asynchronously in the background. This allows for efficient transaction processing and analytics by storing data in different optimized formats throughout this lifecycle.

1. EFFICIENT TRANSACTION
PROCESSING IN SAP HANA
Presented by Vijay Soppadandi
21363273

2. CONTENTS
• What is SAP HANA?
• Goal
• Agenda
• Framework
• Summary & discussion

3. WHAT IS SAP HANA?
• High-Performance Analytic Appliance
• In-memory computing

4. GOAL
• The overall goal of the SAP HANA database is to provide a generic but
powerful system for different query scenarios, both transactional and
analytical, on the same data representation within a highly scalable
execution environment

5. AGENDA
OLTP (Online Transaction Proccessing)
o large number of concurrent users and transactions
o high update load
o very selective point queries
o Row-stores
OLAP (Online Analytical Processing)
o aggregation queries over a huge volume of data
o compute statistical models from the data
o Column-stores

6. AGENDA
• Zoo of different systems with different capabilities for different application
scenarios
• However, workloads usually contain both
o transactional database needs statistical information to make on-the-fly
business decisions
o data-warehouses are required to capture transactions feeds for real-time
analytics

7. FRAMEWORK
• Layered Architecture of the SAP HANA
• Lifecycle Management of Database Records
• Types of Merging and optimization
• Summary & discussion

8. LAYERED ARCHITECTURE OF THE
SAP HANA
Reference 3

9. FRAMEWORK
• Layered Architecture of the SAP HANA
• Lifecycle Management of Database Records
• Types of Merging and optimization
• Summary & discussion

10. LIFECYCLE MANAGEMENT OF
DATABASE RECORDS
Reference 1

11. LIFECYCLE MANAGEMENT OF
DATABASE RECORDS
• It has three main stages
- L1-delta
-L2-delta
-Main
• SAP HANA theoretically escalate records through different stages of a
physical representation

12. L1-DELTA
• Accepts all incoming data requests
• No data compressions
• Stores them in write optimized manner
- Preserves in logical-row format
-Fast insert & deleat, field update and record projections
• Holds 10,000 to 100,000 rows per single-node

13. L2-DELTA
• The next stage of the Unified table structure
• Organized in column format
• Stores upto 10 millions of row
• It emplyoys dictionary encoding
- However, for performance reasons, the dictionary is unsorted requiring secondary index
structures to optimally support point query access patterns

14. MAIN STORE
• Represents core data
• Final data format
• Organized in column format
• Highest compression rate
-Positions in a sorted dictionary
-Stored in a bit-packet manner
-Dictionary is always comprised

15. UNIFIED TABLE ACCESS
• A common abstract interface to access different stores •
• Records are propagated asynchronously
– without interfering with running operations
• Two transformations (or merge steps)
– L1-deta to L2-delta
– L2-delta to main

16. L1-DETA TO L2-DELTA MERGE
• Rows format is converted into column format
- column-by-column inserted into the L2-delta
Steps for merging:
• Step 1 ( parallel)
- new entries are added (advance) to the dictionary
• Step 2 (parallel)
-using dictionary encoding technique new column values are
added
• Step 3
- added values are removed from the L1-delta

17. L2-DELTA TO MAIN MERGE
• New main structure created from L2-delta
• Resourse intensive
-Is carefully schedulled and highly optimized
• Current L2-delta is closed when its done
• Retries the merge on failure

18. PERSISTENCE MAPPING
Reference 1

19. CONT...
• Its fully supports ACID gurentees
• Uses REDO logs instead of UNDO mechanisms and saving point
• It has some complications in making merging process

20. FRAMWORK
• Layered Architecture of the SAP HANA
• Lifecycle Management of Database Records
• Types of Merging and optimization
• Summary & discussion

21. MERGE OPTIMIZATION
• Basic idea to provide transperent record propagation from write to read
optimization.
• The classic merge
• Re-sorting merge
• Partial merge

22. THE CLASSIC MERGE
• It has two phases
• In first phase generates the new sorted dictionary
• In secound phase, new main index generates on the new dictionary

23. THE CLASSIC MERGE
Reference 1

24. RE-SORTING MERGE
• Provides higher compression potential
• reorganizes the content of the full table to yield a data layout which
provides higher compression potential
• not easy because all records should have the same order in all columns
• uses a scheme discussed in another paper

25. PARTIAL MERGE
• It aims to reduce overall merge overhead
• Split the main into two independent main structures
- passive : Not part of the merge process
-Active : Takes part in the merge process with L2-delta

26. PARTIAL MERGE
Reference 1

27. CHARACTERISTICS OF RECORD
STAGES
Reference 1

28. REFERENCES
1.Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth
-Vishal Sikka SAP 3412 Hillview Ave Palo Alto, CA 94304, USA vishal.sikka@sap.com
-Franz Färber SAP Dietmar-Hopp-Allee 16 69190, Walldorf, Germany franz.faerber@sap.com
-Wolfgang Lehner SAP Dietmar-Hopp-Allee 16 69190, Walldorf, Germany wolfgang.lehner@sap.com
-Sang Kyun Cha SAP 63-7 Banpo 4-dong, Seochoku 137-804, Seoul, Korea sang.k.cha@sap.com
-Thomas Peh SAP Dietmar-Hopp-Allee 16 69190, Walldorf, Germany thomas.peh@sap.com
-Christof Bornhövd SAP 3412 Hillview Ave Palo Alto, CA 94304, USA christof.bornhoevd@sap.com
2.Efficient Transaction Processing in SAP HANA Database
Presented by Henggang Cui 15-799b Talk
3. The SAP HANA Database–An Architecture Overview
-Franz F¨arber Norman

29. END
ANY QUESTIONS ?