You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by Apache Wiki <wi...@apache.org> on 2010/05/25 23:48:36 UTC
[Cassandra Wiki] Update of "CassandraLimitations" by StuHood
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 StuHood.
http://wiki.apache.org/cassandra/CassandraLimitations?action=diff&rev1=9&rev2=10
--------------------------------------------------
== Artifacts of the current code base ==
* The byte[] size of a value can't be more than 2^31-1.
* 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. This will be fixed in https://issues.apache.org/jira/browse/CASSANDRA-16
+ * A related limitation is that an entire row cannot be larger than 2^31-1 bytes, since the length of rows is serialized to disk using an integer.
* 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. https://issues.apache.org/jira/browse/CASSANDRA-598 is open to remove this limitation.
* <<Anchor(streaming)>>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 http://issues.apache.org/jira/browse/CASSANDRA-265. As a workaround in the meantime, you can manually split files into chunks of whatever size you are comfortable with -- at least one person is using 64MB -- and making a file correspond to a row, with the chunks as column values.
* Thrift will crash Cassandra if you send random or malicious data to it. This makes exposing the Cassandra port directly to the outside internet a Bad Idea. See http://issues.apache.org/jira/browse/CASSANDRA-475 and http://issues.apache.org/jira/browse/THRIFT-601 for details.