# A Resilient Large-Scale Trajectory Index for Cloud-Based Moving Object Applications
## 5 Experimental Study
### Performance Evaluation
Figure 5: Average execution time for the SF dataset with low resource availability on (**a**) range query, (**b**) interval query, (**c**) lookup query, and (**d**) longest query. Figure 6: Average execution time for the SF dataset with low resource availability on (**a**) continuous range query with small selectivity, (**b**) continuous interval query with small selectivity, (**c**) continuous spatio-temporal query with small selectivity, (**d**) continuous range query with large selectivity, (**e**) continuous interval query with large selectivity, and (**f**) continuous spatio-temporal query with large selectivity. We excluded temporal and spatio-temporal queries in the UK + IE dataset since it does not include timestamps. Figures 7-9 show the averages of the running time in conditions of high resource availability (Memory = 12 BG and Thread = 6) and low resource availability (Memory = 6 BG and Thread = 2). Overall, RMOI shows better performance, especially on low resource availability. LSpark seems to slightly overtake DTR on most of the queries. In the case of a very low TOver dataset, the competition is challenging because most of the query types prefer spatial locality over object locality. As a result, RMOI predicts \(LP\) to be 5 and 6 (the highest value is 7) for the high resource case and the low resource case, respectively. There is not enough room for improvement as all the approaches generally depend on space-based partitioning. We also observe that, when reducing resource availability, RMOI relies more on spatial locality on a dataset with low TOver, such as the UK + IE and the GT datasets. On the other hand, it relies more on object locality when applied to a dataset with higher TOver, such as the SF  
The second testbed is a stress test designed to capture the situation of a long run and the impacts of different query types. It depends on reporting the results of 100-query cycle, which consists of random query types with random frequencies. Here, RMOI depends on DPModel and IFModel. Figures 10 and 11 show the cumulative running time of 6 query sets on the RioBuses dataset, where each color represents a query type. We identify continuous queries running on SS and LS as two query types, because of the huge difference in running time. The first and second query sets consist of 3 query types, as seen in Figures 10a,b and 11a,b. The third and the fourth sets have 7 query types (Figures 10c,d and 11c,d), and the last two sets contain all the query types. Each query type in every set has random frequency. Queries are drawn from query pools, which contain different spatial and temporal selectivities and k values similar to the first testbed. The cluster nodes have two settings as before. With high resource availability (memory = 12 BG and thread = 6), RMOI shows a significant speedup. It outperforms LSpark and DTR by factors of 2.7\(\times\) and 3.6\(\times\) on the average, respectively. In a low resource availability scenario (memory = 4 BG and thread = 2), RMOI outperforms LSpark and DTR again, by factors of 11.5\(\times\) and 2.5\(\times\) on the average, respectively, as seen in Figure 11. In both resource settings, aggregation queries and continuous range queries on large selectivity are the most dominant query types. We also ran the second testbed on the UK + IE dataset. With high resource availability, RMOI gains a speedup by a factor 1.6x on the average, as seen in Figure 12; while on average it outruns LSpark by a factor 2.1\(\times\) and DTR by a factor of 2.1\(\times\) on low resource availability, Figure 13. However, it did not do as well on the second query set. RMOI predicts _LP_ to be 2 on the second query set, while it predicts _LP_ to be 6 and 7 on the other sets. The overall performance of RMOI is outstanding, especially on a very sparse dataset. Similar to the previous results, LTQ and LS CRQ are the most expensive query types, especially with low resource availability. The first query set has 35% LTQ, and the third set has 22% LTQ and 23% LS CRQ.