RE: design principle to manage roll back

[Manu Chadha]

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 Cassandra promotes data 
duplication by creating a table for each query then there should be a way to 
keep duplicate copies consistent.


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: onmstester onmstester<mailto:onmstes...@zoho.com.INVALID>
Sent: 14 July 2020 08:04
To: user<mailto:user@cassandra.apache.org>
Subject: 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 Zoho Mail<https://www.zoho.com/mail/>


---- On Tue, 14 Jul 2020 10:47:33 +0430 Manu Chadha <manu.cha...@hotmail.com> 
wrote ----


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 suitable for my project?

Cassandra recommends creating a new table for each query. This results in data 
duplication (which doesn’t bother me). Take the following scenario. An 
application which allows users to create, share and manage food recipes. Each 
of the function below adds records in a separate database


for {savedRecipe <- saveInRecipeRepository(...)

               recipeTagRepository <- saveRecipeTag(...)
               partitionInfoOfRecipes <- savePartitionOfTheTag(...)
               updatedUserProfile <- updateInUserProfile(...)
               recipesByUser <- saveRecipesCreatedByUser(...)
               supportedRecipes <- updateSupportedRecipesInformation(tag)}

If say updateInUserProfile fails, then I'll have to manage rollback in the 
application itself as Cassandra doesn’t do it. My concerns is that the rollback 
process could itself fail due to network issues say.

Is there a recommended way or a design principle I can follow to keep data 
consistent?

Thanks
Manu

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10