I suspect this will kill the benefit of DTCS, but haven't tested it to be
100% here.
The benefit of DTCS is that sstables are selected for compaction based on
the age of the data, not their size. When you mix TTL'ed data and non
TTL'ed data, you end up screwing with the "drop the entire SSTable"
I have a potential use case I haven’t had a chance to prototype yet, which
would normally be a good candidate for DTCS (i.e. data delivered in order and a
fixed TTL), however with every write we’d also be updating some static cells
(namely a few key/values in a static map CQL column). There coul
Thanks for the detailed answer!
2015-04-30 17:14 GMT+03:00 Jonathan Haddad :
> You can connect to any node in the cluster to issue a query. For that
> request, it's called the coordinator. The coordinator will figure out
> which node to talk to. The DataStax native drivers can use what's calle
Hi guys, this (old) thread has no answers.
@Donald, did you find out answer to your second question ? (first one
depends on the second imho)
@all, Any pointer or extra info would be great.
Alain
2014-10-22 18:03 GMT+02:00 Donald Smith :
> Sorry, I copy-and-pasted the wrong variable name. I m
You can connect to any node in the cluster to issue a query. For that
request, it's called the coordinator. The coordinator will figure out
which node to talk to. The DataStax native drivers can use what's called
token aware queries, in that they'll connect to one of the nodes that owns
the data
I'm trying to use cassandra-stressd (daemon Mode)
Following the instruction in this link
http://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsCStressDaemon_t.html
Two questions:
1. What does"-h host" parameter stands for, the daemon server, the C*
server?
I can not find this the paramete
Thank for your response!
I've read the documentation but some points aren't clear for me still. Does
Cassandra support read/write operation only from/to node which is
responsible for this partition (calculated by has)?
2015-04-29 22:43 GMT+03:00 Robert Coli :
> On Wed, Apr 29, 2015 at 8:56 AM, Ni
In general your data model should match your queries in Cassandra.
In the examples you provided the queries are by name, not by ID, so I don’t see
much use in using ID as the primary key.
Without much context, like why you are using SET or if queries must specify
both first_name and last_name whi
Thanks Rahul and Arun
On Thu, Apr 30, 2015 at 3:24 PM, Rahul Neelakantan wrote:
> Here is a calculator someone has put together
>
>
> http://btoddb-cass-storage.blogspot.com/2012/01/ive-been-asked-for-spreadsheet-to-help.html?m=1
>
> Rahul
>
> On Apr 30, 2015, at 12:53 AM, arun sirimalla wrote:
Here is a calculator someone has put together
http://btoddb-cass-storage.blogspot.com/2012/01/ive-been-asked-for-spreadsheet-to-help.html?m=1
Rahul
> On Apr 30, 2015, at 12:53 AM, arun sirimalla wrote:
>
> Hi Rahul,
>
> If you are expecting 15 GB of data per day, here is the calculation.
>
Helle all,
I was wondering which data model of the Three describe below better in
terms of performance. Seems 3 is good.
*#1. log with 3 Index*
CREATE TABLE log (
id int PRIMARY KEY,
first_name set,
last_name set,
dob set
);
CREATE INDEX log_firstname_index ON test.log
11 matches
Mail list logo