Guardrails are thresholds that guide data and system usage, performance optimization, and avoidance of errors or unexpected results in Adobe Experience Platform.
This document provides default usage limits for Query Service data to help you optimize system performance when querying data in relation to your licensing entitlements.
Before continuing with this document, you should have a good understanding of the key Query Service definitions and capabilities. They are described below:
Ad hoc queries: For executing
SELECT queries to explore, experiment, and validate data where the results of the queries are not stored on the data lake.
Batch queries: For executing
INSERT TABLE AS SELECT and
CREATE TABLE AS SELECT queries to clean, shape, manipulate, and enrich data. The results of these queries are stored on the data lake. The metric for measuring the consumption of this functionality is computational hours.
Query Service users: Query Service users provided within your current license for Customer Journey Analytics, Adobe Real-Time Customer Data Platform, and/or Adobe Journey Optimizer may also be used with Data Distiller. Query Service users are shared between features.
Ad hoc users: Ad hoc users are the ones executing ad hoc queries.
Batch users: Batch users are the ones executing batch Queries.
Reporting API: An API for making data fetch calls (internally or externally). Extended reporting data models are derived from the native reporting data models in Adobe Experience Platform such as the Real-Time CDP dashboards data model.
The illustration below summarizes how Query Service capabilities are currently packaged and licensed:
There are two types of default limits within this document:
Soft limit: You can go beyond a soft limit, however, soft limits provide a recommended guideline for system performance.
Hard limit: A hard limit provides an absolute maximum.
The default limits outlined in this document are constantly being improved. Please check back regularly for updates.
The tables below provide the recommended guardrail limits and descriptions for query execution when using a particular query pattern.
Ad hoc queries
|Maximum execution time||10 minutes||Hard||This defines the maximum output time for an ad-hoc SQL query. Exceeding the time limit to return a result throws the error code 53400.|
|Concurrent Query Service users||
||Hard||This defines how many users can create sessions concurrently for a particular organization. If the concurrency limit is exceeded, the user receives a
||Hard||This defines how many queries can be executed concurrently for a particular organization. If the concurrency limit is exceeded, the queries are queued.|
|Client connector and result output Limit||Client Connector
||Hard||The result of a query can be received through the following means:
|Results returned via||Client UI||N/A||This defines how the results are made available to the users.|
|Maximum execution time||24 hours||Hard||This defines the maximum execution time for a batch SQL query.
The processing time of a query is dependent on the volume of data to be processed and query complexity.
|Concurrent Query Service Users for Unscheduled Batch||
||Hard||For unscheduled batch queries (for example CTAS/ITAS queries in interactive mode), this defines how many users can create sessions concurrently for a particular organization. If the concurrency limit is exceeded, the user receives a
|Concurrent Query Service Users for scheduled Batch||No user limitation||N/A||Scheduled batch queries are asynchronous jobs so there is no user limitation.|
|Computational hours for batch data processing||As specified in the Customer’s Adobe Experience Platform Intelligence Query Custom SKU Sales order||Soft||This defines the scoped amount of computational time per year a customer is allowed for executing batch queries to scan, process, and write data back into the data lake.|
|Query concurrency||Supported||N/A||Scheduled batch queries are asynchronous jobs, therefore concurrent queries are supported.|
|Client connector and result output limit||Client Connector
||Hard||The result of a query can be made available using the following methods:
|Results returned via||Dataset||N/A||This defines how the results are made available to the users.|
The table below provides the recommended guardrail limits and description for the query accelerated store.
|Query concurrency||4||Hard||To ensure that queries on aggregated data via the reporting API (including queries that enhance data models such as the Real-Time CDP data models) have the resources to execute efficiently, the reporting API tracks resource utilization by assigning concurrency slots to each query. The system puts queries into a queue and waits until concurrency slots become available or they can be served from the cache. A maximum of four concurrent query slots are available at any given time.
If you access the reporting API through a BI tool and need more concurrency, a BI server is required.
After reading this document you should have a better understanding of the default limits for query execution with the available query patterns.
See the following documentation for more information on Query Service: