title: Duplicate rows/columns for the same primary key in Cassandra
body: <p>I have a table/columnfamily in Cassandra 3.7 with sensordata.</p>
  
  <pre><code>CREATE TABLE test.sensor_data (
      house_id int,
      sensor_id int,
      time_bucket int,
      sensor_time timestamp,
      sensor_reading map&lt;int, float&gt;,
      PRIMARY KEY ((house_id, sensor_id, time_bucket), sensor_time)
  ) 
  </code></pre>
  
  <p>Now when I select from this table I find duplicates for the same primary key, something I thought was impossible.</p>
  
  <pre><code>cqlsh:test&gt; select * from sensor_data;
  
   house_id | sensor_id | time_bucket | sensor_time                     | sensor_reading
  ----------+-----------+-------------+---------------------------------+----------------
          1 |         2 |           3 | 2016-01-02 03:04:05.000000+0000 |       {1: 101}
          1 |         2 |           3 | 2016-01-02 03:04:05.000000+0000 |       {1: 101}
  </code></pre>
  
  <p>I think part of the problem is that this data has both been written "live" using java and Datastax java driver, and it has been loaded together with historic data from another source using sstableloader. </p>
  
  <p>Regardless, this shouldn't be possible. 
  I have no way of connecting with the legacy cassandra-cli to this cluster, perhaps that would have told me something that I can't see using cqlsh.</p>
  
  <p>So, the questions are:<br>
  * Is there anyway this could happen under known circumstances?<br>
  * Can I read more raw data using cqlsh? Specifically write time of these two rows. the writetime()-function can't operate on primary keys or collections, and that is all I have.</p>
  
  <p>Thanks.</p>
  
  <p>Update: </p>
  
  <p>This is what I've tried, from comments, answers and other sources<br>
  * selecting using blobAsBigInt gives the same big integer for all identical rows<br>
  * connecting using cassandra-cli, after enabling thrift, is possible but reading the table isn't. It's not supported after 3.x<br>
  * dumping out using sstabledump is ongoing but expected to take another week or two ;)</p>