## 4 Performance Tests
### INSERT Statement  
The testing of the insertion operation was performed by defining the structure of the entities, respectively, of the documents in Elasticsearch so that the data can be processed by sending a JSON object to a Rest service. In order to test the data insertion operation, multiple tests were performed, starting from the insertion of 30,000 records to the insertion of 2,000,000 records. For the insertion process, we provide JSON objects based on REST requests. We decided to use _car_announcements_ because it represents a complex structure through which various queries can be tested, but also due to the fact that its representation in the relational database involves several tables that offer the possibility to analyze the application performance depending on the number of records. Initially, 30,000 documents will be inserted, after 60,000 car announcements followed by 100,000. To have the most accurate times, the insertion process will continue by adding 500,000 car announcements, followed by the insertion of 1,000,000 car announcements, and finally 2,000,000 car announcements will be inserted to distinguish performances. Figure 5: Disk memory usage. Due to the fact that MySQL Document Store does not have a Bulk API that works with large data sets, in order to be able to process the data in parallel, _ExecutorService_ will be used, which will execute multiple tasks, each containing 500 documents. To index multiple documents, Elasticsearch has the Bulk API that provides a number of operations exposed by rest services, being optimized to work with large data sets. This API eliminates the need to write additional code to process data, simplifying application logic and reducing development time. Additionally, using the _BulkProcessor_ class is enough to create an _IndexRequest_ object based on the indexed document, and the actual indexing process will be conducted by _BulkProcessor_. Thus, the insert statement has the syntax presented in Table 1:  
Based on the results obtained in the data insertion process, it can be seen that Elasticsearch is much faster than MySQL Document Store in both cases of using one (Figure 6) and three threads, respectively (Figure 7). This idea is very well highlighted by the insertion of 2,000,000 documents, where the time differences are very large. Another important aspect that influences processing times is the way of inserting data. As can be seen in the results obtained in both cases, the use of three threads improved the processing times, but for MySQL Document Store the processing times did not decrease as significantly as they did for Elasticsearch. This can be caused by the fact that the data is inserted in the MySQL Document Store through a task that runs at an interval of 6 s and executes several transactions to avoid a large amount of data in memory. \begin{table}
\begin{tabular}{|c|c|} \hline \begin{tabular}{c} _Collection cars = session.getSchema(schemaName).getCollection(CARS);_ \\ session.startTransaction(); \\ carAnnouncementDTOS.stream().forEach(carAnnouncementDTO-> cars. \\ addOrReplaceOne(carAnnouncementDTO.getCarAnnouncementNo(), gson.tolson(carAnnouncementDTO)));_ \\ session.commit(); \\ \end{tabular} \\ \hline \
\begin{tabular}{c} **Elasticsearch** \\ \end{tabular} &
\begin{tabular}{c} _IndexRequest indexRequest = new IndexRequest(indexName).id(String.valueOf_ \\ _(carAnnouncementDTO.getCarAnnouncementNo())).source(gson.tolson_ \\ _(carAnnouncementDTO), XCContentType.JSON);_ \\ _bulkProcessor.add(indexRequest);_ \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 1: INSERT statements. Figure 6: Insert statement using a single thread. Elasticsearch is also built on Apache Lucene, which is much faster and able to handle larger amounts of data than MySQL Document Store. Another advantage of Elasticsearch in the insertion process is that it has the Bulk API. It is very well optimized, being built to process large amounts of data.