Our counters API only supports setting the counter value. When you update a counter via the REST API with a value of 100 for example, then that means the sum or count is 100 for the timestamp specified. A counter data point represents the total count or sum for corresponding timestamp. This style works well for cases in which the client keeps track of the count or sum.
There are scenarios in which the client does not or cannot easily keep track of the count. For these scenarios it is easier for the client to able to increment (or decrement) the counter. Consider the following example. We want to track the total number of requests for a REST endpoint. For a single web server, it is easy to keep track of the total number of requests for that particular server. We want to track the total number of requests across all servers.
It should be assumed that a counter will always either be updated by setting the value or by incrementing it. Mixing both ways will make it confusing and difficult to reason about the values. I am not suggesting that we do something on the server side to enforce this. It should be handled on the client side. I just want to point it out.
We store counters in the data table. For counters that are updated by incrementing, we can use Cassandra's counter data type, which will require a separate table since counters cannot be mixed with non-counter columns outside of the primary key. One nice benefit of using the counter data type is reduced storage. We do not store a separate value for each update, just the modified counter. The potential downside to this is that we are not tracking the increments values. We also lose the ability to know the total count at some previous time prior to the latest known count.
If we want to track the increment values, then our best bet might be to store the incrementing counters in the data table and forgo using Cassandra's counter data type. Even if we elect to use Cassandra's counter, I think we still want to track the total count over time so that we can compute rates.