Re: operation and maintenance tools

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

Re: A difficult data model with C*

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

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 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,

Re: A difficult data model with C*

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, >>

Re: A difficult data model with C*

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

Re: Secondary index tombstone limit

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

Secondary index tombstone limit

Hi, could you please clarify: 100k tombstone limit for SE is per CF, cf-node, original sstable or (very unlikely) partition? Thanks! -- Oleg Krayushkin

operation and maintenance tools

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

A difficult data model with C*

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

Re: store individual inventory items in a table, how to assign them correctly

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

Re: large number of pending compactions, sstables steadily increasing

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

Re: large number of pending compactions, sstables steadily increasing

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

store individual inventory items in a table, how to assign them correctly

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.

Re: Designing a table in cassandra

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

Re: Cassandra Python Driver : execute_async consumes lots of memory?

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

Cassandra Python Driver : execute_async consumes lots of memory?

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

Re: large number of pending compactions, sstables steadily increasing

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

Re: Using a Set for UDTs, how is uniqueness established?

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: > >

Re: Using a Set for UDTs, how is uniqueness established?

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.

Using a Set for UDTs, how is uniqueness established?

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

Re: failing bootstraps with OOM

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

Re: Are Cassandra writes are faster than reads?

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

Re: Designing a table in cassandra

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