Thanks for response.
Note: I'm not good in English (I'm not native and I'm learning); Please
forgive me if it words aren't easy to understand ;)
I didn't satisfied for some reasons:
- as you mentioned, it don't (logically) override the last value! and it
will cause lot of side effects (from affecting compaction strategy, to
storage capcaity and even a new component for gc old signals). I realy
don't need event sourcing here. I wan't a fast and effient cache for last
updated signals, not more, not less.
- I can achieve better result (in my assumtion) than what was in the
answer (of course base on my domain). for example I can have a
`last_day_signals` or `last_hour_signals` table plus a simple table (like
what I presented in my question). In this case I can use one table for very
hot sensors with less effects on compaction (because most of values would
update in memtable) and read query!
- I prefer to use a range query to get values with less costs (application
complexity and i/o effiency).
But the main question is this: "Can I ignore clustering-keys effects on
rows order?" that seems the response is false!
And one more question: `ALLOW FILTERING` is not neccessary for my query! I
can use `sensors` clustering order too. But my assumtion is that when I set
partition-key in my query (and maybe clustering-key too) I will avoid most
of `ALLOW FILTERING` costs! But it seems that I'm wrong! Am I? Why?
