nyc_taxis: make the fixed-interval histogram 60 days wide, on the epoch grid - #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:

"gap": "+30DAY",
"start": "2015年01月01日T00: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月06日T00: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月06日T00:00:00 2996 | 2014年11月06日 00:00:00 2996
 2015年01月05日T00:00:00 52666 | 2015年01月05日 00:00:00 52666
 2015年03月06日T00:00:00 54062 | 2015年03月06日 00:00:00 54062
 2015年05月05日T00:00:00 51300 | 2015年05月05日 00:00:00 51300
 2015年07月04日T00:00:00 45290 | 2015年07月04日 00:00:00 45290
 2015年09月02日T00:00:00 47561 | 2015年09月02日 00:00:00 47561
 2015年11月01日T00:00:00 46009 | 2015年11月01日 00:00:00 46009
 2015年12月31日T00: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.