Yes, it is ture. Current cassandra has many limitations or bad implementations, especially on storage level.
In my opinion, these limitations or bad implementations are just implementation, not the original intention of design. And I also want to give a suggestion/advice to the project leaders, we currently should avoid introducing too many useless/unnecessary, and forcus on fixing bugs/re-implement some core modules. On Sun, Apr 18, 2010 at 9:00 PM, Mason Hale <ma...@onespot.com> wrote: > > > On Sun, Apr 18, 2010 at 7:41 AM, Gary Dusbabek <gdusba...@gmail.com>wrote: > >> On Sat, Apr 17, 2010 at 10:50, dir dir <sikerasa...@gmail.com> wrote: >> > >> > What problems can’t it solve? >> > >> > No flexible indices >> > No querying on non PK values >> > Not good for binary data (>64mb) unless you chunck >> > Row contents must fit in available memory >> > >> > Gary Dusbabek say: Row contents must fit in available memory. Honestly I >> do >> > not understand >> > the meaning from that statement. Thank you. >> > >> > Dir. >> > >> >> The main reason is that the compaction operation (removing deleted >> values) currently requires that an entire row be read into memory. >> >> Gary Dusbabek >> > > > This is a statement I wish I had run across sooner. Our first > implementation (which we're changing now) included some very big rows. We > ran into trouble with compaction and during hinted hand-off operations > (which also deals with data a full row at a time) because these rows would > not fit into available memory. > > I think until there are not these lurking gotcha spots like compaction and > hinted hand-off, where a full row must fit in memory, we should not be > making misleading statements like "Cassandra has the advantage of a more > advanced datamodel, allowing for a single row to contain billions of > column/value pairs: enough to fill a machine." (from: > http://gigaom.com/2010/03/11/digg-cassandara/ , > http://spyced.blogspot.com/2010/03/cassandra-in-action.html). A statement > like that should have some caveats, otherwise it reads as an endorsement, a > suggestion even, to build a data model with massively wide rows. In > practice, it is not feasible to have billions of columns in a single row > because it will lead to problems with compaction and hinted hand-off, maybe > elsewhere. > > Mason > > >
