# Data Chunks Placement Optimization for Hybrid Storage Systems
## 4 Heuristics for Finding an Optimal Data Chunk Placement
### Testbed Setup and Metrics  
For setting up testbed and showcasing the previously presented analytic results, we emphasized existing research studies [26; 27] in the field. For encoding and decoding the data object, we use KODO-Python: Python binding for KODO Network Coding library [28] which was written in C++ language. For testing purposes, we took multiple random files with the size of 16 MB, and we split them into the chunks with the size of 512 KB. Moreover, for the current model, we used generation size 32 and the coefficient which was chosen from the finite field with a size of GF(28) [29]. The model was simulated in the environment, where the server has 50 GB of RAM and 12 CPU with 6 cores per Socket. In addition to this, we also created a simulated platform of a hybrid cloud multi-node system which consists of 8 storages (Google Nearline and S3 Standard-Infrequent Access), running in different regions, as well as 2 local storages, which was replicated receiver nodes. Receiver storage size was artificially limited maximum to 100 MB for testing purposes. For our experiments, we used cloud vendors to cool data pricing strategy. \"Cool Data\" has a lower storage cost compared with its predecessors. However, it has extra operation fees per request and retrieval charge for every GB of downloaded data. As was presented above, the early deletion fee is another outlying item for \"Cool Data\" storage tier. No matter that the data was stored during the period or removed before the last day of the BTU, the minimum storing span will always go up. As an example, if the 1-GB data was stored on day 1 and removed on day 9 in Google Cloud Storage, the charge will be:  
* $0.01 (0.01$ is approximate price for GCP storage)
* 1 GB
* 9/30 = $3 for storing the data from day 1 to 9;  
* 1 GB
* 21/30 = $7 for storing the data from day 9 to 21, 10$ in total.  
Both of the cloud vendors which were chosen for the testing purpose have a free tier for a certain amount of the REST API calls and data retrieval operation with multiple restrictions, such as after 1 GB and 1000 requests to \"S3 Standard-Infrequent Access\" storages, where Amazon charges 0.0001-0.1$ per 1000 requests, depending on the type of the request [30]. The price also varies based on the regions of the cloud storage. For our experiment, we use the same pricing scheme for per 10 requests (GET request only) and 1 MB of the data (due to a size small size of the data which we used for testing). Further measurement was done using official Amazon \"S3 Transfer Acceleration\" [29] and Google \"Google Cloud's Operations Suite\" [31] tools. For storage metrics, we used the \"CloudWatch\" [32] monitoring service. All metrics information which was used for analyzing the performance of the algorithm is summarized in Tables 1 and 2. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter Name** & **Value** \\ \hline Number of the Transmitter Storage & 8 \\ \hline Number of the Receiver Storage & 2 \\ \hline Number of the Chunks per file & 32 \\ \hline Storage Capacity Range (KB) & [4096,..., 102,400] \\ \hline Chunk size (KB) & 512 \\ \hline Locations of the receiver Storages & [Baku, Budapest] \\ \hline AWS Transmitter Storages Location & [Seoul, Cape Town, Frankfurt, Oregon] \\ \hline GCP Transmitter Storages Location & [Zurich, Mumbai, Osaka, Montreal] \\ \hline \hline \end{tabular}
\end{table} 
Table 1: General metric parameters.