## 3 Overview and Theoretical Foundations
### The Notion of Quality-of-Service in Big Data Management  
In smart city application scenarios that require intermixing inter-domain heterogeneous georeferenced data, it is essential that data management systems (DMSs) satisfy a set of QoS goals prespecified in SLAs. Typical performance metrics that are intrinsically incorporated with DMSs include, time-based QoS metrics such as end-end latency and throughput, in addition to quality metrics such as approximation accuracy in case of relying on Approximate Query Processing (AQP). Those quality attributes enforce constraints on functionalities provided by DMSs, thus prespecifying qualifications (a.k.a. annotations) on how system functionalities are performed. For example, constraining an aggregation-based geospatial query, Top-N, to be performed with a low-latency or high accuracy.  
It is therefore indispensable for the developers of DMSs to deal with QoS awareness as a first-class-citizen by design while designing those systems or adding extra service functionalities in such a way that enforce the system to provide its services in accordance with the QoS properties. Achieving this goal when designing DMSs to join multi-domain heterogeneous data is challenging as it requires trading off various conflicting factors. Specifically, not knowing the scale of size of input heterogeneous data or its structure a-priori is to blame in most cases.  
QoS metrics can be divided into two categories. Those are time-based and quality-based. The former focuses on time-related measurements such as end-end latency and throughput. In system service quality control, end-end latency can be loosely defined as the total time to process all records from the input data from the moment records become persistent in disk-resident storage until query running results are served to the user. The goal of latency QoS metric is always lowering it. Throughput, on the other hand, can be roughly defined as the count of records that are processed by the system service during a time interval (e.g., every second). The QoS goal for throughput is to obtain a high throughput value. The other branch of QoS metrics relies on the accuracy of results obtained after using a service of the system to run a query. Examples include estimation quality, where the service system needs to guarantee a degree of estimation quality if it relies on approximation to provide the service as opposed to deterministic solutions. For example, if a DMS employs sampling or load shedding to reduce the input data size as a resolution for data size exceeding system computation capacity. The goal of this metric is to obtain a higher estimation (i.e., approximation quality) [37].  
Time-based and quality-based QoS metrics are contradicting in service systems that DMSs normally seek to find a plausible balance among them. For example, trading-off a tiny loss in accuracy at the price of a significantly lower latency. It is worth mentioning, though, that DMSs are designed to either guarantee QoS by being proactively (or reactively) responsive through applying mathematically-principled cost models, while other DMSs are designed to provide a service as a \"best-effort\" guarantee, where they do not necessarily meet QoS goals, but otherwise work on maximum resource capacity to achieve QoS goals as close as possible to those desired.  
In scenarios that require integrating big multi-domain data, DMSs should incorporate QoS metrics as principal elements rooted in their codebases to relief the shoulders of front-end developers from having to reason about those logistics at the presentation layers. The aim is to build a system that can strike a plausible balance between time-based and quality-based QoS goals.