[Cassandra Wiki] Update of "CassandraLimitations" by JonathanEllis

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "CassandraLimitations" page has been changed by JonathanEllis.
http://wiki.apache.org/cassandra/CassandraLimitations?action=diff&rev1=4&rev2=5

--------------------------------------------------

  == Artifacts of the current code base ==
  
   * Cassandra's compaction code currently deserializes an entire row (per columnfamily) at a time.  So all the data from a given columnfamily/key pair must fit in memory.  Fixing this is relatively easy since columns are stored in-order on disk so there is really no reason you have to deserialize row-at-a-time except that that is easier with the current encapsulation of functionality.
-  * Cassandra has two levels of indexes: key and column.  But in super columnfamilies there is a third level of subcolumns; these are not indexed, and any request for a subcolumn deserializes _all_ the subcolumns in that supercolumn.  So you want to avoid a data model that requires large numbers of subcolumns.  This can be fixed; the core classes involved are SuperColumn and SequenceFile.
+  * Cassandra has two levels of indexes: key and column.  But in super columnfamilies there is a third level of subcolumns; these are not indexed, and any request for a subcolumn deserializes _all_ the subcolumns in that supercolumn.  So you want to avoid a data model that requires large numbers of subcolumns.
   * Cassandra's public API is based on Thrift, which offers no streaming abilities -- any value written or fetched has to fit in memory.  This is inherent to Thrift's design; I don't see it changing.  So adding large object support to Cassandra would need a special API that manually split the large objects up into pieces.  Jonathan Ellis sketched out one approach in https://issues.apache.org/jira/browse/CASSANDRA-265.
  
  == Obsolete Limitations ==