serhiy-bzhezytskyy opened a new pull request, #21:
URL: https://github.com/apache/solr-orbit-workloads/pull/21
### Description
OpenSearch Benchmark's `nyc_taxis` — the workload this one was ported from —
defines `date_histogram_fixed_interval` with `"fixed_interval": "60d"`, and
OpenSearch anchors a fixed interval on the epoch rather than on the query. This
port asks Solr for `"+30DAY"`, starting at the query's own lower bound:
```json
"gap": "+30DAY",
"start": "2015-01-01T00:00:00Z",
```
So the operation reports buckets of half the width, on different edges.
Nothing fails and no document is lost — the sum over buckets is right — but the
shape of the histogram, which is what this operation exists to measure, is not
the shape OpenSearch Benchmark measures.
Two separate corrections are needed, and the first alone is not enough:
```
shipped start=2015-01-01 gap=+30DAY 13 buckets differs
width only start=2015-01-01 gap=+60DAY 7 buckets differs
this fix start=2014-11-06 gap=+60DAY 8 buckets identical to
OpenSearch
```
`2014-11-06T00:00:00Z` is the last 60-day boundary from `1970-01-01` that is
not after the corpus. Solr counts gaps from `start`, so that is where the
bucket edges have to begin for them to fall on the instants OpenSearch uses.
The buckets before the data are empty and `mincount: 1` drops them, so the
response still starts at the first bucket that holds documents — `2014-11-06`,
which is where the OpenSearch Benchmark run's first bucket also starts.
### Which reference
The `nyc_taxis` notes in `nyc_taxis/README.md` say "upstream" four times
without saying upstream of what, and here it matters: Elastic's `rally-tracks`
carries a workload of the same name whose values have diverged from OpenSearch
Benchmark's.
```
operation OSB rally-tracks
date_histogram_fixed_interval 60d 10d
date_histogram_calendar_interval month week
date_histogram_agg day day
```
Checked against `rally-tracks`, this change would look wrong. The port
follows OpenSearch Benchmark throughout — the shipped
`date_histogram_calendar_interval` is `+1MONTH`, which is OSB's `month` and not
rally's `week` — so this adds one sentence to the README naming that repository
as the reference, once for the whole table.
### Measured
Both shipped files, both engines, the same 300,649 documents: the operation
body from this repository is sent to Solr 10.0.0, the OpenSearch Benchmark
operation body to OpenSearch 3.8.0. Nothing is reconstructed by the harness —
it reads the two `operations/default.json` files and posts what it finds.
```
Solr OpenSearch
2014-11-06T00:00:00 2996 | 2014-11-06 00:00:00 2996
2015-01-05T00:00:00 52666 | 2015-01-05 00:00:00 52666
2015-03-06T00:00:00 54062 | 2015-03-06 00:00:00 54062
2015-05-05T00:00:00 51300 | 2015-05-05 00:00:00 51300
2015-07-04T00:00:00 45290 | 2015-07-04 00:00:00 45290
2015-09-02T00:00:00 47561 | 2015-09-02 00:00:00 47561
2015-11-01T00:00:00 46009 | 2015-11-01 00:00:00 46009
2015-12-31T00:00:00 756 | 2015-12-31 00:00:00 756
```
8 buckets against 8, identical edges and identical counts. Both bucket sums
are 300,640, which is Solr's `numFound`, so no matched document falls outside a
bucket on either side. OpenSearch reports `hits.total.value: 10000` here
because of its default `track_total_hits` cap — the comparison is between the
bucket sums, not that number.
The two sibling operations were checked the same way and need no change:
`date_histogram_calendar_interval` agrees on 12 buckets and
`date_histogram_facet` on 21, counts identical. A calendar month and a day are
already aligned by `start: 2015-01-01`, so only the fixed interval was off.
### What this does not show
The counts above are a 300,649-document sample, not the full corpus. The
bucket edges do not depend on how much of the corpus is loaded, and neither
does the agreement between the two engines, but the numbers inside the buckets
obviously do.
### Related
None to close. This is the `date_histogram_fixed_interval` difference I
recorded in #18 as wanting its own PR with its own measurement.
apache/solr-orbit#77 makes the converter emit `+60DAY` for a
`fixed_interval: 60d` instead of silently defaulting to `+1MONTH`, so the value
corrected here is one the converter can now produce rather than one only
present by hand. Neither PR needs the other, and the remaining difference
between the generated operation and this file — the facet window, still
`NOW/YEAR-10YEAR` — is being handled separately over there.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
