# Fast Performance Modeling across Different Database Versions Using Partitioned Co-Kriging
## 1 Introduction  
Database systems are increasingly becoming more configurable [1; 2]. The large number of configuration parameters can directly influence the functional and non-functional properties of database systems [3; 4]. Performance (e.g., latency, throughput, and requests per second) is one of the most important non-functional properties as it directly affects user experience [5]. Appropriate configurations can improve the performance for database systems [2; 6]. For example, the throughput difference between the best and worst configurations for Cassandra can be as high as 102.5% for a given workload [7]. To distinguish the optimal configuration, users are interested in knowing the consequences of changing the configuration parameters that are available to them. However, the exponentially growing configuration space and complex interactions among configuration parameters make it difficult to understand the performance of the system [8; 9]. In recent years, learning-based approaches have become the mainstream to solve this problem. These methods often collect the performance measurements of only a limited set of configurations (called samples), then build a performance model with these samples, and use the model to predict the system performance of the unseen configurations [7; 10; 11; 12; 13; 14]. In this way, performance can be predicted before a variant of the database system is configured and deployed. Existing approaches usually focus on the performance modeling problem under a constant environment, including fixed hardware [11; 14], workload [9; 10], and database version [2; 7]. We will concentrate on performance modeling for a newer database version in this work. In practice, previous performance prediction models often lead to high prediction error once the database version changes [15]. A new performance predictionmodel may need to be learned from scratch to meet the prediction accuracy requirements. However, the demand for high quality samples in learning-based methods contradicts the need for rapid acquisition of a new performance prediction model. Specifically, researchers often need a large number of samples to build a good performance prediction model [16]. However, the collection of samples requires a lot of time and resources [6; 10], which makes the construction of the new performance model time-consuming and laborious. Fortunately, performance models typically exhibit similarities across different database versions [17]. We introduce the concept of transfer learning into performance modeling for database systems. Similar to humans that learn from previous experience and transfer the knowledge learned to accomplish new tasks easier [18], here, knowledge about performance behavior observed in an older database can be reused effectively to learn models for a newer database with a lower cost. The problem is to identify the transferable knowledge and make use of them to ease learning of performance models. In this paper, we propose a co-kriging-based performance prediction method to efficiently learn models by reusing information gained previously when database version changes. The challenge is to predict system performance with high accuracy while utilizing a small sample in target domain. As it takes time and effort to configure the database system and collect performance measurement data, it is desirable that the sample size is kept minimum. Co-kriging allows data on an auxiliary variable to be used to make up for an insufficient amount of data in undersampled case [19]. We regard the performance responses in older (source) and newer (target) database systems as the auxiliary variable and primary variable, respectively. The measurement data in source can facilitate building an accurate performance model in target by co-kriging with a small sample in target. Further, Partitioned Co-Kriging (PCK) is proposed to better satisfy the assumption of co-kriging method. The assumption of co-kriging method is that the performance response is stationary [20].