Re: Recreating materialized views in cassandra

eating a JIRA describing: what's the workload/queries and how does it end up in an inconsistent state if you can reproduce it? On Wed, 29 Jul 2020 at 20:49, Jasonstack Zhao Yang < jasonstack.z...@gmail.com> wrote: > > The cluster started to crash when some partitions in MV crossed 1 G

Re: Recreating materialized views in cassandra

mentions cluster instability while creating and deleting mv's > > The cluster started to crash when some partitions in MV crossed 1 GB size >> at few nodes, whereas in other nodes it is less than 50 MB. > > > Should we be worried about this? > > On Mon, Jul 27, 2020

Re: Recreating materialized views in cassandra

Hi, > We are facing data inconsistency issues between base tables and materialized views. do you run "nodetool repair" on both base and view regularly? > What are all the possible scenarios that we should be watching out for in a production environment? more cpu/io/gc for populating views. > C

Re: Materialized View's additional PrimaryKey column

Hi Jon, Do you have any clue what's the cause of downtime using MV? eg. memory pressure, or overloaded by view writes? Thanks. On Fri, 26 Jul 2019 at 13:59, mehmet bursali wrote: > Thank you again for Clear information Jon! i give up 🤗 > > Android’de Yahoo Postadan gönderildi >

Re: Commit Log question

Hi Charulata, IMO, 64MB is fine unless you archive commit log or scan it for backup. Zhao Charulata Sharma (charshar) 于2017年4月28日周五 上午8:01写道： > Hi , > > Can anyone please tell me the implication of increasing the > commitlog_segment_size_in_mb > from the default value of 32 MB to a higher

Re: Drop tables takes too long

flush all schema info into sstable, then reads all on disk schema into memory (5k tables info + related column info).. > You also might need to increase the node count if you're resource constrained. More nodes won't help and most probably make it worse due to coordination. Zhao Y

Re: why dose it still have to seach in SSTable when getting data in memtable in the read flow？

Hi, Cassandra uses last-writetime-win strategy. In memory data doesn't mean it is the latest data due to custom write time, if data is also in Sstable, Cassandra has to read it and reconcile. Jasonstack On Mon, 27 Mar 2017 at 7:53 PM, 赵豫峰 wrote: > hello, I get the message that "If the memtable

Re:Question about compaction strategy changes

hi Edwards, when changibg gc_grace_second, no compaction willbbe triggered. regards, jasonstack Sent from my Mi phoneOn Seth Edwards , Oct 22, 2016 11:37 AM wrote:Hello! We're using TWCS and we notice that if we make changes to the options to the window unit or size, it seems to implicitly s

Re: Does anyone store larger values in Cassandra E.g. 500 KB?

1. usually before storing object, serialization is needed, so we can know the size. 2. add "chunk id" as last clustering key. Vikas Jaiman 于2016年10月21日周五 下午11:46写道： > Thanks for your answer but I am just curious about: > > i)How do you identify the size of the object which you are going to chunk?

Re: regarding drain process

Hi Varun, It looks like a scheduled job that runs "nodetool drain".. Zhao Yang Varun Barala 于2016年9月25日周日 下午7:45写道： > Jeff Jirsa thanks for your reply!! > > We are not using any chef/puppet and It happens only at one node other > nodes are working fine. > And all ma

Re: Read data from specific node in cassandra

Hi, Can you check LoadBalancing Policy -> whiteList ? jasonstack Varun Barala 于2016年5月5日周四 下午5:40写道： > Hi Siddharth Verma, > > You can define consistency level LOCAL_ONE. > > and you can applyh consistency level during statement creation. > > like this -> statement.setConsistencyLevel(Consisten

StatusLogger is logging too many information

Hi, Currently StatusLogger will log info when there are dropped messages or GC more than 200 ms. In my use case, there are about 1000 tables. The status-logger is logging too many information for each tables. I wonder is there a way to reduce this log? for example, only print the thread pool in

Re: Cassandra table limitation

the different (probably competing) workloads >> effectively. >> >> Mike >> >> On Tue, Apr 5, 2016 at 8:40 PM, jason zhao yang < >> zhaoyangsingap...@gmail.com> wrote: >> >>> Hi Jack, >>> >>> Thanks for the reply. >>&g

Re: Cassandra table limitation

to scale with the table count. For one each >> table/CF has some fixed memory footprint on *ALL* nodes. The consensus is >> you shouldn't have more than "a few hundreds" of tables. >> >> On Mon, Apr 4, 2016 at 10:17 AM, jason zhao yang < >> zhaoyangsin

Re: Cassandra table limitation

oogle.com/forum/#!topic/nosql-databases/IblAhiLUXdk > > In short C* is not designed to scale with the table count. For one each > table/CF has some fixed memory footprint on *ALL* nodes. The consensus is > you shouldn't have more than "a few hundreds" of tables. > > O

Cassandra table limitation

Hi, This is Jason. Currently, I am using C* 2.1.10, I want to ask what's the optimal number of tables I should create in one cluster? My use case is that I will prepare a keyspace for each of my tenant, and every tenant will create tables they needed. Assume each tenant created 50 tables with no