To delete all the columns for row send a Mutation where the Deletion has
neither a super_column or predicate
I test, but throw the exception “A SlicePredicate must be given a list of
Columns, a SliceRange, or both”
Best Regards
Donna li
发件人: aaron mort
> Not sure what the intended purpose is, but we've mostly used it as an
> emergency disk-capacity-increase option
Thats what I've used it for.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 28 Jun 2011, at 15:55, Dan Kuebrich
AFAIK that is still not supported.
To delete all the columns for row send a Mutation where the Deletion has
neither a super_column or predicate
Cheers
-
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 28 Jun 2011, at 15:50, Donna Li w
Not sure what the intended purpose is, but we've mostly used it as an
emergency disk-capacity-increase option. It's not as good as raid because
each disk size is counted individually (a compacted sstable can only be on
one disk) so compaction size limits aren't expanded as one might expect.
On Mo
Cassandra version is 0.7.2, when I use batch_mutate, the following exception
throw “TException:Deletion does not yet support SliceRange predicates”, which
version support delete the whole row of a key?
Best Regards
Donna li
发件人: Donna Li
发送时间: 201
I thought there is an option to give multiple data dirs in cassandra.yaml.
What's the purpose of that?
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/RAID-or-no-RAID-tp6522904p6523523.html
Sent from the cassandra-u...@incubator.apache.org mailing
All:
Can I remove all the columns of a key in a column family under the
condition that not know what columns the column family has?
Best Regards
Donna li
oftentimes people use time actually subconsciously to express causal
relations ("before/after"), as long as you have some other means to
establish causal relations, you don't really need to have an exactly clock.
On Mon, Jun 27, 2011 at 4:54 PM, aaron morton wrote:
> Without exception the timesta
Hi all, I just stumbled on to what looks like issue CASSANDRA-2653. Here's my
stack trace:
ERROR [ReadStage:10] 2011-06-27 15:22:36,087 AbstractCassandraDaemon.java (line
114) Fatal exception in thread Thread[ReadStage:10,5,main]
java.lang.AssertionError: No data found for
NamesQueryFilter(colu
If you have a quality HW raid controller with proper performance (and far from
all have good performance) you cam definitely benefit from a battery backed up
write cache on it, although the benefits will not be huge on raid 0.
Unless you get a really good price on that high performance HW raid
Without exception the timestamp is set by the client, not the server. The one
exception to the without exception rule is CounterColumnType operations.
If you are in a situation where you need better timing than you can get with
ntp you should try to design around it.
Hope that helps.
--
RAID0 so you have one big volume.
For performance (cassandra does not stripe sstables across the data dirs) and
otherwise you'll have fragmentation and wont be able to utilise all your space.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpic
Which one is preferred RAID0 or spreading data files accross various disks on
the same node? I like RAID0 but what would be the most convincing argument
to put additional RAID controller card in the machine?
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.na
Hi Nick,
Thanks, it looks a lot like what I'm experiencing. I've voted on the issue.
Regards,
Sebastien Coutu
On Mon, Jun 27, 2011 at 1:31 PM, Nick Bailey wrote:
> I believe you are describing the issure here:
>
> https://issues.apache.org/jira/browse/CASSANDRA-1777
>
> Until that issue is fi
On 6/27/2011 4:01 PM, A J wrote:
Is there an enhancement on the roadmap to stagger the auto compactions
on different nodes, to avoid more than one node compacting at any
given time (or as few nodes as possible to compact at any given time).
If not, any workarounds ?
Thanks.
+1. I proposed th
During writes, the timestamp field in the column is the system-time of
that node (correct me if that is not the case and the system-time of
the co-ordinator is what gets applied to all the replicas).
During reads, the latest write wins.
What if there is a clock skew ? It could lead to a stale writ
Is there an enhancement on the roadmap to stagger the auto compactions
on different nodes, to avoid more than one node compacting at any
given time (or as few nodes as possible to compact at any given time).
If not, any workarounds ?
Thanks.
Each node (independently) has logic that guarantees that any writes
processed before the truncate, will be wiped out.
This does not mean that each node will wipe out the same data, or even
that each node will process the truncate (which would result in a
timedoutexception).
It also does not mean
On Mon, 2011-06-27 at 15:06 -0600, AJ wrote:
> Would anyone care to talk about their experiences with using Solandra
> along side another application that uses Cassandra (also on the same
> node)? I'm curious about any resource contention issues or
> compatibility between C* versions and Sol.
Hi everyone,
Would anyone care to talk about their experiences with using Solandra
along side another application that uses Cassandra (also on the same
node)? I'm curious about any resource contention issues or
compatibility between C* versions and Sol. Also, I read the developer
somewhere
If those went to zero, it would certainly tell me something happened. :) I
guess watching that would be a way of seeing something was going on.
Is the truncate itself propagating a ring-wide marker or anything so the CF
is logically "empty" before being physically removed? That's the impression
There's a JMX method to get the number of sstables in a CF, is that
what you're looking for?
On Mon, Jun 27, 2011 at 1:04 PM, Ethan Rowe wrote:
> Is there any straightforward means of seeing what's going on after issuing a
> truncate (on 0.7.5)? I'm not seeing evidence that anything actually
> h
Is there any straightforward means of seeing what's going on after issuing a
truncate (on 0.7.5)? I'm not seeing evidence that anything actually
happened. I've disabled read repair on the column family in question and
don't have anything actively reading/writing at present, apart from my
one-off
I believe you are describing the issure here:
https://issues.apache.org/jira/browse/CASSANDRA-1777
Until that issue is fixed though, the solution is to use the same
interface for both.
On Mon, Jun 27, 2011 at 12:09 PM, Sebastien Coutu wrote:
> Hi Everyone,
> Quick question regarding the listen_
Let me make that simpler.
Don't ever use replicate_on_write=false (even if you "think" that it is
what you want, there is a good chance it's not).
Obviously, the default is replicate_on_write=true.
--
Sylvain
On Mon, Jun 27, 2011 at 7:03 PM, Philippe wrote:
> if i write at ALL and read at ONE,i
Hi Everyone,
Quick question regarding the listen_address and rpc_address parameters.
We're trying to run some map-reduce jobs on our ring and my goal is to split
the Cassandra intra-cluster traffic from the Thrift calls. I've populated
the listen_address with the IP address of one interface and rp
if i write at ALL and read at ONE,is that setting required ?
thanks
Le 27 juin 2011 17:22, "Donal Zang" a écrit :
> On 27/06/2011 17:04, Artem Orobets wrote:
>>
>> Hi!
>>
>> As I know, we use counter column only with replication factor ALL, so
>> is it mean that we can't read data while any replic
i used TimeUUIDType as type in storage-conf.xml file
and i used it as comparator in my java code,
but in the execution i get exception :
Erreur --java.io.UnsupportedEncodingException: TimeUUIDType
how can i write it?
BR
De : David Boxenhorn
À : user@cas
On 27/06/2011 17:04, Artem Orobets wrote:
Hi!
As I know, we use counter column only with replication factor ALL, so
is it mean that we can't read data while any replica will fail?
you can use any consistency level, using replicate_on_write=true when
create the counter column family.
--
Do
The replacement is to use the replication_factor variable in strategy options.
If you look in
http://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.0/conf/schema-sample.txt
you can see an example of that.
The issue to do that was https://issues.apache.org/jira/browse/CASSANDRA-1263
The
It belongs in strategy_options now.
For example, strategy_options={'replication_factor': '1'} in Python.
On Mon, Jun 27, 2011 at 9:57 AM, Michal Augustýn
wrote:
> Hi all,
>
> I just look into "Cassandra.thrift" file from 0.8 distribution and
> replication_factor element of KsDef structure is mar
Hi!
As I know, we use counter column only with replication factor ALL, so is it
mean that we can't read data while any replica will fail?
Hi all,
I just look into "Cassandra.thrift" file from 0.8 distribution and
replication_factor element of KsDef structure is marked as
@deprecated. What is the non-deprecated replacement for this (IMHO)
core setting? Or is CQL the replacement?
Thanks!
Augi
On Mon, Jun 27, 2011 at 12:02 PM, Philippe wrote:
> a quick followup on this : when using Byte ordered partitioner. how does a
> short key get mapped to the 128bit token ? what about keys longer than 128 ?
> does Cassandra just pad and truncate ?
Token are not limited to 128 bits. With the ordere
a quick followup on this : when using Byte ordered partitioner. how does a
short key get mapped to the 128bit token ? what about keys longer than 128 ?
does Cassandra just pad and truncate ?
thanks
Le 24 juin 2011 04:53, "Maki Watanabe" a écrit :
> A little addendum
>
> Key := Your data to identi
35 matches
Mail list logo
