search

elastic / elasticsearch

Free and Open Source, Distributed, RESTful Search Engine
https://www.elastic.co/products/elasticsearch
Other
1.24k stars 24.85k forks source link

Add `version_range` as a range field type #83995

Open ajosh0504 opened 2 years ago

ajosh0504 commented 2 years ago

Description

Range field types represent a continuous range of values between an upper or lower bound. There are several range field types supported by Elasticsearch as of today. Version numbers seem like a natural fit for range field types, given that versions are often expressed as <, >, <=, >= , and hence would be good to include in the list.

Versioning is an important component of production-level software engineering. I can speak for my team, which trains machine learning models every month and saves versioned model training metadata into Elasticsearch. Being able to aggregate the data by model versions would be extremely useful.

Another use-case for version ranges is in enrich processors, where users might want to enrich existing data with version-related information, for example, enriching documents with software vulnerability information based on the software version.

elasticmachine commented 2 years ago

Pinging @elastic/es-data-management (Team:Data Management)

elasticmachine commented 2 years ago

Pinging @elastic/es-search (Team:Search)

cbuescher commented 2 years ago

Just for the record, this was already planned as part of https://github.com/elastic/elasticsearch/issues/48878 but in the end the range field was split from the main version field work to simplify the PR. There was a WIP prototype PR for the range work that seemed doable at the time, but it would definitely need to be updated and polished.

ajosh0504 commented 2 years ago

Any plans for when this work will be picked back up?

ajosh0504 commented 2 years ago

That said, if the work for version_range field type in particular is going to be tracked in #48878 in the future, I can close this issue.

cbuescher commented 2 years ago

No current plans, lets keep this issue open because you also state a use-case where your team would need it.

geekpete commented 1 year ago

Mentioning that being able to match against a version range (similar to the ip range type that allows native matching against ip ranges) opens up a range of use cases wherever version data is being used that could leverage this native range type for multiple products across all Observability, Security and Enterprise Search solutions. Without the range type, doing certain kinds of range matches can be extremely tedious and those scenarios can be greatly simplified by just storing a range to match against natively. The original enhancement envisioned the version range type as a key feature to go along with the version type, it'd be a shame to half-implement the idea that has so much value. I do understand this all needs to fit within prioritization challenges.

elasticsearchmachine commented 4 months ago

Pinging @elastic/es-search-foundations (Team:Search Foundations)