Skip to content

Query scaling

For large volumes of queries or for complex, long-running queries, it may be necessary to increase the amount of resources servicing queries to maintain desired performance. There are different options available to tune, depending on the profile and scale of the queries. Adding more threads can be used to speed up individual queries. Adding more replicas can increase parallelism when there is a high number of concurrent requests. If the number of replicas becomes very high, scaling your routing layer should be considered. Adding replicas is also a good practice for increasing query resiliency by adding redundant processes.

Threads

Adding additional threads to a DAP allows for query filtering and aggregation to be performed in parallel within a single process. DAP process make use of additional threads when they are available.

DAPs are kdb+ processes which are configured to have secondary threads using the -s flag provided to the process.

In a kdb Insights Enterprise deployment, -s is added automatically based on your k8sPolicy. The number of threads will be automatically configured to match the requested number of CPU cores.

In the user interface, the CPU request value can be set in the query compute settings.

Query compute

When configuring a database using an assembly YAML file, the k8sPolicy resource requested CPU value will be used for the number of threads.

spec:
  # additional config ...
  elements:
    instances:
      da:
        mountList: [rdb, idb, hdb]
        k8sPolicy:
          resources:
            requests:
              cpu: 2

This value should be tuned to match the desired execution parallelism requirements of the query profile. See the performance best practices on threads for details.

Replicas

Data Access Processes are individual kdb+ processes, which, while fast in executing queries, only have a single main thread. To increase query throughput and the number of concurrent queries the system can manage, adding additional DAP replicas will give the gateway a greater number of targets with which to serve the queries in parallel. The gateway makes use of all replicas available when load-balancing query work by default.

In the kdb Insights Enterprise user interface, the number of replicas can be changed by increasing the number of Production Read Replicas.

Query settings

In a kdb Insights Enterprise assembly deployment, set the size of your instance to change the number of replicas.

spec:
  elements:
    dap:
      instances:
        da:
          mountList: [rdb, idb, hdb]
          size: 2 # Define 2 query replicas

This value should be tuned to match the desired parallelism requirements of the query profile. See the performance best practices on replicas for details.

Routing

As the number of DAP replicas increases, it will become necessary to increase the number of Resource Coordinators and Service Gateways that are servicing queries.

In a kdb Insights Enterprise deployment, the Service Gateway (SG) and Resource Coordinator (RC) intelligently route query requests across all replicas, providing automatic load balancing. SGs and RCs will also automatically discover newly-added replicas and balance the number of requests across the updated set.

Base install

The number of replicas for the RC and SG need to be configured as part of your kdb Insights Enterprise install.

To configure this value, set the resource-coordinator.replicaCount and sg-gateway.replicaCount in your install's values file.

service-gateway:
  resource-coordinator:
    replicaCount: 3
  sg-gateway:
    replicaCount: 3