The graph in Fig.12 shows the duration plotted 。‘。 be preferable for in the workload.We contend that this trade -off is acceptable Regarding the sec wnside.if the -balancing a Even if the ofter roller needs to rve a steady post-reconfguration state befor load-balancing [38] 7.4 Data Shuffling 7.6 Sensitivity Analysis n this experiment.we e how well the methods are able astly.we evalt e ho nents.d the the Ycs plan used in Section7 begin with plan then cause ch ,10%0t sulng the ples w he that ion tak an unacceptably long This able to g y al not im and thro ades slightly )of uptim etting A of t n asynch and( n S The DBMS'othpsbeter th the pr are the tw ll to th the best 10%e e of throughput v onfigu the sa 7.5 Reconfiguration Duration vs.Degradation not sho 00 ms herent trade-off in live r ortize the imp act of data choose to tune oned parame the e in moving db ff. d the RELATED WORK how quickly Squall oletes the re ing asyne an copy,halts all execution on the source node and performs a tupleor 50 100 150 200 250 300 350 Time to Reconfigure (seconds) 20 30 40 50 60 70 80 TPS % Drop Figure 12: Duration vs. Degradation – Measuring the mean throughput percentage decrease while in reconfiguration compared to out of reconfigu￾ration for a YCSB workload contracting the number of nodes. The decrease in reconfiguration time is controlled by limiting the number of sub-plans and delay between asynchronous requests. 0 50 100 150 200 250 300 350 400 0 1000 2000 3000 4000 TPS 16KB 0 50 100 150 200 250 300 350 400 0 1000 2000 3000 4000 TPS 2MB 0 50 100 150 200 250 300 350 400 Elapsed Time (seconds) 0 1000 2000 3000 4000 TPS 10MB 0 50 100 150 200 250 300 350 400 0 1000 2000 3000 4000 TPS 512KB 0 50 100 150 200 250 300 350 400 0 1000 2000 3000 4000 TPS 5MB 0 50 100 150 200 250 300 350 400 Elapsed Time (seconds) 0 1000 2000 3000 4000 TPS 20MB Figure 13: Chunk Size Analysis – The impact of chunk sizes on time to complete reconfiguration and throughput for YCSB workload. 7.4 Data Shuffling In this experiment, we evaluate how well the methods are able to shuffle data between pairs of partitions. This is to simulate mod￾erate data reconfiguration without creating migration dependencies on a single partition. We again use a YCSB database with 10 mil￾lion tuples evenly split on 16 partitions and execute a workload that accesses tuples with a uniform distribution. The reconfigura￾tion plan then causes eight pairs of partitions to exchange 10% of their tuples with each other (i.e., 62,500 tuples per partition). The throughput and latency measurements in Fig. 11 show that Stop-and-Copy is able to quickly migrate data in only a few sec￾onds. This downtime may still be unacceptable for highly available applications: if a system needs “five nines” (99.999%) of uptime, each week the system can only afford 6 seconds of downtime. As in Section 7.3, Pure Reactive never completes because of transac￾tions’ uniform access patterns and the overhead of small data pulls. The DBMS’s performance with Zephyr+ is better than the previ￾ous trials, largely due to the lack of multiple partitions pulling data from a single partition. Moving data from partition to another is the ideal case for Zephyr [19]. But again we see that despite re￾quiring longer to complete, Squall only causes a ∼10% decrease in throughput. We explore this issue further in the next experiment. 7.5 Reconfiguration Duration vs. Degradation The results from the experiments thus far show that there is an in￾herent trade-off in live reconfiguration between reconfiguration du￾ration and performance degradation. One of Squall’s goals is that it seeks to efficiently amortize the impact of data migration by using a combination of on-demand data pulls and periodic asynchronous data pulls. We have tuned Squall to minimize performance impact for a variety of workloads through the aforementioned parameters. But if an administrator wants a shorter reconfiguration time, then they can tune Squall to be more aggressive in moving data at the cost of a greater disruption in the DBMS’s performance. To better understand this trade-off, we used the same reconfiguration sce￾nario with the YCSB workload from Section 7.3. We then vary how quickly Squall completes the reconfiguration by decreasing the number of sub-plans it generates and the amount of time the system waits between issuing asynchronous pull requests. The graph in Fig. 12 shows the reconfiguration duration plotted against the DBMS’s throughput degradation relative to its through￾put before the reconfiguration starts. As expected, the faster re￾configurations cause a greater drop in performance. This indicates that a longer reconfiguration time may be preferable for applica￾tions concerned with high availability. One could argue, however, that there are two downsides to an extended reconfiguration: (1) snapshots may not be taken while reconfiguration is in progress, so recovery could take longer in case of failure, and (2) new recon- figurations may not be started while an existing reconfiguration is in progress, so the system may take longer to respond to changes in the workload. We contend that this trade-off is acceptable given the performance improvement during reconfiguration, and further￾more, we do not consider either of these downsides to be a major issue. In our experience, most H-Store users rely on replicas for fault tolerance, and almost never recover from snapshots. Even in the worst-case scenario where recovery from a snapshot is required, reconfiguration is not likely to significantly extend the timeline. Regarding the second potential downside, if the load-balancing al￾gorithm is effective, there should not be a need for frequent recon- figurations. Even if the system must reorganize the database often, we do not expect the duration to be an issue as the system con￾troller needs to observe a steady post-reconfiguration state before load-balancing [38]. 7.6 Sensitivity Analysis Lastly, we evaluate how Squall’s tuning parameters described in Sections 4 and 5 affect the DBMS’s performance and the length of the reconfiguration. For all of these experiments, we use the YCSB workload with the same reconfiguration plan used in Section 7.3 that contracts the cluster from four to three nodes. We begin with comparing the different maximum chunk sizes for pull requests. The results in Fig. 13 show that when the chunk size is 2 MB or less, reconfiguration takes an unacceptably long time. Above 10 MB, however, the total length of reconfiguration does not improve significantly and throughput degrades slightly. For this reason, we select 8 MB as our default chunk size. Next, we measure Squall’s performance with different settings for (1) the delay between asynchronous requests and (2) the num￾ber of sub-plans that it generates for a reconfiguration plan. These are the two settings that have the greatest affect on the DBMS’s performance during the reconfiguration and the time it takes for Squall to complete data migration. For the former, the results in Fig. 14a show that separating asynchronous pulls by 200 ms pro￾vides the best balance of throughput versus reconfiguration time. In the same way, the results in Fig. 14b show that creating five sub-plans is the optimal choice for this workload which we set as our minimum. Although we do not show experiments here due to space constraints, we found that separating consecutive sub-plans by 100 ms also achieves this nice balance. These experiments show that our chosen settings are appropri￾ate for the YCSB workload. We found that they also proved to be ideal for TPC-C. Depending on the application, administrators may choose to tune these parameters to further minimize recon- figuration time at the expense of performance during migration, or alternatively stretch out the reconfiguration time in order to max￾imize system performance. We defer the problem of automating this tuning process in Squall as future work. 8. RELATED WORK There are several existing protocols for migrating data between non-partitioned DBMSs [18]. The simplest approach, stop-and￾copy, halts all execution on the source node and performs a tuple- or