I don't understand the advantages of ColumnFamilies over a
SuperColumnFamily with just one supercolumn. Why have the former if the
latter is functionally equivalent?
Thanks
Ted
the advantages of ColumnFamilies over a
SuperColumnFamily with just one supercolumn. Why have the former if the
latter is functionally equivalent?
JE http://issues.apache.org/jira/browse/CASSANDRA-598
So is there a vague plan to move to just SuperColumnFamilies once this
is resolved? The API
http://issues.apache.org/jira/browse/CASSANDRA-598
2010/3/3 Ted Zlatanov t...@lifelogs.com:
I don't understand the advantages of ColumnFamilies over a
SuperColumnFamily with just one supercolumn. Why have the former if the
latter is functionally equivalent?
Thanks
Ted
2010/3/3 Ted Zlatanov t...@lifelogs.com:
I don't understand the advantages of ColumnFamilies over a
SuperColumnFamily with just one supercolumn. Why have the former if the
latter is functionally equivalent?
Being pretty new here with Cassandra's terminology, I'm not sure what
be SuperColumns and ColumnFamilies can only
hold Columns.
I guess the term SuperColumnFamily (which I haven't seen documented)
is used when you want to implicitly say that SuperColumns are used
beneath.
--
Alex
twitter.com/alexconrad
What are the benefits of using multiple ColumnFamilies compared to using a
composite
row name?
Example: You have messages that you want to index on sent and to.
So you can either have
ColumnFamilyFrom:userTo:{userFrom-messageid}
ColumnFamilyTo:userFrom:{userTo-messageid}
or something like
are the benefits of using multiple ColumnFamilies compared to using a
composite
row name?
Example: You have messages that you want to index on sent and to.
So you can either have
ColumnFamilyFrom:userTo:{userFrom-messageid}
ColumnFamilyTo:userFrom:{userTo-messageid}
or something like
On Wed, Mar 3, 2010 at 6:56 AM, Jonathan Ellis jbel...@gmail.com wrote:
I would rather move to a more flexible model (as many levels of
nesting as you want) than a less-flexible one.
+1
This is one of patterns that I have seen many times: providing for as
many levels as you want may not be
On 2010-03-05 18:04, Erik Holstad wrote:
What are the benefits of using multiple ColumnFamilies compared to using
a composite row name?
Just for terminology's sake, I'll note that rows have keys, not names.
Only columns and supercolumns have names.
I'm not the top expert here by any means
you'll need to
(a) make sure you have the latest trunk
(b) wipe your data, commitlog, and system directories, since adding
new tables or columnfamilies non-destructively is not yet supported
(see https://issues.apache.org/jira/browse/CASSANDRA-44)
-Jonathan
On Tue, Jun 23, 2009 at 8:55 AM
um, silly me, there's no data folder for each ColumnFamily of course.
I am still wondering how to delete entire ColumnFamilies...
On Wed, Oct 21, 2009 at 6:54 PM, Johannes Schaback
johannes.schab...@visual-meta.com wrote:
Hi
I am currently using a ColumnFamily as an intermediate store for data
but this is probably the best fit for us. We'd
JE want to allow ColumnFamilies with either traditional (for Cassandra)
JE long timestamps, or vector clocks, but not mixed. The bad news is,
JE this is a very substantial change and will probably not be in 0.9
JE unless someone steps up to do the work
in a system
JE emphasizing availability, but incr/decr can be provided in an
JE eventually consistent manner with vector clocks. There are other
JE possible approaches but this is probably the best fit for us. We'd
JE want to allow ColumnFamilies with either traditional (for Cassandra)
JE long
On 2010-03-05 18:30, David Strauss wrote:
On 2010-03-05 18:04, Erik Holstad wrote:
So you can either have
ColumnFamilyFrom:userTo:{userFrom-messageid}
ColumnFamilyTo:userFrom:{userTo-messageid}
or something like
ColumnFamily:user_to:{user1_messageId, user2_messageId}
.
--
KeysCachedFraction0.01/KeysCachedFraction
!-- if FlushPeriodInMinutes is configured and positive, it will
be
flushed to disk with that period whether it is dirty or
not.
This is intended for lightly-used columnfamilies so that
they
do
:
Hi all,
I know the limitation when using super column.
# 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
and ColumnFamilies:
~ A ColumnFamily is the Cassandra concept closest to a relational
~ table. Keyspaces are separate groups of ColumnFamilies. Except in
~ very unusual circumstances you will have one Keyspace per application.
~ There is an implicit keyspace named 'system' for Cassandra
17 matches
Mail list logo
