This document presents the OpenSearch Benchmark performance test results for PolarSearch version 1.0 across three standard workloads: HTTP logs, NYC taxis, and Geonames.
For detailed test steps, refer to the PolarSearch benchmark test method.
Write performance test results
The write tests use the append-no-conflicts-index-only procedure to bulk write the complete corpus to a cluster. These tests evaluate write throughput (docs/s) with a varying number of concurrent write clients (bulk_indexing_clients). Each test starts with an empty index.
HTTP logs
The dataset is based on real web server access logs from the 1998 FIFA World Cup and contains approximately 247 million log records.
Test scenario 1: 6 shards and 1 replica
Throughput (docs/s)
Client 1
Client 2
Client 4
Client 8 (default)
Client 16
Client 32
PolarSearch 1.0
127860
197938
324857
454070
466709
469483
Test scenario 2: 6 shards and 0 replicas
Throughput (docs/s)
Client 1
Client 2
Client 4
Client 8 (default)
Client 16
Client 32
PolarSearch 1.0
172384
288195
512037
741541
783537
785893
NYC taxis
The dataset is based on 2015 NYC taxi trip data and contains approximately 165 million records.
Test scenario 1: 6 shards and 1 replica
Throughput (docs/s)
Client 1
Client 2
Client 4
Client 8 (default)
Client 16
Client 32
PolarSearch 1.0
77098
113670
183412
259955
271045
272685
Test scenario 2: 6 shards and 0 replicas
Throughput (docs/s)
Client 1
Client 2
Client 4
Client 8 (default)
Client 16
Client 32
PolarSearch 1.0
126167
187151
311023
451135
482505
488001
Search performance
The search test runs after write operations are complete, with replica=1 and target_throughput=0 (full-speed stress testing mode), to evaluate the maximum search throughput (ops/s) under full CPU load.
HTTP logs
term: Exact term match
An exact term match is performed on logs-* with a fixed hit count of 10,000 entries, returning the default 10 entries. This test evaluates the search efficiency of the PolarSearch 1.0 inverted index, the overhead of cross-shard fan-out and merge operations, and the processing capability of the network coordination layer.
term (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 148 | 312 | 591 | 829 | 1147 | 1475 |
asc_sort_timestamp: Sorting by doc values
A match_all query is executed on all documents, and the top 10 results are returned after being sorted in ascending order by timestamp. The @timestamp field is of the date type and is sorted by using doc values columnar storage. This operation evaluates the read efficiency of doc values, top-N heap sorting, and the merging capability of the coordinator node for PolarSearch 1.0.
asc_sort_timestamp (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 133 | 262 | 443 | 579 | 732 | 931 |
range: Time range scan
Perform a dynamic time window range query on the @timestamp field. Because 90% of queries in the log product include a time filter, this task evaluates the efficiency of date range scanning, complementing term queries to provide a comparison between point queries and range queries.
range (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 106 | 269 | 431 | 573 | 707 | 815 |
hourly_agg: Time-series aggregation
This test performs a date_histogram aggregation (bucketing by the hour) across all documents. It evaluates the aggregation throughput for date types, a core operation in log monitoring and statistical analysis scenarios.
hourly_agg (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 1.48 | 2.97 | 4.3 | 4.76 | 4.8 | 4.8 |
NYC taxis
match-all: Baseline scheduling
A match_all query is executed on the entire dataset of approximately 165 million records, returning only the default 10 records without sorting or aggregation. This process tests the efficiency of the basic path for engine request parsing, shard scheduling, and result serialization.
match-all (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 281 | 564 | 1115 | 2022 | 3167 | 4508 |
range: Numeric range scan
Performs a fixed numeric range filter on the total_amount field (fare amount, scaled_float type) to query for trips with a fare between 5 and 15 dollars, and returns 10 results by default. This operation tests the range scanning efficiency of a numeric field.
range (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 10.63 | 21.07 | 39 | 43 | 43 | 43 |
autohisto_agg: Adaptive time aggregation
Perform an auto_date_histogram aggregation (automatic bucketing, buckets=20) on data within a 20-day time window to examine the engine's adaptive aggregation capabilities. This complements range (range is for numerical range queries, while auto_date_histogram is for time range aggregations).
autohisto_agg (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 17.55 | 37.64 | 64.55 | 73.38 | 74 | 75.84 |
Geonames
The Geonames dataset is based on global points of interest (POI) data, containing approximately 11.4 million records with fields such as place names, country codes, population, and geographic coordinates. It is primarily used to evaluate performance across various query types. Because the Geonames dataset is much smaller than the HTTP logs and NYC taxis datasets, its write times are short. Consequently, the write performance differences for PolarSearch 1.0 are not significant enough for a meaningful comparison. Therefore, the Geonames tests focus on search scenarios, covering exact queries, full-text search, aggregations, geospatial queries, and script scoring to evaluate the product's query processing capabilities.
term: Exact term match
term (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 434 | 866 | 1615 | 2887 | 4433 | 5755 |
phrase: Full-text phrase match
This test evaluates phrase match performance in full-text search. A phrase match requires verifying term position information in the inverted index and is therefore more computationally complex than a standard term query.
phrase (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 408 | 782 | 1341 | 2523 | 3737 | 4925 |
country_agg_uncached: Terms aggregation with nesting
This test performs a terms aggregation (bucketing by country code) with a nested sum aggregation across all documents. The aggregation cache is disabled to reflect the true computational overhead. This test evaluates the engine's CPU utilization efficiency under heavy aggregation loads, making it representative of compute-intensive aggregation scenarios.
country_agg_uncached (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 12 | 24.62 | 45 | 50.55 | 51 | 51 |
decay_geo_gauss_function_score: Geospatial distance decay scoring
A scoring query with a geo-distance decay function (Gaussian decay) is run on the geo_point field to evaluate the query efficiency of the geospatial index and the score calculation capability.
decay_geo_gauss (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 5 | 9.73 | 17 | 18.62 | 19 | 19 |
painless_static: Painless script scoring
This test uses a Painless script to compute a custom score for each document. The script is pre-compiled and executed statically (static binding). This test evaluates the computational throughput of the script engine, including JIT compilation. It is representative of highly customized script scoring scenarios.
painless_static (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 5.52 | 10.85 | 19 | 20.89 | 21 | 21 |
desc_sort_population: Numeric sorting by doc values
Sort all documents by the population field (integer type) in descending order and return the top 10 results. The sorting is performed by using doc values columnar storage. This operation tests the efficiency of reading numeric fields from columnar storage and the performance of top-N sorting.
desc_sort_population (ops/s) | Client 1 | Client 2 | Client 4 | Client 8 | Client 16 | Client 32 |
PolarSearch 1.0 | 250 | 464 | 864 | 1451 | 1960 | 2469 |