title: Using CF's as an extra key level? Is there a limit on tables/column famillies in Cassandra?
body: <p>As usual, I don't know if this is a good idea, so that's why I'm asking StackOverflow!</p>
  
  <p>I'm toying with the idea of using CF's as an extra layer of partitioning data. For example, (and using the sensor example which seems to be pretty common) a traditional schema would be something like:</p>
  
  <pre><code>CREATE TABLE data (
    area_id int,
    sensor varchar,
    date ascii,
    event_time timeuuid,
    some_property1 varchar,
    some_property2 varchar,
    some_property3 varchar
    PRIMARY KEY ((area_id, sensor, date), event_time)
  ) WITH CLUSTERING ORDER BY (event_time DESC);
  </code></pre>
  
  <p>This is a bit problematic if some_property1,2,3 etc are not known at design time and can be changed over the life the platform. One possibility is to just declare more properties as needed, but then I think it makes more sense to bring the sensors into their own CF as each will have different schemas. You could do this just by naming the CF something composite (managed outside Cassandra), e.g. {area_id}_{sensor_name}, and then alter the schema as needed when new properties are requested for insert.</p>
  
  <p>My question is 2 fold. a) Is this a reasonable idea? and b) Are there any limitations of Cassandra (such as a cap of number of CFs) that this might fall foul of?</p>
  
  <p>For reference this is a <a href="https://stackoverflow.com/questions/19818673/cassandra-time-sliced-data-model-for-unknown-data">possible design to a previous question</a>, but I think the question is valid to stand-alone.</p>