Hmm interesting could be some variation on 3510 (which caught me out).
Personally I really don't like having to rely on repair to stop deletes
being undone. If you agree follow this proposal for an alternative
https://issues.apache.org/jira/browse/CASSANDRA-3620 which also stops
tombstone build up
currently j.o.a.c.io.sstable.indexsummary is implemented as ArrayList of
KeyPosition (RowPosition key, long offset)
i propose to change it to
RowPosition keys[]
long offsets[]
this will lower number of java objects used per entry from 2
(KeyPosition + RowPosition) to 1.
For building these ar
On 2011-12-28 12:52 , Dominic Williams wrote:
Hmm interesting could be some variation on 3510 (which caught me out).
Actually after making some further reading of the changelog 2786 looks
like a likely culprit.
If I'm reading the jira correctly all versions < 0.8.8 and < 1.0.4 are
at risk of
There really is no generic way of comparing these systems, NoSQL
databases are highly heterogeneous.
The only credible and accurate way of doing a comparison is for a
specific, well defined, use case. Other than that you are always going
to be comparing apples to oranges thus having an crappy (and
I wanted to throw out a "solution" of mine . With hinted handoff being
guaranteed losing a delete is almost impossible so solutions like this are
no longer required, but...
My "solution" is always write deletes at cl.all. if a delete fails at all
queue it up, on a message queue, write a log, etc.
On Monday, December 26, 2011, Asil Klin wrote:
> If 3 rows in a column family need to be read together 'always', is it
preferable to just merge them in 1 row using composite col names(instead of
keeping in 3 rows) ? Does this improve read performance, anyway ?
You almost definitely want to merge
You need to execute one get slice operation for each item id or if the row
is not large , you can try one large get slice on the entire row and deal
with the results client side.
If you try method 1 When doing slices on composites you can set the start
inclusive or exclusive values to get only the
Since I have around 20 items to query, I guess making 20 queries to
retrieve activities by all followies on all of those 20 columns would too
inefficient, so to take the advantage of more efficient queries, are
supercolumns recommended for this case ? Anyways, in case I use
supercolumns, I need to
Super columns have the same fundamental problem and perform worse in
general. So switching from composites to super columns is NEVER a good idea.
On Wed, Dec 28, 2011 at 1:19 PM, Aditya wrote:
> Since I have around 20 items to query, I guess making 20 queries to
> retrieve activities by all fol
I believe this calls for Cassanda Cookbook 2nd edition :)
On Wed, Dec 28, 2011 at 10:26 AM, Edward Capriolo wrote:
> Super columns have the same fundamental problem and perform worse in
> general. So switching from composites to super columns is NEVER a good idea.
>
>
> On Wed, Dec 28, 2011 at 1:
Hi,
I was getting a runtime exception "Chose token 0 which is already in use by
..." when bootstrapping without initial_token. So looking at
StorageService getBootstrapToken(), if the ring has more than 2 nodes and
all nodes are up, do I always have to specify initial token when adding new
nodes?
Hi, it looks like cassandra 1.0.6 was released a while ago, but I still don't
see the rpm here: http://rpm.datastax.com/EL/5/i386/
Any idea when that will be out?
Thanks,
Shu
> exception "May not be enough replicas present to handle consistency level"
Check for mistakes in using getendpoints. Cassandra says Unavailable
when there is not enough replicas *IN THE REPLICA SET FOR THE ROW KEY*
to satisfy the consistency level.
> I tried to read data using cassandra-cli but
I've noticed when creating column families that the name of the column
family apparently has some restrictions...e.g. the presence of a '.'
character in the column family name seems to throw an exception. Is
there anywhere articulated the restrictions on column family names (and
keyspace names
14 matches
Mail list logo
