Re: Unsubscribe

please send an empty email to: user-unsubscr...@cassandra.apache.org to unsubscribe yourself from the list. Thank you. srinivasarao daruna wrote: Thank You, Regards, Srini - To unsubscribe, e-mail:

Unsubscribe

Thank You, Regards, Srini

Re: Cqlsh copy command on a larger data set

Thank you for the suggestions On Tue, Jul 14, 2020 at 1:42 AM Alex Ott wrote: > CQLSH definitely won't work for that amount of data, so you need to use > other tools. > > But before selecting them, you need to define requirements. For example: > >1. Are you copying the data into tables with

Re: Cqlsh copy command on a larger data set

CQLSH definitely won't work for that amount of data, so you need to use other tools. But before selecting them, you need to define requirements. For example: 1. Are you copying the data into tables with exactly the same structure? 2. Do you need to preserve metadata, like, writetime & TTL?

RE: design principle to manage roll back

Thanks. Will check Scalar DB. I avoid batch because I read that it isn’t perfect. Regarding Idempotent, my apprehension is that if the write is failing then subsequent attempts might also fail. Sorry, I am not trying to find issues in your suggestions (it might sound like I am). I am just

RE: design principle to manage roll back

Thanks. Will check Scalar DB. I avoid b Sent from Mail for Windows 10 From: Hiroyuki Yamada Sent: 14 July 2020 09:26 To: user@cassandra.apache.org Subject: Re: design principle to manage

Re: design principle to manage roll back

As one of the options, you can use (Logged) batch for kind of atomic mutations. I said, "kind of" because it is not really atomic when mutations span multiple partitions. More specifically, the mutations go to all the nodes eventually so intermediate states can be observed and there is no

RE: design principle to manage roll back

Thanks. Actually none of my data is big data. I just thought not to use traditional RDBMS for my project. Features like replication, fast read and write, always ON, scalability appealed well to me. I am also happy with eventual consistency. To be honest, I feel there has to be a way because if

Re: design principle to manage roll back

Hi, I think that Cassandra alone is not suitable for your use case. You can use a mix of Distributed/NoSQL (to storing single records of whatever makes your input the big data) & Relational/Single Database (for transactional non-big data part) Sent using https://www.zoho.com/mail/

design principle to manage roll back

Hi What are the design approaches I can follow to ensure that data is consistent from an application perspective (not from individual tables perspective). I am thinking of issues which arise due to unavailability of rollback or executing atomic transactions in Cassandra. Is Cassandra not