## 4 Performance Tests
### UPDATE Operation  
A simple, single update made on an indexed field, in which we change the country name with the _id_\(x\) can be done; for each database structure, the update operations are presented in Table 2. \begin{table}
\begin{tabular}{l} \hline \hline \multicolumn{2}{c}{**RELATIONAL MYSQL: Single update operation**} \\ \hline @Query(value = ”update country set name = ’Romania’ where id =:countryId”, nativeQuery = true) \\ void updateByld @Param(“countryId”) long countryId); \\ _And from the service it is called in the form:_ \\ countryRepository.updateByld(2); \\ \hline \multicolumn{2}{c}{**DOCUMENT-BASED MYSQL: Single update operation**} \\ \hline Country collection.getOne(“2”).replace(“name”, new JsonString).setValue(“Romania”)); \\ \hline \multicolumn{2}{c}{**COUCHDB FIRST STRUCTURE: Single update operation**} \\ \hline Map\textless{String, String\textgreater{}} result = db.find(Map.class, “2”); \\ if (result!= null) { result.put(“name”, “Romania”); db.update(result); } \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Single update operations. Figure 4: Performance time (ms) for the insert operation. As shown in Figure 5, the relatively big time difference between the first and the second structure in CouchDB is because, in the case of the first one, we made the selection and updated through a predefined order; but in the second case, the update was made through a request that automatically takes longer. When using MySQL, in the back, the update first looks for that item and then changes it. If we had defined indexes on the table, automatically the time required for the update would have been much shorter because indexes improve the speed of operations in the database. For document-based MySQL, we searched for the document to be modified, and with the replace command, we modified the desired field. A more complex, multiple update operation, that will update one hundred elements, changing the currency of all the countries on the European continent and setting it as having the value \"test\", is presented in Table 3. \begin{table}
\begin{tabular}{l} \hline \hline _Send a request with:_ \\ requestBody:”(\(\backslash\)”selector\(\backslash\)”: \{\(\backslash\)”_id\(\backslash\)”: \(\backslash\)”2\(\backslash\)”\(\}\))” \\ _parse the response using the second structure of ResponseDTO:_ \\ List\textless{}Continent\textgreater{}updatedList=responseDTO.getDocs().stream().peek \\ (doc\textgreater{}\{ doc.setName(“Romania”); \}).collect(toList()); \\ UpdateDTO updateDTO = new UpdateDTO0; \\ updateDTO.setDocs(updatedList); \\ String asString = new ObjectMapper().writeValueAsString(updateDTO); \\ _Send a second request with requestBody: asString_ \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Cont. Figure 5: Performance time (ms) for the single update operation. It can be noticed that in the body of the request for CouchDB second structure we have to send each document with all the fields, even if we have modified only one field. When only the modified field is added, all documents will be saved in this form, namely, all other fields will disappear. In this form, documents can be entered into the database. As can be seen in Figure 6, the time difference between the first structure and the second one is represented by the way updating the elements takes place. In the case of the first structure, two requests have to be made to get all the countries, and then iterating through the list obtained and updating each element. First, one has to create a new modified statement for the elements that satisfy the search content and then update the desired field with the new value. However, MySQL performance is the best when a small number of elements are involved because in CouchDB both obtaining and saving the modified elements is made through requests, which automatically takes longer and depends on the response times to these requests.