What would/could take so long for the nodes to agree? It's a small cluster (7
nodes) all on local LAN and not being used by anything else.
I think a delete refresh might be in order...
Thanks!
Bill-
On 02/15/2011 09:13 PM, Jonathan Ellis wrote:
command never returns means it's waiting for
I know nothing about postgis and little about spacial data, but if you're simply
talking about data that relates to some latitude longitude pair, you could
have your row key simply be the concatenation of the two: lat:long.
Can you provide more details about the type of data you're looking to
To reiterate, so I know we're both on the same page, your schema would be
something like this:
- A column family (as you describe) to store the details of a reminder. One
reminder per row. The row key would be a TimeUUID.
- A super column family to store the reminders for each user, for each
Any time I see/hear a single row containing all ... I get nervous. That single
row is going to reside on a single node. That is potentially a lot of load
(don't know the system) for that single node. Why wouldn't you split it by at
least user? If it won't be a lot of load, then why are you
I did not understand before... sorry.
Again, depending upon how many reminders you have for a single user, this could
be a long/wide row. Again, it really comes down to how many reminders are we
talking about and how often will they be read/written. While a single row can
contain millions
I'm still very new to Cassandra, but when I started reading about it the first
thing I thought about was a session store. It's based (in part from what I
understand) on Dynamo which is (again, I could be wrong) used at Amazon as the
session store for your shopping cart.
So I would certainly
I'm very new to Cassandra, but I'll pitch in my $0.02.
Row look-ups are super fast, why do you think it would be more efficient to
store these two rows together in the super column method you describe?
Why would you not just look-up the rows, one after the other?
If I understand correctly,
It makes sense that the single row for a system (with a growing number of
columns) will reside on a single machine.
With that in mind, here is my updated schema:
- A single column family for all the messages. The row keys will be the TimeUUID
of the message with the following columns:
Ah, sweet... thanks for the link!
Bill-
On 01/26/2011 08:20 PM, buddhasystem wrote:
Bill, it's all explained here:
http://wiki.apache.org/cassandra/MemtableThresholds#JVM_Heap_Size,the
Watch the number of CFs and the memtable sizes.
In my experience, this all matters.
