support multiple values per point

[go-oleg]

All views in JuttleViz that have an understanding of a valueField allow only one of them per point.

When working with data in juttle, it is pretty common to end up with points that have multiple values each.

For example,

emit -limit 100 -from :0:
| put value = count()
| reduce -every :10m: sum=sum(value), min=min(value), max=max(value)

┌────────────────────────────────────┬──────────┬──────────┬──────────┐
│ time                               │ max      │ min      │ sum      │
├────────────────────────────────────┼──────────┼──────────┼──────────┤
│ 1970-01-01T00:10:00.000Z           │ 100      │ 1        │ 5050     │
└────────────────────────────────────┴──────────┴──────────┴──────────┘

In this case each point ends up with three values. The current expected way of sending this data into a timechart is to first call split:

emit -limit 100 -from :0:
| put value = count()
| reduce sum=sum(value), min=min(value), max=max(value)
| split
// | view timechart

┌────────────────────────────────────┬──────────┬──────────┐
│ time                               │ name     │ value    │
├────────────────────────────────────┼──────────┼──────────┤
│ 1970-01-01T00:10:00.000Z           │ sum      │ 5050     │
├────────────────────────────────────┼──────────┼──────────┤
│ 1970-01-01T00:10:00.000Z           │ min      │ 1        │
├────────────────────────────────────┼──────────┼──────────┤
│ 1970-01-01T00:10:00.000Z           │ max      │ 100      │
└────────────────────────────────────┴──────────┴──────────┘

This breaks each point into one point containing one of the values in the value field and original field name in the name field. It now has one value per point just like timechart expects.

The downside of having to call split before sending the points to view timechart is you end up sending a lot more points/data from the juttle-engine to your browser.

The proposal is to add multi-valueField support to timechart and the rest of the applicable views.

Default Behavior

Right now, if no -valueField is specified, the views look for the first numeric field they can find in the first point, and use that. The new behavior here would be that if theres more than one numeric field, it'll do the equivalent of calling split internally, creating a separate point for each value, assigning the value into value and the original value's field name into name. If there already existed a field called name in the point, it would get clobbered, but I think thats somewhat of an edge case. If points already contain a field called name, then it prolly is the name of the metric/value and there is only one value in the point to begin with.

Customizing the Behavior

If by chance a points have more numeric fields than a user wants to plot, they can still explicitly specify -valueField 'sum' or multiple -valueFields ['sum', 'min']. It would be good to just standardize on -valueFields, but that would be a pretty major breaking change so to begin, we should introduce -valueFields alongside -valueField.

[go-oleg]

cc @demmer @dmehra @jadbox

[dmehra]

Let's specify expected behavior if the user does

reduce max(v), min(v), avg(v) by type | view timechart

Perhaps nothing sensible can possibly happen, but we should have definition for this case.
Otherwise +1 to the proposal

[go-oleg]

@dmehra, the generated series would be

name: max, type: type1
name: min, type: type1
name: avg, type: type1
name: max, type: type2
name: min, type: type2
name: avg, type: type2
...

(assuming its reduce -every)

[dmehra]

What's the name of an individual series in the resulting timechart? Is "name: max, type: type1" the name?

[go-oleg]

@dmehra, yes.

Another option would be something like

type: type1 (max)

or just

type1 (max)

But these are introducing new concepts.