# EC-Kad: An Efficient Data Redundancy Scheme for Cloud Storage
## 4 Experiment Evaluation
### Experimental Result Evaluation  
Given the limited computational resources, to facilitate calculations and enable effective simulation, in the experiments, we divided all the original files equally into 10 data chunks. Under the condition of having the same number and size of original data chunks, we compared the performance of different network coding schemes. For the storage solution proposed in this paper, we chose the EC (10,3) strategy, which means that the number of original data chunks was 10, and the number of redundant data chunks was 3. The quantity of redundant data chunks here was determined based on empirical experience. Regarding the performance indicators for comparison, we mainly focused on the encoding latency, decoding latency, recovery success rate under different failure probabilities, and redundancy calculation overhead. The experimental results were obtained through an average of 30 iterations of calculation. Figure 4 shows a comparison of the encoding and decoding latencies of the compared encoding schemes, with the X axis representing the different sizes of various files used in the experiment and the Y axis representing the encoding latency. Figure 5 shows the decoding latencies of the different encoding schemes being compared. It can be seen from Figure 4 that the encoding latency of EC-Kad was shorter than those of the benchmarks and increased linearly with the file size. The encoding latency of the GMR-RC scheme was close to linear growth, and when processing small file encoding, there was not much of a difference between the EC-Kad and GMR-RC methods. As the file size increased, the difference widened. The NEC-CRC scheme had large time fluctuations due to the use of random coefficients in the encoding matrix. When encoding a 400 M file, the encoding latency of NEC-CRC was 486.25 s, and that of GMR-RC was 290.26 s. Then, as the file size gradually increased, the difference in the encoding latency between the GMR-RC and NEC-CRC methods decreased, and our solution (EC-Kad) still maintained its advantage. As can be seen from Figure 5, the decoding latencies of EC-Kad and GMR-RC were comparable, while that of NEC-CRC fluctuated significantly. Decoding involves retrieving the data chunks of a file from the corresponding cloud data center nodes and then merging and decoding them. Our proposed EC-Kad solution employs the Kademlia algorithm to search for data chunks when retrieving them from the cloud, which enhances the efficiency of data chunk retrieval. Moreover, due to the redundancy of the encoding, only the minimum number of data chunks is required to merge and decode the original file, thereby speeding up the decoding process to a certain extent. In GMR-RC, the decoding process has been optimized, and thus its method achieved a decoding latency comparable to our solution. NEC-CRC, on the other hand, incurs random computational overhead. When retrieving data chunks for decoding, it randomly receives a sufficient number of data chunks, which leads to significant fluctuations in the decoding latency. Figure 6 illustrates a comparison of the recovery success rates of the encoding schemes under different fault probabilities. In a Hadoop cluster, we could simulate node failures for virtual machines using a random fault injection method. We evaluated the recovery success rates of various comparative schemes under node failure probabilities of 5%, 10%, 15%, 20%, and 25%. As shown in Figure 6, EC-Kad and GMR-RC had comparable recovery success rates. However, the recovery success rate of NEC-CRC gradually decreased with increasing fault probability values. At a fault probability of 25%, the recovery success rate was only 69.7%. Our EC-Kad scheme demonstrated a higher level of fault tolerance. This is because we used a Cauchy matrix as the coefficient matrix for implementing erasure codes. The Cauchy matrix has good numerical stability, which ensures correctness in data recovery. Figure 4: Encoding latency. Figure 5: Decoding latency.