Sizing a Virtual Instance for Queries

Rockset supports a wide range of access patterns and is commonly used as a cloud-native alternative to Elasticsearch. This page provides general guidance on sizing to help you plan for the following types of queries: search and analytics. We advise testing Rockset on your own data and queries as these are simple examples and may not capture the specifics of individual workloads.

Rockset separates storage from compute for elasticity. Distributed compute clusters are referred to as Virtual Instances and they are offered in a range of t-shirt sizes. Compute scales linearly as you increase the t-shirt size, with the amount of compute doubling from a small virtual instance to a medium virtual instance and so on.

You can expect QPS to grow linearly as you scale out Rockset. We recommend sizing your Virtual Instance for queries based on the latency that you are looking to achieve for your workload. Then, you can scale out the Virtual Instance to support higher QPS applications. There is no data replication needed.

Rockset offers two Virtual Instance classes: General Purpose and Memory Optimized. The General Purpose class provides a ratio of memory and compute suitable for many workloads. The Memory Optimized class has double the memory to compute than the General Purpose class. The size of the working set, or the set of data required to be in memory, will determine the optimal class for your workload.

With that background, let’s jump into the performance seen on search and analytics queries in Rockset.

Search

Rockset uses elements of a search index in its Converged Index to execute point lookup queries. A search index is like an index in the back of a book, you can quickly use the index to find the relevant pages (i.e.: data) for retrieval. The more selective the query, even over large-scale data, the faster it will return.

For this example, we ran a simple search query over a NYC Rideshare Trip Records dataset with 619 million documents and 583 GiB of data. The NYC Rideshare Trip Records is publicly available in the Rockset console. This is the query that we used:

SELECT
    dispatching_base_num,
    trip_time base_passenger_fare,
    tips
FROM
   nyc_taxi
WHERE
    rideshare_service = 'Uber'
    and dispatching_base_num = 'B02889'
    and pickup_date = date '2020-01-30'
    and tips <> 0

On this query, with a selectivity of 1,065 documents, you can expect a medium virtual instance to achieve 52 QPS. You can expect similar QPS for the General Purpose and the Memory Optimized classes. When the working set grows and there is high memory utilization on the General Purpose instance class, then switching to the Memory Optimized instance class is advised.

While this is a simple search query, Rockset excels at complex filters on large-scale data. The selectivity of the query is the primary contributor to QPS rather than the dataset size.

Analytics

Rockset uses elements of a columnar store in its Converged Index to aggregate data for analytical purposes. Columnar stores work by storing all values for a column contiguously on storage. That means a query can fetch the exact columns it needs and scan the values to aggregate the results. As the number of columns and rows scanned increases, you can expect latency to increase.

For this example, we are again using the NYC Rideshare Trip Records public dataset and running a simple analytics query that scans 4.2 million documents. We use data clustering by the pickup_date field to store those same field values together on storage for optimal analytics performance. This is the query that we used with the date of 2020-01-01:

SELECT
    rideshare_service,
    COUNT(*) total_rides,
    SUM(base_passenger_fare) total_fare,
    SUM(tips) total_tips
FROM
    Demo_Ridesharing.nyc_taxi
WHERE
    pickup_date <= current_date()
    and pickup_date >current_date() - interval 7 day
GROUP BY
    rideshare_service
ORDER BY
    total_rides DESC

For this query, you can expect a Medium Virtual Instance to achieve 28 QPS. You can expect similar QPS for the General Purpose and the Memory Optimized classes.

Rockset excels at complex analytics, including SQL joins, over multiple fields of data. The amount of data scanned determines the QPS for the workload.

Analytics with Large Working Set

To demonstrate when to use the General Purpose VI class versus the Memory Optimized VI class, we used a parameterized analytics query for a multi-tenant application. Parameters in Rockset enable the passing of field values at query time.

For this analysis, we shifted the dataset to the Chicago Taxi Cab Dataset as it contains taxi cab companies, or tenants, for the purposes of this application. The Chicago taxi dataset contains 151 distinct companies across 79M trips. The dataset size is 172 GiB.

Let’s use the following analytics query and parameterize the company field. See the parameterized query below:

SELECT
    company,
    COUNT(1) total_rides,
    SUM(fare) total_fare,
    SUM(tips) total_tips
FROM
    taxi.chi_taxi
WHERE
    company = :company
GROUP BY
    company

In a multi-tenant application, analytics are generated for different tenants. As more tenants query Rockset, the size of the working dataset increases. Depending on the size of the working dataset from tenants, it may make sense to switch from the General Purpose instance class to the Memory Optimized instance class.

We cycled through 151 tenants or companies to see the upper limit of the working dataset size for the general purpose and memory optimized instance classes while keeping QPS consistent. We were able to keep QPS at 6 and see how the latencies differed between the two instance classes:

Conclusion

While this guide provides a few simple query examples to help you think about sizing your Virtual Instance, we recommend trying this on your own data and queries. There are a number of additional factors and considerations that contribute to QPS, including the complexing of your query, your data model, how the data is transformed, number of collections joined and more.