Thank you for the response. Now I have more confidence on using nodetool:-)
From: Dikang Gu
Date: 2016-11-08 14:52
To: cassandra
Subject: Re: operation and maintenance tools
Hi Simon,
For a 10 nodes cluster, Cassandra nodetool should be enough for most C*
operations and maintenance, unless you
Which version of Cassandra are you using? If this is a 3.0 or higher, why
don't you create a materialized view for ypur base table with the last time
as the first clustering colum?
However : It need to be confirmed if this is not an anti-pattern for
cassandra as this materialized view will have a
Hi Simon,
For a 10 nodes cluster, Cassandra nodetool should be enough for most C*
operations and maintenance, unless you have some special requirements.
For the memory, you can check what's your JVM settings, and the gc log for
JVM usage.
--Dikang.
On Mon, Nov 7, 2016 at 7:25 PM, wxn...@zjqunsh
Agree, change the last_time to be descending order will help, you can also
TTL the data, so that the old records will be purged by Cassandra.
--Dikang.
On Mon, Nov 7, 2016 at 10:39 PM, Alain Rastoul
wrote:
> On 11/08/2016 03:54 AM, ben ben wrote:
>
>> Hi guys,
>>CREATE TABLE recent (
>>
On 11/08/2016 03:54 AM, ben ben wrote:
Hi guys,
CREATE TABLE recent (
user_name text,
vedio_id text,
position int,
last_time timestamp,
PRIMARY KEY (user_name, vedio_id)
)
Hi Ben,
May be a clustering columns order would help
CREATE TABLE recent (
...
) WITH CLUSTER
unsubsribe
Sent from Yahoo Mail on Android
On Tue, 8 Nov, 2016 at 2:11 pm, Oleg Krayushkin wrote:
Hi, could you please clarify: 100k tombstone limit for SE is per CF, cf-node,
original sstable or (very unlikely) partition?
Thanks!--
Oleg Krayushkin
Hi, could you please clarify: 100k tombstone limit for SE is per CF,
cf-node, original sstable or (very unlikely) partition?
Thanks!
--
Oleg Krayushkin
Hi All,
I need to do maintenance work for a C* cluster with about 10 nodes. Please
recommend a C* operation and maintenance tools you are using.
I also noticed my C* deamon using large memory while doing nothing. Is there
any convenent tool to deeply analysize the C* node memory?
Cheers,
Simon
Hi guys,
We are maintaining a system for an on-line video service. ALL users' viewing
records of every movie are stored in C*. So she/he can continue to enjoy the
movie from the last point next time. The table is designed as below:
CREATE TABLE recent (
user_name text,
vedio_id text,
You can use lightweight transactions to achieve this.
Example:
UPDATE item SET customer = 'Joe' WHERE item_id = 2 IF customer = null;
Keep in mind that lightweight transactions have performance tradeoffs (
http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0)
On Mon, 7 Nov
Hm, this MAY somehow relate to the issue I encountered recently:
https://issues.apache.org/jira/browse/CASSANDRA-12730
I also made a proposal to mitigate excessive (unnecessary) flushes during
repair streams but unfortunately nobody commented on it yet.
Maybe there are some opinions on it around he
What I’ve seen happen a number of times is you get in a negative feedback
loop:
not enough capacity to keep up with compactions (often triggered by repair
or compaction hitting a large partition) -> more sstables -> more expensive
reads -> even less capacity to keep up with compactions -> repeat
T
Say I have 100 products in inventory, instead of having a counter I want to
create 100 rows per inventory item.
When someone purchases a product, how can I correctly assign that customer
a product from inventory without having any race conditions etc?
Thanks.
Hi Carlos Alonso,
Thanks for your quick answer.
Thanks and Regards
A.SathishKumar
On Mon, Nov 7, 2016 at 2:26 AM, Carlos Alonso wrote:
> Hi,
>
> I think your best bet is, as usual, the simplest one that can work, which,
> to me, in this case is the 3rd one. Creating one single device table tha
Hi Rajesh,
By looking at your code I see that the memory would definitely grow because
you write big batches async and you will end up large number of batch
statements and the all end up slowing down. We recently migrated some data
to C* and what we did was we created a data stream and wrote in ba
Hi
We are trying to inject millions to data into a table by executing Batches of
PreparedStatments.
We found that when we use 'session.execute(batch)', it write more data but very
very slow.
However if we use 'session.execute_async(batch)' then its relatively fast but
when it reaches certain
Hey guys,
Do we have any conclusions about this case? Ezra, did you solve your
problem?
We are facing a very similar problem here. LeveledCompaction with VNodes
and looks like a node went to a weird state and start to consume lot of
CPU, the compaction process seems to be stucked and the number of
Huh, so that means updates to the udt values won't be possible?
Sticking to a map then.
On Mon, Nov 7, 2016 at 5:31 PM, DuyHai Doan wrote:
> So, to compare UDT values, Cassandra will compare them field by field. So
> that udt1.equals(udt2) results in:
>
> udt1.field1.equals(udt2.field1)
>
So, to compare UDT values, Cassandra will compare them field by field. So
that udt1.equals(udt2) results in:
udt1.field1.equals(udt2.field1)
&& udt1.field2.equals(udt2.field2)
...
&& udt1.fieldN.equals(udt2.fieldN)
Your idea of using field "id" to distinguish between UDT value is good e.g.
I have a UDT which contains a text 'id' field, which should be used to
establish the uniqueness of the UDT.
I'd like to have a set field in a table, and I'd like to use the id
of the udts to establish uniqueness.
Any ideas how this can be done? Also using Java, and c* 3.7
If what you need is a replacement node, to increase the hardware specs I'd
recommend an 'immediate node replacement' like described here:
http://mrcalonso.com/cassandra-instantaneous-in-place-node-replacement/
Basically the process just rsyncs the relevant data (data + configuration)
from one node
Thanks Jeff and Ben for the info.
On Mon, Nov 7, 2016 at 6:44 AM, Ben Bromhead wrote:
> They can be and it depends on your compaction strategy :)
>
> On Sun, 6 Nov 2016 at 21:24 Ali Akhtar wrote:
>
>> tl;dr? I just want to know if updates are bad for performance, and if so,
>> for how long.
>>
Hi,
I think your best bet is, as usual, the simplest one that can work, which,
to me, in this case is the 3rd one. Creating one single device table that
contains the different 'versions' of the configuration during time, along
with a flag to know wether it was updated by user or by network gives y
23 matches
Mail list logo