We seem to be having a fundamental misunderstanding. Thanks for your
comments. aj
On 7/3/2011 8:28 PM, William Oberman wrote:
I'm using cassandra as a tool, like a black box with a certain
contract to the world. Without modifying the "core", C* will send the
updates to all replicas, so your
I'm using cassandra as a tool, like a black box with a certain contract to
the world. Without modifying the "core", C* will send the updates to all
replicas, so your plan would cause the extra write (for the placeholder). I
wasn't assuming a modification to how C* fundamentally works.
Sounds lik
On Sun, Jul 3, 2011 at 5:12 PM, Jeremy Hanna wrote:
> Trying some other stuff with tools mentioned here:
> http://spyced.blogspot.com/2010/01/linux-performance-basics.html but not
> seeing anything particularly disk bound, though await (from iostat -x) seems
> high on one of the devices.
Are y
On 7/3/2011 6:32 PM, William Oberman wrote:
Was just going off of: " Send the value to the primary replica and
send placeholder values to the other replicas". Sounded like you
wanted to write the value to one, and write the placeholder to N-1 to me.
Yes, that is what I was suggesting. The po
Was just going off of: "Send the value to the primary replica and send
placeholder values to the other replicas". Sounded like you wanted to write
the value to one, and write the placeholder to N-1 to me. But, C* will
propagate the value to N-1 eventually anyways, 'cause that's just what it
does
On 7/3/2011 4:07 PM, Yang wrote:
I'm no expert. So addressing the question to me probably give you real
answers :)
The single entry mode makes sure that all writes coming through the
leader are received by replicas before ack to client. Probably wont be
stale data
That doesn't sound any
On 7/3/2011 3:49 PM, Will Oberman wrote:
Why not send the value itself instead of a placeholder? Now it takes
2x writes on a random node to do a single update (write placeholder,
write update) and N*x writes from the client (write value, write
placeholder to N-1). Where N is replication factor
On Jul 3, 2011, at 4:29 PM, Jeremy Hanna wrote:
> Anyone know if secondary index performance should be in the 100-500 ms range.
> That's what we're seeing right now when doing lookups on a single value.
> We've increased keys_cached and rows_cached to 100% for that column family
> and assume
I'm no expert. So addressing the question to me probably give you real
answers :)
The single entry mode makes sure that all writes coming through the leader
are received by replicas before ack to client. Probably wont be stale data
On Jul 3, 2011 11:20 AM, "AJ" wrote:
> Yang,
>
> How would you de
Why not send the value itself instead of a placeholder? Now it takes
2x writes on a random node to do a single update (write placeholder,
write update) and N*x writes from the client (write value, write
placeholder to N-1). Where N is replication factor. Seems like extra
network and IO in
Anyone know if secondary index performance should be in the 100-500 ms range.
That's what we're seeing right now when doing lookups on a single value. We've
increased keys_cached and rows_cached to 100% for that column family and assume
that the secondary index gets the same attributes. I've
Yang,
How would you deal with the problem when the 1st node responds success
but then crashes before completely forwarding any replicas? Then, after
switching to the next primary, a read would return stale data.
Here's a quick-n-dirty way: Send the value to the primary replica and
send pla
Quoting Eric Evans :
> On Sat, 2011-07-02 at 19:17 +0100, dnalls...@taz.qinetiq.com wrote:
> > Just to illustrate; the typical injection pattern is:
> > select * from users where KEY='jsmith'; DROP COLUMNFAMILY 'users';
>
> No, each CQL query must contain exactly one statement, so this sort of
> a
You could do the serialization for all your supported datatypes yourself (many
libraries for serialization are available and a pretty thorough benchmarking
for them can be found here: https://github.com/eishay/jvm-serializers/wiki) and
prepend the serialized bytes with an identifier for your dat
Hi all,
I need to store column values that are of various data types in a
single column family, i.e I have column values that are integers,
others that are strings, and maybe more later. All column names are
strings (no comparator problem for me).
The thing is I need to store unstructured data - I
First, move off 0.7.2 if you can. While you may not get hit with this
https://github.com/apache/cassandra/blob/cassandra-0.7.6-2/NEWS.txt#L61 you may
have trouble with this https://issues.apache.org/jira/browse/CASSANDRA-2554
For background read the section on Staring Up and on Concurrency here
Ah, I get it. Your normal access pattern should be one row at a time.
On Sun, Jul 3, 2011 at 11:41 AM, David Boxenhorn wrote:
>>> What do you think ?
>>
>> I think you should strongly consider denormalizing so that you can
>> read ranges from a single row instead.
>
> Why do you recommend denorma
>> What do you think ?
>
> I think you should strongly consider denormalizing so that you can
> read ranges from a single row instead.
Why do you recommend denormalizing instead of secondary indexes?
18 matches
Mail list logo
