Master Hologres Query Queues: Boost Concurrency, Isolation & Fault Tolerance

Basic Introduction of Query Queue

Query Queue (also called Query Queue) addresses operational challenges caused by unknown traffic spikes and large tasks that can overload resources. When sudden traffic peaks occur, the queue limits overall concurrency to protect existing queries and maintain instance stability.

Large tasks such as unexpected bulk imports, massive ad‑hoc queries, or scans that unintentionally cover many partitions can consume excessive resources. Query Queue provides a circuit‑break mechanism to detect and kill such tasks before they destabilize the system.

For isolating large tasks, Query Queue can be combined with Serverless Computing, automatically routing these queries to serverless resources for execution.

Basic Architecture

In an elastic compute group, multiple compute groups exist. When a query arrives, it matches rules and is routed to a specific queue (e.g., INSERT, UPDATE, DELETE go to Query Queue 1). Concurrency limits can be applied per queue, allowing differentiated control for different query types.

Queries in a queue can also be sent to Serverless Computing for execution, and large queries that trigger circuit‑break can be rerun in Serverless to improve overall success rates.

Main Capabilities of Query Queue

Concurrency Control : Flexible classifiers match queries and direct them to different queues, enabling diversified concurrency limits.

Queueing Ability : Each queue can have customized queue size values to meet complex business scenarios.

Query Circuit‑Break : Based on execution time, queues can define circuit‑break thresholds to prevent large queries from saturating the system.

Query Isolation : Queries that are circuit‑broken are automatically rerun via Serverless, achieving both isolation and higher success rates.

Usage Scenario Example

Consider an instance with read‑write separation: write tasks use init_warehouse compute group, read tasks use readonly_warehouse. Real‑time Flink writes have stable traffic and may not need a queue, while batch writes from MaxCompute can be assigned an insert_1 queue for automatic flow control. Large tables can be isolated to Serverless automatically.

For query workloads, high‑priority business A can use a select_1 queue with flow control and Serverless rerun for high success rates, while lower‑priority business B can use a second queue with flow control and circuit‑break that kills harmful large queries.

Concurrency Control & Queueing – Management

When creating a Query Queue, you must specify max_concurrency (maximum concurrent queries) and max_queue_size (maximum queue length). Optional queue_timeout_ms sets a timeout for queued queries (default -1 means no limit).

Classifier Management

After a queue is created, classifiers determine which queries are routed to which queue. Classifiers are evaluated by priority; the first matching classifier assigns the query to its queue. If no classifier matches, the query falls back to the default queue.

Multiple classifiers can be bound to a single queue, but a classifier belongs to only one queue. System table hologres.hg_classifiers lists all configured classifiers.

Classifier Matching Rules

Supported matching attributes include query type (INSERT, SELECT, UPDATE, DELETE), account, database name, engine, SQL fingerprint, storage mode, and application name.

Validating Classifier Rules

Use the EXPLAIN statement to verify which queue a query uses; the “Query Queue” line shows the matched queue and classifier. Queries that do not use a queue (e.g., Fixed Plan) will not display this information.

Important Notes

The system‑generated default_queue is created automatically for each instance or compute group and cannot have custom classifiers or rules; unmatched queries fall into this queue.

Queue mechanisms apply only to SELECT, INSERT, UPDATE, DELETE statements. Fixed Plan queries are not affected. Statements like COPY or CREATE TABLE AS generate underlying INSERT statements, which are subject to queue control.

Query Isolation & Circuit‑Break

Demo videos illustrate creating a queue, setting concurrency limits, configuring circuit‑break, and viewing query logs. (Video link omitted for brevity.)

Summary of Query Queue Use Cases

For write tasks, real‑time streams may skip the queue, while batch writes benefit from queue‑based flow control and Serverless isolation for large jobs. For read tasks, high‑priority queries use queues with Serverless rerun for reliability; lower‑priority queries use queues with circuit‑break that can kill harmful large queries.