Currently there is a limitation that each row must fit in memory (with some
not insignificant overhead), thus having lots of columns per row can trigger
out-of-memory errors. This limitation should be removed in a future
release.
Please see:
- http://wiki.apache.org/cassandra/CassandraLimitation
On Wed, Jul 7, 2010 at 11:33 AM, Jonathan Ellis wrote:
> Having a few requests time out while the service detects badness is
> typical in this kind of system. I don't think writing a completely
> separate StorageProxy + supporting classes to allow avoiding this in
> exchange for RF times the net
We've been experiencing some cluster-wide performance issues if any single
node in the cluster is performing poorly. For example this occurs if
compaction is running on any node in the cluster, or if a new node is being
bootstrapped.
We believe the root cause of this issue is a performance optimiz
Hi Julie --
Keep in mind that there is additional data storage overhead, including
timestamps and column names. Because the schema can vary from row to row,
the column names are stored with each row, in addition to the data. Disk
space-efficiency is not a primary design goal for Cassandra.
Mason
Grepping through the logs, I haven't been able to deduce what was going on
at the same time, but I have found many instances of these errors for
multiple files going back for weeks nows. (Found 848 of these errors since
4-23-2010). The files not found include Index and Data files spanning
multiple
One of our Cassandra nodes is throwing multiple of these errors:
ERROR [ROW-READ-STAGE:185] 2010-04-27 14:56:59,543 CassandraDaemon.java
(line 78) Fatal exception in thread Thread[ROW-READ-STAGE:185,5,main]
java.lang.RuntimeException: java.io.FileNotFoundException:
/data/cassandra/data/Onespot/Ent
done some
exploring: http://codemonkeyism.com/cassandra-scala-akka/
[1] http://en.wikipedia.org/wiki/Software_transactional_memory
[2] http://doc.akkasource.org/
Mason Hale
http://www.onespot.com
On Thu, Apr 22, 2010 at 9:14 AM, Miguel Verde wrote:
> No, as far as I know no one is working o
On Sun, Apr 18, 2010 at 8:26 AM, Brandon Williams wrote:
>
> On Sun, Apr 18, 2010 at 8:00 AM, Mason Hale wrote:
>
>> 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
On Sun, Apr 18, 2010 at 7:41 AM, Gary Dusbabek wrote:
> On Sat, Apr 17, 2010 at 10:50, dir dir 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 m
On Sat, Apr 17, 2010 at 10:50 AM, dir dir wrote:
> Hi Mason,
>
> Honestly, I am beginner user in Cassandra. I rather confused to follow
> this database. I ask to the forum about the reason twitter.com to use
> Cassandra
> because I want to know the basic reason why we choose Cassandra instead of
Twitter who made this
decision can really explain the rationale behind it.
This link should shed some light on the subject:
http://engineering.twitter.com/2010/02/link-cassandra-at-twitter.html
Mason
--
Mason Hale
http://www.onespot.com
direct +1 800.618.0768 ext 701
ty. No geometry
calulations required. ;-)
This page provides a good description of the technique:
http://code.google.com/apis/maps/articles/geospatial.html
Mason
--
Mason Hale
http://www.onespot.com
direct +1 800.618.0768 ext 701
12 matches
Mail list logo