At the coordinator level SAI queries fall under Range metrics. I would either put them under the same at the lower level or in a new SAI metric.
It would be confusing to have the top level coordinator query metrics in Range and the lower level in Read. On Dec 1, 2023, at 12:50 PM, Caleb Rackliffe <calebrackli...@gmail.com> wrote:
So the plan would be to have local "Read" and "Range" remain unchanged in TableMetrics, but have a third "SAIRead" (?) just for SAI post-filtering read SinglePartitionReadCommands? I won't complain too much if that's what we settle on, but it just depends on how much this is a metric for ReadCommand subclasses operating at the node-local level versus something we think we should link conceptually to a user query. SAI queries will produce a SinglePartitionReadCommand per matching primary key, so that definitely won't work for the latter.
@Mike On a related note, we now have "PartitionReads" and "RowsFiltered" in TableQueryMetrics. Should the former just be removed, given a.) it actually is rows now not partitions and b.) "RowsFiltered" seems like it'll be almost the same thing now? (I guess if we ever try batching rows reads per partition, it would come in handy again...)
I prefer option 2. It is much easier to understand and roll up two metrics than to do subtractive dashboards.
SAI reads are already “range reads” for the client level metrics, not regular reads. So grouping them into the regular read metrics at the lower level seems confusing to me in that sense as well.
As an operator I want to know how my SAI reads and normal reads are performing latency wise separately.
-Jeremiah Option 1 would be my preference. Seems both useful to have a single metric for read load against the table and a way to break out SAI reads specifically. Hi,
We are looking at adding SAI post-filtering reads to the local table metrics and would like some feedback on the best approach.
We don't think that SAI reads are that special so they can be included in the table latencies, but how do we handle the global counts and the SAI counts? Do we need to maintain a separate count of SAI reads? We feel the answer to this is yes so how do we do the counting? There are two options (others welcome):
1. All reads go into the current global count and we have a separate count for SAI specific reads. So non-SAI reads = global count - SAI count 2. We leave the exclude the SAI reads from the current global count so total reads = global count + SAI count
Our preference is for option 1 above. Does anyone have any strong views / opinions on this?
|
