11th IEEE International Symposium on Applied Computational Intelligence and Informatics • May 12-14, 2016 • Timişoara, Romania

Performance Issues of in-Memory Databases in

OLTP systems
Patrik Szpisják, Levente Rádai
Óbuda University, Alba Regia Technical Faculty, Székesfehérvár, Hungary
E-Mail: [email protected], [email protected]

Abstract— Nowadays, new in-memory-based Enterprise

Resource Planning solutions are available for the companies.
One of the main purposes of these solutions are the
availability of real-time analytics. In a previous paper [1], we
discussed, how Oracle In-Memory Database solutions can
support faster on-line analytical processing queries and
measured and discussed the limitations of the Oracle in-
memory extension related to the complexity of the query and
size of the tables, which showed a downturn in in-memory
performance gain as the number of tables to be joined raises.
[3] In present paper, the question is, how this in-memory
performance gain does look like in case of on-line transaction
processing functionality. During the examination, we try to
go forward into the direction of comparison this performance Figure 1. Oracle Dual format in-memory representation featuring new
issue at different type of in-memory database types. in-memory column store [4]

I. DISK-BASED DATABASES It had to be done in the OLTP system in order to access

the truly real-time data.
Initially, disk based databases were commonly and As of an early experiment, the cache size of some disk-
widely used by the companies. It was possible to store large based database was enlarged to the similar size of the
amount of data at a cheap price which satisfied the memory. With this technique, it was possible to store a
enterprises’ needs. As the technology advanced and market large amount of data in cache for higher cache hit rates
globalization begun, the existing market solutions role had which enabled faster data access. This helped much, but
been taken over by global solutions role which allowed still was not nearly as fast as pure memory because the
companies to build an international wide market network. index structure still had to be built for disk access.
Ever since, the amount of stored enterprise operational and Therefore, main memory based databases appeared [2].
analytical data hugely grown to big data. This meant bigger These databases store all the data in the physical memory.
costs as more hardware was needed for both storage and Since the access time of memory is much less than disk, the
processing. However, it was even harder to make analytical store is not block oriented and the memory is directly
operations and as the data access times started to rise, the accessed by the processor, the performance hugely
total cost of profitable data access rose. Also, it was a increased. However, as we previously discussed [3], it
manner of time to produce management reports. Therefore, caused some database problems like volatile and being
it was reasonable to create a separate system for these vulnerable to operating systems errors. Due to these
purposes. The concept of Business Intelligence appeared.
dangers, it was reasonable to implement one or more
II. DEVELOPMENT TREND OF OLTP AND OLAP backup databases to prevent data loss. [5]
As business requirements became more complex, the III. ORACLE DATABASE 12C IN-MEMORY EXTENSION
structure of OLTP (Online Transactional Processing) In our previous article [3], we discussed that Oracle’s In-
databases had to be designed for transactional processing memory solution is not a standalone database, it is more
[1]. Therefore, as it is mentioned before, financial and like a feature. Oracle Database 12c stores the data on disk
analytical planning increasingly moved out to separate
as a conventional database. Activating the In-memory
systems called OLAP (Online Analytical Processing). feature, it is possible to store tablespaces, tables and
These systems provided better flexibility as well as specified columns of tables and even table partitions in
analytical performance [5]. The introduction of data memory, as Figure 1 shows. We can decide which of these
warehouses provided these functions, but in a cost of
we want to populate in memory for faster access.
additional management of so-called ETL (Extract,
Transform, Load) processes. Based on the According to this use-case article [4], storing data in
implementations, these two type of systems are a lot memory lowers the cost of data access as well as
different, however OLTP system is a necessary prerequisite maintaining analytical indexes. Due to the fast data access
for build OLAP functionality. As the technology further by vector processing and low memory access time, it is
advanced, for some companies it was a necessity to make possible to drop most of the analytical indexes. Most of the
real-time changes and decisions. The need for real-time indexes are analytical ones which is maintained by the
analytics appeared. Due to the latency caused by ETL CPU. Therefore, by dropping these indexes the overall
processes which usually took place at nights, OLAP performance of the system increases.
systems were unable to serve this purpose.

978-1-5090-2380-6/16/$31.00 ©2016 IEEE – 479 –

P. Szpisják, L. Rádai • Performance Issues of in-Memory Databases in OLTP Systems

We can say that mostly OLAP systems can benefit from Therefore, new records can be easily placed after the
this feature without any application changes, but it is existing entries and it does not require a differential buffer
reasonable to test if the OLTP systems can have an and a merging process.
advantage too. Common features are the availability of the column-
Hereinafter, we will do a performance test where we oriented tables, which can make the OLAP queries much
measure OLTP transaction times with and without Oracle’s faster by storing the values of a column near to each other
In-memory feature. (Figure 1.), but disperse the values of a record alongside the
memory space allocated to the table. This can result the
IV. SAP HANA IN-MEMORY DATABASE performance drop at record processing, e.g. inserting new
The idea of SAP High-Performance Analytical Engine record, selecting an entire record or joining columns or
came from middle of years of 2000, when the multicore- entire tables. On the following chapters, we will make a
based parallel processing came into general cost-efficient performance benchmark on two in-memory databases and
use and the specific cost of operative memory dropped test this feature on each of them.
radically. The development directions of SAP aimed first to
support OLAP functionality and to build new generation V. CONSIDERATIONS AT OLTP PERFORMANCE
data warehouse system and created the so called BENCHMARK OF SAP IN-MEMORY DATABASES
SanssoucciDB. [5] Testing SAP In-memory and disk-based transaction
The concept of this in-memory database uses the column processing performance is not so easy, like testing this in
oriented storage of data tables, as well, to provide more Oracle 12C databases. The reason is, that as previously
performance, but this results a question: where should the mentioned, SAP HANA is not an in-memory option of a
new entries of a table be placed? For the new entries, a disk-based DBMS, it is a different type of database
differential buffer is introduced, which can receive all of management system. Basically, SAP was started as an
the modifications of the main store. By this solution, the enterprise application developer, and the solutions were
entries in the columns of main store can be let sorted, only built on top of standard, high-performance DBMS
the changing entries are invalidated. The modifications are developed by third-party software companies. The reason
merged into the main store daily, which can serve to save was, that the target companies of the SAP real-time,
the snapshots for recovery as persistent storage using solid standard enterprise software mostly operated an RDBMS
state disks, as well. [6] and managed an existing their database with enterprise
Other consideration of the concept is the light-weight data. To replace the entire system was unavailable option
compression methods, the different types of dictionary in marketing aspect. Additionally, SAP do not need to
encoding, which can compress the tablespace size usually develop own RDBMS, only support the RDBMS solutions
down to 10% depending on the information density. These of third-party developers. This resulted a strong
light-weight compression methods can work on-the-fly dependency from the RDMBS developers in case of
without any performance drop, and result additional supporting the SAP software, the database interface has to
performance gain because less bits should be flow through be developed and maintained for each supported RDBMS.
the processing architecture. [6] The database-level business logic coding by SQL scripts
was very hard to apply because of legal issues between
In comparison of the SAP HANA memory resident software developer companies, which resulted that the
database, Oracle in-memory extension assures the business logic is coded mainly in application layer. For
continuous, synchronized persistency by disk-based main these considerations, SAP started to develop its own
store. Furthermore, the extension works with some spare MAXDB RDBMS solution and acquired RDBMS
space after the entries of each column. developers. From 2006, as the specific costs of memory and
parallel processing reach the adequate level, it started to
develop HANA for OLAP, and later for OLTP. With own
database engines, the business logic could be placed onto
database level, so the data processing and presentation pre-
processing does not require the application layer or tier.
To compare the disk-based and in-memory OLTP
performance in SAP systems, we cannot use the same
DBMS. Therefore, we selected a common infrastructure for
both DBMS type. A reasonable environment is the SAP
HANA Cloud Platform, where both MAXDB and HANA
is available. This is primarily a Platform-as-a-Service
system, therefore, we have to create the test environment.
The data structure and the text processes can be created and
maintained in SAP HANA Studio, which is a customized
Eclipse development environment.
On the other hand, we have to consider to the layer of
business logic. In this environment, the business logic
execution can be placed on database level, therefore, we
have chosen to run the tests on database level in case of
both type of systems.
Figure 2. Conceptual overview of SanssoucciDB [5] Similar test results using similar or different methods and
systems are hard to find in the literature.

– 480 –
 11th IEEE International Symposium on Applied Computational Intelligence and Informatics • May 12-14, 2016 • Timişoara, Romania

Figure 5. Runtime comparison of entry recording at disk-based and at

in-memory extension operation

Figure 3. Runtime structure and on SAP HANA Cloud Platform [7]

(© 2014 SAP SE or an SAP affiliate company)
VI. ORACLE DATABASE IN-MEMORY OLTP
PERFORMANCE BENCHMARKING
During the test, we chose an OLTP system, which The outcome of the tests by above mentioned Query
generally speaking exposed to high workload. All the used Types can be seen on Figure 4 in case of using disk store.
columns of both the source tables and the target tables had The first and the second test’s runtime was nearly the
the type of Varchar2 with a general length of 30 characters. same. The result was similar, because the first case had
Joining tables and the use of filters narrowed down the more returned columns and more joined tables while the
results to one thousand per query, which allowed us to second one had a more complex filtering by the subquery.
measure transactional operations time on the target table as
well as on individual inserted rows. The third test was much faster because it applied an
aggregation and the join was made on only two tables. This
We used three separate test cases, where the structure of operation could be executed quite fast thanks to the
the target tables was nearly the same as the source tables complex index structure.
but with a few extra timestamp type columns to log the start
and finish time of the rows’ insertion. Preventing the Before the following test, we populated both the source
performance issues, each log starts in a separate session by and the target tables in memory. As the compression option,
Pragma AUTONOMOUS_TRANSACTION compiler we used the default one which is the “for query low” option.
directive in Oracle DBMS and by AUTONOMOUS Executing the same queries resulted the effect showed by
TRANSACTION block in HANA DBMS, which marks Figure 5.
each transaction for independent run. Besides the We can see, that the results in these tests varied on a
individual row’s log, we also created a separate log table greater spectrum. The first and the third query’s runtime
where we logged each test’s start and finish time to measure was nearly the same as before but the second one has
the full total elapsed time of each transaction. suffered a huge performance loss. It is caused by the
The developed test queries are: complexity of the query because of the subquery filtering.
Generally speaking, we can say that the complexity of a
 In Query Type1 test, we selected eight columns from query influences the overall performance.
a total of six tables. Besides the join conditions, we
also applied two simple filters. On the Figure 6, we can see the performance difference
of in-memory and no in-memory tests grouped by the
 In Query Type2 test, four columns had been selected queries. Surprisingly every test result showed that the
from three tables, applying a subquery as a filter. performance dropped when we turned on the in-memory
 In Query Type3 test returned five columns from feature. The first query had a performance loss of 20
which one was an aggregated column by percent while the third had as little as 3 percent loss. By the
summarizing. We did also use group by expression complexity of the query, the second query had a
here. performance drop as much as 372 percent.

Figure 4. No in-memory entry recording runtime Figure 6. Operation overtime rate at in-memory OLTP operation

– 481 –
P. Szpisják, L. Rádai • Performance Issues of in-Memory Databases in OLTP Systems

In OLAP systems, we measured a similar result, namely This examination shows how different type of in-
as the number of involved tables raises, the performance of memory databases can behave in case of different
in-memory extension is lowering in comparison of disk- transaction processing load. Moreover, it is very instructive
based operation. for educational area, and it can provide an additional insight
It is important to mention, that during the test, we did not into the behavior of databases of ERP system. Both of the
drop the complex analytical indexes. This could cause an different type of in-memory solutions is unique and could
overall performance loss on the in-memory queries. be reasonable option optimal production system, but we
have to consider to the special conditions and features of
VII. SAP HANA IN-MEMORY OLTP PERFORMANCE the certain company or business area and the operations
BENCHMARKING parameters have to be carefully optimized, which is mostly
a hard task because of the business process complexity.
Running the same three tests we can receive the results
on Figure 7. Here, the entry recording into the HANA in- ACKNOWLEDGMENT
memory database takes significantly shorter time, than the
disk-based MaxDB. The differences in certain tests show We would like to say thanks to the National Talent
stronger differences as the complexity raises, but the entry Program of Human Resource Ministry of Hungarian State
recording performance seems to be quite faster, using Government for supporting the presentation opportunity on
differential buffer. this conference.
REFERENCES
[1] H. Plattner, “A Common Database Approach for OLTP and OLAP
Using an In-memory Column Database”, in: Proceedings of the
2009 ACM SIGMOD International Conference on Management of
data, 2009, ACM New York, 2009,
[2] H. Garcia-Molina and K. Salem, “Main Memory Database Systems:
An Overview”, in: IEEE Transactions on Knowledge and Data
Engineering, Volume: 4 , Issue: 6, Page(s): 509 - 516 , ISSN : 1041-
4347, IEEE, 2009,
[3] P. Szpisják and L. Rádai, “A New Way in Business Intelligence”,
in: G. T. Orosz (ed), Proceedings of the 10th Jubilee International
Symposium on Applied Informatics and Related Areas (AIS2015),
Paper P16. 6 p. ISBN:978-615-5460-49-4, Óbuda University,
Székesfehérvár, Hungary, 2015,
[4] Oracle Database 12c In-memory, When to Use Oracle Database In-
Figure 7. Entry recording execution time comparison in case of memory, Identifying Use Cases for Application Acceleration,
MaxDB and HANA database Oracle White Paper, 2015 March, URL:
http://www.oracle.com/technetwork/database/in-
memory/overview/twp-dbim-usage-2441076.html,
We have to pin down that these tests are not available to
[5] H. Plattner and A. Zeier, “In-memory Data Management -
real performance comparison between the two type of in- Technology and Applications”, Springer-Verlag Berlin Heidelberg,
memory database management system, only to check, how Germany 2012,
the performance between the disk-based and in-memory [6] H. Plattner, “A Course in In-memory Data Management - The Inner
operations changes depending on load changes. Therefore, Mechanics of In-memory Databases”, September 7, 2015 -
the main target of these tests are to examine the behavior of November 2, 2015, Hasso Plattner Institute, Potsdam, Germany
the in-memory operation depending on work load in 2015, URL: https://open.hpi.de/courses/imdb2015,
comparison of disk-based operation. [7] R. Nogueira and M. Grasshoff: “Introduction to SAP HANA Cloud
Platform (Repeat)”, openSAP Open Online Course, February 4,
VIII. CONCLUSION 2015 - March 25, 2015, © 2015 SAP SE or an SAP affiliate
company, URL: https://open.sap.com/courses/hanacloud1-2,
As we mentioned before, the areas that benefit from In- [8] A Selmeci, T Orosz: "Usage of SOA and BPM changes the roles
memory are the data access for analytics and the analytical and the way of thinking in development". In: A. Szakál (ed.),
index maintenance. As this article discussed [5], the benefit Proceedings of the 10th IEEE Jubilee International Symposium on
on OLTP systems by this in-memory feature is limited and Intelligent Systems and Informatics (SISI2012), 2012. pp. 265-271.,
mainly can be achieved by dropping the analytical indexes. ISBN: 978-1-4673-4751-8, Subotica, Serbia,
During these tests, we did not drop these indexes which [9] A. Selmeci, I. Orosz, Gy. Györök, T. Orosz: "Key Performance
Indicators Used in ERP Performance Measurement Applications".
likely caused an overall performance loss. The full testing In: A. Szakál (ed.), Proceedings of the 10th IEEE Jubilee
without indexes would have been a large-scale test which International Symposium on Intelligent Systems and Informatics
we may discuss in a following article. (SISI2012), 2012. pp. 43-48., ISBN: 978-1-4673-4751-8, Subotica,
We also have to mention, that in some databases, storing Serbia,
the indexes can take up as much as 60 percent of the [10] Tamás Orosz, István Orosz: "Company level Big Data
Management". In: Anikó Szakál (ed.), Proceedings of the 9th IEEE
storage. Moreover, in-memory feature enables real-time International Symposium on Applied Computational Intelligence
analytics which will become more and more important in and Informatics (SACI2014), 2014. pp. 209-303., ISBN: 978-1-
the future. 4799-4694-5, Timisoara, Romania,
Although the results showed a slightly performance loss [11] Orosz Gábor Tamás: "Analysis of SAP Development Tools and
while using in-memory feature, it is still worth to consider Methods". In: A. Szakál (ed.), Proceedings of the 15th IEEE
implementing it, not only because it can greatly reduce International Conference on Intelligent Engineering Systems
(INES2011), 2011, pp. 439-443., ISBN: 978-1-4244-8955-8,
storage needs but also because the less index the CPU has Timisoara, Romania.
to maintain the faster the system could become.

– 482 –