Hi,
I have the following table:
CREATE TABLE integration_time (
message_source_id uuid,
traffic_data_type varchar,
integration_period varchar,
integration_time timestamp,
PRIMARY KEY ((message_source_id,traffic_data_type,integration_period))
);
I want the combination of (message_source_id,
Hi Wim,
Yes, that is looks correct to me.
Cheers,
Jens
On Tue, Jul 1, 2014 at 8:37 AM, Wim Deblauwe wim.debla...@gmail.com wrote:
Hi,
I have the following table:
CREATE TABLE integration_time (
message_source_id uuid,
traffic_data_type varchar,
integration_period varchar,
Hi again,
As a follow-up; if you have many `message_source_id`s you could also do:
CREATE TABLE integration_time (
message_source_id uuid,
traffic_data_type varchar,
integration_period varchar,
integration_time timestamp,
PRIMARY KEY (message_source_id,traffic_data_type,integration_period)
);
Hi,
thanks for the tip, but I never need to query the traffic_data_types and
integration_periods for a single message_source, so I will keep the double
bracket notation then for now.
Thanks,
Wim
2014-07-01 12:03 GMT+02:00 Jens Rantil jens.ran...@tink.se:
Hi again,
As a follow-up; if you
I also expanded on a script originally written by Matt Stump @ Datastax.
The readme has the reasoning behind requiring sub-range repairs.
https://github.com/hancockks/cassandra_range_repair
On Mon, Jun 30, 2014 at 10:20 PM, Phil Burress philburress...@gmail.com
wrote:
@Paulo, this is very
You didn't post any timings, only when it started failing so it's unclear
whether performance is dropping off or scaling in some sort of linear or
non-linear fashion. Second the recommendation to do some traces which
should be much more telling.
On Fri, Jun 13, 2014 at 3:34 AM, Phil Luckhurst
I have a six node cluster in AWS (repl:3) and recently noticed that repair
was hanging. I've run with the -pr switch.
I see this output in the nodetool command line (and also in that node's
system.log):
Starting repair command #9, repairing 256 ranges for keyspace dev_a
but then no other
if the boxes are idle, you could use jstack and look at the stack… perhaps
it's locked somewhere.
Worth a shot.
On Tue, Jul 1, 2014 at 9:24 AM, Brian Tarbox tar...@cabotresearch.com
wrote:
I have a six node cluster in AWS (repl:3) and recently noticed that repair
was hanging. I've run with
A couple options:
1. You could use nodetool settraceprobability. If lots are slow, you can
then go to the system_events.sessions and pick out some slow ones.
2. You could update the metadata (temporarily) on your table and use
tracing ad-hoc using cqlsh.
Using #1 if you need to pick out exact
On Tue, Jul 1, 2014 at 9:24 AM, Brian Tarbox tar...@cabotresearch.com
wrote:
I have a six node cluster in AWS (repl:3) and recently noticed that repair
was hanging. I've run with the -pr switch.
It'll do that.
What version of Cassandra?
=Rob
We're running 1.2.13.
Any chance that doing a rolling-restart would help?
Would running without the -pr improve the odds?
Thanks.
On Tue, Jul 1, 2014 at 1:40 PM, Robert Coli rc...@eventbrite.com wrote:
On Tue, Jul 1, 2014 at 9:24 AM, Brian Tarbox tar...@cabotresearch.com
wrote:
I have a
Does this output from jstack indicate a problem?
ReadRepairStage:12170 daemon prio=10 tid=0x7f9dcc018800 nid=0x7361
waiting on condition [0x7f9db540c000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for
On Tue, Jul 1, 2014 at 11:09 AM, Brian Tarbox tar...@cabotresearch.com
wrote:
We're running 1.2.13.
1.2.17 contains a few streaming fixes which might help.
Any chance that doing a rolling-restart would help?
Probably not.
Would running without the -pr improve the odds?
No, that'd
Given that an upgrade is (for various internal reasons) not an option at
this point...is there anything I can do to get repair working again? I'll
also mention that I see this behavior from all nodes.
Thanks.
On Tue, Jul 1, 2014 at 2:51 PM, Robert Coli rc...@eventbrite.com wrote:
On Tue, Jul
On Tue, Jul 1, 2014 at 11:54 AM, Brian Tarbox tar...@cabotresearch.com
wrote:
Given that an upgrade is (for various internal reasons) not an option at
this point...is there anything I can do to get repair working again? I'll
also mention that I see this behavior from all nodes.
I think
For what purpose are you running repair? Because I read that we should!
:-)
We do delete data from one column family quite regularly...from the other
CFs occasionally. We almost never run with less than 100% of our nodes up.
In this configuration do we *need* to run repair?
Thanks,
On Tue,
That uname call is in there specifically to check if you're running from
cygwin and force a pidfile to be written for stop-server.bat if so; ctrl+c
functionality in mintty is inconsistent with its signal trapping across
both cygwin and Windows releases.
I wrote the PowerShell start-up scripts
The extra parentheses are used to indicate that the three columns constitute
the “partition key” – otherwise only the first column of the primary key would
be the partition key. The partition key indicates which data rows will be
stored contiguously on a single node of the cluster. As written,
Thanks! We retrieved all the ranges and started running repair on them. We
ran through all of them but found one single range which brought the ENTIRE
cluster down. All of the other ranges ran quickly and smoothly. This one
problematic range reliably brings it down every time we try to run repair
Hi Duyhai,
According to a reply I got from a Datastax member, the unit is in milli-second.
Thanks,
Senhua
From: DuyHai Doan doanduy...@gmail.commailto:doanduy...@gmail.com
Reply-To: user@cassandra.apache.orgmailto:user@cassandra.apache.org
On Tue, Jul 1, 2014 at 3:53 PM, Phil Burress philburress...@gmail.com
wrote:
Thanks! We retrieved all the ranges and started running repair on them. We
ran through all of them but found one single range which brought the ENTIRE
cluster down. All of the other ranges ran quickly and smoothly.
I'm really perplexed on this one.. I think this must be a bug or some
misconfiguration somewhere.
I'm fetching ONE row which is one cell in my table.
The row is in the row cache, sitting in memory.
SELECT sequence from content where bucket=98 AND sequence =
140348149405742;
And look at
you know.. one thing I failed to mention.. .is that this is going into a
bucket and while it's a logical row, the physical row is like 500MB …
according to compaction logs.
is the ENTIRE physical row going into the cache as one unit? That's
definitely going to be a problem in this model. 500MB
On Tue, Jul 1, 2014 at 6:06 PM, Kevin Burton bur...@spinn3r.com wrote:
you know.. one thing I failed to mention.. .is that this is going into a
bucket and while it's a logical row, the physical row is like 500MB …
according to compaction logs.
is the ENTIRE physical row going into the cache
so.. caching the *queries* ?
it seems like a better mechanism would be to cache the actually logical
row…, not the physical row.
Query caches just don't work in production, If you re-word your query, or
structure it a different way, you get a miss…
In my experience.. query caches have a 0% hit
A work around for this, is the VFS page cache.. basically, disabling
compression, and then allowing the VFS page cache to keep your data in
memory.
The only downside is the per column overhead. But if you can store
everything in a 'blob' which is optionally compressed, you're generally
going to
WOW.. so based on your advice, and a test, I disabled the row cache for the
table.
The query was instantly 20x faster.
so this is definitely an anti-pattern.. I suspect cassandra just tries to
read in they entire physical row into memory and since my physical row is
rather big.. ha. Well that
Rowcache is typically turned off because it is only useful in very specific
situations-the row(s) need to fit in memory. Also, the access patterns have to
fit.
If all the rows you're accessing can fit, Rowcache is a great thing. Otherwise,
not so great.
--
Colin
320-221-9531
On Jul 1,
28 matches
Mail list logo
