Hi,
youre right – one seek with hit in the partition key cache and two if not.
Thats the theory – but two thinge to mention:
First, you need two seeks per sstable not per entire read. So if you data is
spread over multiple sstables on disk you obviously need more then two reads.
Think of
On 20/03/2017 22:05, Michael Wojcikiewicz wrote:
Not sure if someone has suggested this, but I believe it's not
sufficient to simply add nodes to a cluster to increase read
performance: you also need to alter the ReplicationFactor of the
keyspace to a larger value as you increase your cluster
I am trying to scrub a Column family using nodetool scrub, is it going to
create snapshots for sstables which are corrupted or for all the sstables
it is going to scrub ?? and to remove snapshots created does running
nodetool clearsnapshot is enough or do i need to manually delete pre-scrub
data
I think the general assumption is that DC failover happens at the client
app level rather than the Cassandra level due to the potentially very
significant difference in request latency if you move from a app-local DC
to a remote DC. The preferred pattern for most people is that the app fails
in a
Specifically, this puts us in an awkward position because LOCAL_QUORUM is
desirable so that we don't have unnecessary cross-DC traffic from the client by
default, but we can't use it because it will cause complete failure if the
local DC goes down. And we can't use QUORUM because it would fail
Apologies for the stream-of-consciousness replies, but are the dropped
message stats output by tpstats an accumulation since the node came up, or
are there processes which clear and/or time-out the info?
On Mon, Mar 20, 2017 at 3:18 PM, Voytek Jarnot
wrote:
> No dropped
On 2017-03-20 13:17 (-0700), preetika tyagi wrote:
> I'm trying to understand the maximum number of disk seeks required in a
> read operation in Cassandra. I looked at several online articles including
> this one:
>
No dropped messages in tpstats on any of the nodes.
On Mon, Mar 20, 2017 at 3:11 PM, Voytek Jarnot
wrote:
> Appreciate the reply, Kurt.
>
> I sanitized it out of the traces, but all trace outputs listed the same
> node for all three queries (1 working, 2 not working).
I'm trying to understand the maximum number of disk seeks required in a
read operation in Cassandra. I looked at several online articles including
this one:
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutReads.html
As per my understanding, two disk seeks are required in the
Appreciate the reply, Kurt.
I sanitized it out of the traces, but all trace outputs listed the same
node for all three queries (1 working, 2 not working). Read repair chance
set to 0.0 as recommended when using TWCS.
I'll check tpstats - in this environment, load is not an issue, but network
default_time_to_live is a convenience parameter that automatically applies
a TTL to incoming data. Every field that's inserted can have a separate
TTL.
The TL;DR of all this is that changing default_time_to_live doesn't change
any existing data retroactively. You'd have to truncate the table if
As secondary indexes are stored individually on each node what you're
suggesting sounds exactly like a consistency issue. the fact that you read
0 cells on one query implies the node that got the query did not have any
data for the row. The reason you would sometimes see different behaviours
is
Hi,
On Fri, Mar 17, 2017 at 2:22 PM Paulo Motta
wrote:
> It's safe to truncate this table since it's just used to inspect repairs
> for troubleshooting. You may also set a default TTL to avoid it from
> growing unbounded (this is going to be done by default on
I would zero in on network throughput, especially interrack trunks
sent from my mobile
Daemeon Reiydelle
skype daemeon.c.m.reiydelle
USA 415.501.0198
On Mar 17, 2017 2:07 PM, "Roland Otta" wrote:
> hello,
>
> we are quite inexperienced with cassandra at the moment
Did you check STW GCs?
You can do that with 'nodetool gcstats', by looking at the gc.log or
observing GC related JMX metrics.
2017-03-20 8:52 GMT+01:00 Roland Otta :
> we have a datacenter which is currently used exlusively for spark batch
> jobs.
>
> in case batch jobs
we have a datacenter which is currently used exlusively for spark batch
jobs.
in case batch jobs are running against that environment we can see very
high peaks in blocked native transport requests (up to 10k / minute).
i am concerned because i guess that will slow other queries (in case
other
On 20/03/2017 02:35, S G wrote:
2)
https://docs.datastax.com/en/developer/java-driver/3.1/manual/statements/prepared/
tells me to avoid preparing select queries if I expect a change of
columns in my table down the road.
The problem is also related to select * which is considered bad practice
good point! i did not (so far) i will do that - especially because i often see
all compaction threads being used during repair (according to compactionstats).
thank you also for your link recommendations. i will go through them.
On Sat, 2017-03-18 at 16:54 +, Thakrar, Jayesh wrote:
You
18 matches
Mail list logo