A query follows several steps before a result is returned. Each step affects performance. Understanding how these steps fit together helps identify where slowdowns occur and which optimizations to apply. Prerequisites: A basic understanding of measures, cube structure, and datastore loading is recommended before reading this section.Documentation Index
Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt
Use this file to discover all available pages before exploring further.
How are queries executed by Atoti
The primary query type in Atoti is the MDX query. When Atoti receives an MDX query, it parses the query and breaks it down into Get Aggregates Queries (GAQs). Each GAQ requests one or more measures at a given set of locations. For each GAQ, Atoti computes a query plan that defines how the requested measures will be retrieved or calculated.Value retrieval
The fastest method is to take the values from the aggregate cache. When this is not possible, the values are computed.Aggregate Cache
The fastest option is to retrieve the measure value directly from the Aggregate Cache. This least-recently-used (LRU) cache stores location-measure combinations that were already computed by a previous query, keyed by cube version. If the requested combination is present in the cache, Atoti returns the result immediately without any further computation.Measure Computation
If the value is not cached, Atoti computes the measure at the requested locations. Most measures are computed from other, simpler child measures. To do this, the Atoti engine builds a computation graph for the requested measure. The leaf nodes of this graph are the simplest possible measures, called primitive measures. These are defined as basic aggregations over the fact table. Primitive measures are resolved through one of the following:- Aggregate Providers — Aggregate Providers are materialized views that store pre-computed primitive measure values at a defined granularity. Unlike the Aggregate Cache, which holds recently used location-measure combinations on demand, Aggregate Providers are updated every time a data load is triggered. A location-measure combination can be resolved by an Aggregate Provider if the requested location is at the same granularity or at a coarser granularity than the provider. In the latter case, the query engine aggregates the relevant rows from the Aggregate Provider to produce the result, leveraging the provider’s partitioning to skip irrelevant partitions and parallelize computation.
- Database — Datastore — If no Aggregate Provider can resolve the combination, the engine falls back to the Datastore. The Datastore engine collects all fact records matching the requested location and aggregates them to produce the result. To locate the relevant records, the Datastore engine can use indexes when available; otherwise, it performs a full row scan. Like Aggregate Providers, the Datastore leverages store partitioning to skip irrelevant partitions and parallelize the operation. — Direct Query — When using an external database, the connector generates a SQL query to compute the aggregation directly from the external data source.
