title: Why am I reading many tombstones in Cassandra table although my access pattern should avoid them
body: <p>I know this is not the best way to use Cassandra, but the type of my data requires reading all data from the last week. However when using Collection-types in CQL3, I ran into certain limitations which prevent me from doing normal date-range queries.</p>
  
  <p>So I have set up Cassandra (currently single node, probably more in the future) with the following table</p>
  
  <pre><code>CREATE TABLE cache (tag text, id int, tags map&lt;text,text&gt;, 
    PRIMARY KEY (tag, id) );
  ALTER TABLE cache WITH GC_GRACE_SECONDS = 0;
  </code></pre>
  
  <p>I am inserting with a TTL of one week to automatically remove the items from the Cache. </p>
  
  <p>I tried to follow the suggestions mentioned in <a href="http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets" rel="nofollow">this article</a> to avoid reading many tombstones by selecting by "minimum id", which I persist elsewhere to avoid reading old data:</p>
  
  <pre><code>SELECT * FROM cache WHERE tag = ? AND id &gt;= ?
  </code></pre>
  
  <p>The id is basically some sort of timestamp which is constantly increasing, i.e. I only insert higher values over time and constantly remove older ids from the table.</p>
  
  <p>But I still get warnings about thresholds being reached</p>
  
  <pre><code>WARN 08:59:06,286 Read 5001 live and 5702 tombstoned cells in cache (see tombstone_warn_threshold)
  </code></pre>
  
  <p>And if I do not run manual compaction/scrubbing regularly I get exceptions and queries fail.</p>
  
  <p>However based on my understanding from the articles and documentation, I should be avoiding most if not all tombstones here as I query on equality for the tag, which allows Cassandra to only look for those areas and I use a minimum id which allows Cassandra to start reading only after most of the tombstones, so why are there still tombstone warnings/exceptions reported?</p>