System Settings

The following settings are limits placed on your Rockset organization which may be customized for your specific use case by contacting Rockset Customer Support.

*Refer to Concurrent Queries Limits section.

To change your Virtual Instance type, navigate to the Virtual Instances tab of the Rockset Console.

Peak Streaming Ingest Limit

This refers to the maximum rate at which you can add data into Rockset. It is measured as the number of uncompressed bytes of new data being added to your account per second.

The peak streaming ingest limit is dependent on your Virtual Instance type.

Dedicated Virtual Instances do not have any hard limits on streaming ingest rate; however, your streaming ingest rate will be constrained by the Virtual Instance type that you have provisioned. Larger Dedicated Virtual Instances will have directly proportional lower data latencies due to the additional compute resources working on ingest. For instance, upgrading from a 2XLarge to a 4XLarge Dedicated VI typically doubles your peak streaming ingest rate.

💡

The peak streaming ingest limit does not affect your bulk ingest limit during the initial bulk ingest mode which occurs immediately following collection creation.

For instance, if you are creating a collection from MongoDB, DynamoDB or S3 and that source already has a large dataset, Rockset will automatically employ a bulk loading mechanism to index the data that is pre-existing in that source. This bulk loading process occurs immediately following the creation of the collection, and is not limited to the peak streaming ingest limit that is explained above.

The bulk ingest rate is hundreds of gigabytes per hour. If you need a higher bulk ingest rate, please contact Rockset Customer Support.

After the bulk loading process is completed, Rockset streams new updates made to the source and applies those updates continuously. The peak streaming ingest rate limit described above now applies.

Query Execution Timeout

This refers to the limit on the execution time of any individual query running in your Virtual Instance.

On Dedicated Virtual Instances, Asynchronous Queries are available to queue up queries with custom-defined timeouts of up to 30 minutes.

Query Queue Timeout

This refers to the limit on the queue time of any individual query running in your Virtual Instance. Queries are queued when query requests are received while the concurrent query execution limit is reached. They are then executed in FIFO order once the currently running queries and all prior queued queries are done executing.

Query Memory Limit

This refers to the total amount of memory that a single query can use. This memory is used for storing transient data that is created by intermediate stages of your query execution.

On Shared Virtual Instances, each individual query has a memory limit of 100 MB which can be used during execution. On Dedicated Virtual Instances, the memory available for your queries are determined by the size of the Virtual Instance. In this case, the memory associated with your Virtual Instance is shared by all concurrent queries in your account (for example, larger Dedicated Instance sizes will have higher memory limits).

Concurrent Query Execution Limit

The Concurrent Query Execution Limit (CQEL) refers to the maximum number of queries that a single Virtual Instance will execute concurrently in your account. The default limits (listed below) aim to balance the timeout mechanism in Rockset with the ability to process many queries in parallel without requiring additional management on the client side. Most queries run in under a second, so for most users the QPS is much higher than the default limit. The CQEL limit can be configured per Virtual Instance in the Virtual Instances tab of the console or the Update Virtual Instance REST API endpoint in the settings field.

• Increasing the CQEL:
  • Allows more queries to be executed concurrently, enhancing throughput.
  • May increase query latency as more queries compete for the same VI resources.
  • May increase out-of-memory errors if multiple concurrent queries require significant memory.
  • May increase query timeouts, as time spent in the queue is considered in the timeout threshold (default timeout is 2min).
• Decreasing the CQEL:
  • Can lead to under-utilization of CPU resources, especially if the VI has capacity for handling more concurrent queries.

💡

Tuning CQEL

We recommend increasing the CQEL in small increments until you have found the lowest possible value while achieving high CPU utilization at peak load. If your queries are heavier on memory and/or failing with out-of-memory errors and query timeouts, consider decreasing the CQEL. If your queries are lighter on memory and the CPU utilization of the VI is consistently low, consider increasing the CQEL.

📘

Note on CQEL for Dedicated VIs

Concurrent Query Execution Limit (CQEL) is a function of resources on your VI. It can be unlimited in the context of having multiple VIs as you have more available resources. You can scale concurrent queries by achieving a higher QPS, which is possible through multiple VIs. For an example of how a QPS of 20K was achieved, check out this blog post.