Laremere
commented
5 years ago I see a few general approaches to a stats API:
- Raw column extractor
- Bucketing
- Population division
Example data: ticket ID: rank, name, latency T1: 15, foo, 103ms T2: 5, bar, 81ms T3: 7, baz, 76ms
Raw Column Extractor
This is the most basic option, and is probably a good place to start. The other modes could be built on top of it. What this should do is for some given fields in properties, extract those values to be usable. Eg, requesting rank and latency would yield: [ (15, 100), (5, 75), (7, 70)]
That’s in “array of structs” format (see https://en.wikipedia.org/wiki/AOS_and_SOA) In struct of arrays format, it would be: ([15, 5, 7], [100, 75, 70])
Struct of arrays would be more efficient when transmitting (both in proto and json).
A rough idea for what the API could look like:
message StatsRequest {
// Limits which tickets are included in the stats query.
Pool pool = 1;
// Which arguments should be returned.
repeated string attributes = 2;
}
message StatsResponse {
map<string, StatsColumn> columns = 1;
}
message StatsColumn {
repeated float64 float_value = 1;
}This is what is currently doable via redis by asking for all of the values in a given index (though values across multiple indexes isn’t supported).
How this should work with other datatypes is less clear. Strings properties which have lots of unique values (eg, player name) are less likely to be useful, while those with repeated values (eg, gamemode) are more likely to be useful. As such, sending the same value many times is likely to be inefficient.
Perhaps:
message StatsColumn {
repeated float64 float_value = 1;
repeated bool bool_value = 2;
// The string value of the ith value is string_table[string_lookup[i]]
repeated int64 string_lookup = 3;
repeated int64 string_table = 4;
}Bucketing
Repeated values leads to the second possibility: requiring buckets, and providing counts of those buckets.
Eg, get rank (in buckets of 10) and latency (in buckets of 25) would return (10 - 20, 100 - 125): 1 (0 - 10, 75 - 100): 2
Getting the right buckets would be hard: Too many buckets, and you’re getting most buckets with only 1 player; Too few buckets and you don’t have enough info on how you want to split up your population.
Population division
So, given that, you could, for example, instead ask the system “What values should I use to divide my player population into buckets of 1000.”
This is a less complete idea, but also closer to what the end logic requires. It’s also unclear, at the API level, determine how a multi-dimensional set of users should be divided.
lihaif
syntxerror
A Director calling into Open Match may need statistics about the current player pool size for a specific profile etc., to determine what rate to make match generation calls at.
In general, no component in the online game services system should directly connect to redis. Any information that any component may fetch from redis, we need to implemement as a first class Stats service.
Please use this issue to add any information that this stats service may need to provide.