On Sun, Aug 31, 2014 at 2:59 AM, Todd Nine wrote:
> Hi all,
> I'm working on transferring our thrift DAOs over to CQL. It's going
> well, except for 2 cases that both use multi get. The use case is very
> simple. It is a narrow row, by design, with only a few columns. When I
> perform a mul
a.apache.org
> *Subject:* Re: Help with migration from Thrift to CQL3 on Cassandra 2.0.10
>
> Hey Michael,
>Thanks for the response. If I use the clustered columns in the way you
> described, won't that make the row key of the column family scopeId and
> scopeType?
>
&g
You might want to take a look at Titan, a graph database that can use Cassandra
as its storage engine, and see how it does these things.
-- Jack Krupansky
From: Todd Nine
Sent: Sunday, August 31, 2014 11:06 AM
To: user@cassandra.apache.org
Subject: Re: Help with migration from Thrift to CQL3
You need to switch gears to new terminology as well - a "thrift row" is a
partition now, etc... :)
So yes - the *partition* key of the *table* would be scopeId, scopeType in
my proposed scheme.
But the partitions would be too big, given what you describe.
You could shard the rows, but even then
Hey Michael,
Thanks for the response. If I use the clustered columns in the way you
described, won't that make the row key of the column family scopeId and
scopeType?
The scope fields represent a graph's owner. The graph itself can have
several billion nodes in it. When a lot of deletes star
Actually I think you do want to use scopeId, scopeType as the partition key
(and drop row caching until you upgrade to 2.1 where "rows" are in fact
rows and not partitions):
CREATE TABLE IF NOT EXISTS Graph_Marked_Nodes
(
scopeId uuid, scopeType varchar, nodeId uuid, nodeType varchar,
timestam
Hi all,
I'm working on transferring our thrift DAOs over to CQL. It's going
well, except for 2 cases that both use multi get. The use case is very
simple. It is a narrow row, by design, with only a few columns. When I
perform a multiget, I need to get up to 1k rows at a time. I do not want
t
