Anja Bog

A Hybrid Row-Column OLTP Database Architecture for Operational Reporting

Operational reporting differs from informational reporting in that its scope is on day-to-day operations and thus requires data on the detail of individual transactions. It is often not desirable to maintain data on such detailed level in the data warehouse, due to both exploding size of the warehouse and the update frequency required for operational reports. Using an ODS as the source for operational reporting exhibits a similar information latency.

Benchmarks for Transaction and Analytical Processing Systems

As presented in Chap. 1, the goal of this thesis is to analyze and compare the behavior of databases in mixed workload scenarios as a basis to evaluate logical database design decisions. Benchmarks provide a method for this. A benchmark is “a standardized problem or test that serves as a basis for evaluation or comparison (as of computer system performance).” [141]

Evaluation of Mixing the Workload and Variation of the Database Schema

Three fundamental techniques for performance analysis are listed by Lilja [129], Chap. 1. These are simulation, analytical modeling, and measurements of existing systems. While the last provides the most precise results, it is the most difficult and time-consuming of the three techniques in addition to a limitation of the validity of the derived statements to only the measured system.

The CBTR Tool Chain

The tool chain to assess database systems according to mixed workloads is composed of three parts. Figure 6.1 provides an overview of these parts. The first comprises database specific scripts to create the database schema (tables and indexes) and to load the benchmark base data into the database system that is going to be tested. The second part covers the simulation of a specific workload configuration – a benchmark run.

Combined Transaction Processing and Reporting Benchmark

Only limited statements can be made concerning the ability of existing data management systems to handle a mixed OLTP and OLAP workload since they have so far been treated as separate domains and separate benchmarks were created. Existing benchmarks could be applied to a combined architecture for OLTP and OLAP by simply running the benchmarks in parallel. This would only lead to a partial picture of the actual performance of such a system measuring the effects of hardware resource contention as the benchmarks are running on their own distinguished sets of tables.

Enterprise Data Management for Transaction and Analytical Processing

Enterprise data management has to support all business processes of a company from storing and providing data during daily operations, for example, sales, purchasing, and payroll accounting, to analyzing data for strategic decision making. Daily operations are supported by transaction processing systems.

Database Schema Variants for Mixed OLTP and OLAP

As discussed in Sect. 2.2, a database design optimized for OLAP degrades the performance of OLTP queries and vice versa. If OLTP and OLAP workloads are to be consolidated onto one system, the question of how to design the database arises. Optimizations of the dedicated OLTP and OLAP systems that have evolved in the past might still be applicable to tune the performance of systems under mixed OLTP and OLAP workloads.