I would probably use a messaging layer to perform this operation. Kafka
works very well, but depending on your throughput requirements almost
anything should work.
The idea is to publish your mutation requests to the messaging layer and
allow multiple consumers to process those mutation requests i
I tend to agree with Carlos. Having multiple row keys and parallelizing
your queries will tend to result in faster responses. Keeping positions
relatively small will also help your cluster to manage your data more
efficiently also resulting in better performance.
One thing I would recommend is to
As long as you shut down the node before you start copying and moving stuff
around it shouldn't matter if you take backups or snapshots or whatever.
When you add the filesystem for the ssd will you be removing the existing
filesystem? Or will you be able to keep both filesystems mounted at the
sam
I could be wrong on this since I've never actually attempted what you are
asking. Based on my understanding of how replica assignment is done, I
don't think that just changing the rack on an existing node is a good idea.
Changing racks for a node that already contains data would result in that
dat
When you say you have two logical DC both with the same name are you saying
that you have two clusters of servers both with the same DC name, nether of
which currently talk to each other? IE they are two separate rings?
Or do you mean that you have two keyspaces in one cluster?
Or?
Clint
On Mar
I would arrange your primary key by how You intend to query.
Primary key ((executedby), auditid)
This allows you to query for who did it, and optionally on a time range for
when it occurred. Retrieving in chronological order.
You could do it with your proposed schema and Lucene but for what you
Light weight transactions are going to be somewhat key to this. As are
batches.
The interesting thing about these views is that changing an email address
is not the same operation on all of them.
For The users by email view you have to delete a given existing row and
insert a new one.
For the ot
I would definitely be interested in this.
Clint
On Mar 15, 2016 9:36 PM, "Eric Stevens" wrote:
> We have been working on filtering compaction for a month or so (though we
> call it deleting compaction, its implementation is as a filtering
> compaction strategy). The feature is nearing completio
nuanced.
datastax had a blog post that describes this better as well as limitations
to the algorithm in 2.1 which are addressed in the 3.x releases )
Clint
On Feb 28, 2016 10:11 AM, "Michał Łowicki" wrote:
>
>
> On Sun, Feb 28, 2016 at 4:00 PM, Clint Martin <
> clintlmar...
Your plan for replacing your 200gb drive sounds good to me. Since you are
running jbod, I wouldn't worry about manually redistributing data from your
other disk to the new one. Cassandra will do that for you as it performs
compaction.
While you're doing the drive change, you need to complete the s
I have experienced excessive performance issues while using collections as
well. Mostly my issue was due to the excessive number of cells per
partition that having a modest map size requires.
Since you are reading and writing the entire map, you can probably gain
some performance the same way I di
What sort of data is your clustering key composed of? That might help some
in determining a way to achieve what you're looking for.
Clint
On Jan 5, 2016 2:28 PM, "Jim Ancona" wrote:
> Hi Nate,
>
> Yes, I've been thinking about treating customers as either small or big,
> where "small" ones have
You should endeavor to use a repeatable method of segmenting your data.
Swapping partitions every time you "fill one" seems like an anti pattern to
me. but I suppose it really depends on what your primary key is. Can you
share some more information on this?
In the past I have utilized the consiste
Generating the time uuid on the server side via the now() function also
makes the operation non idempotent. This may not be a huge problem for your
application but it is something to keep in mind.
Clint
On Oct 29, 2015 9:01 AM, "Kai Wang" wrote:
> If you want the timestamp to be generated on the
Max hint window is only part of the equation. If it is down longer than
Max hint window, a repair will still fix up the node for you.
The max time a node can be down before it must be re built is determined by
the lowest gc grace setting on your various tables. By default gc grace is
10 days, but
t; interesting. I am going to explore that in more detail.
>
> Thanks for the good idea.
>
> On 3 October 2015 at 00:03, Clint Martin <
> clintlmar...@coolfiretechnologies.com> wrote:
>
>> You could use a two key space method. At startup, wait some time for the
>&
You could use a two key space method. At startup, wait some time for the
node to join the cluster.
the first time the app starts, you can be in one of three states:
The happiest state is that you succeed in joining a cluster. in this case
you will get replicated the cluster's keyspace and can s
17 matches
Mail list logo
