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?
