CODEWITHSUNDEEP
cassandranosql
Adelin
Adelin

Reputation: 18941

Keep denormalized table consistent (synchronized) in Cassandra DB

I am exploring Cassandra DB and I've come across this video which explains how to denormalize tables to store comments and it goes like this:

Instead of having a comments table and users_id column in that table that points to the user wrote the comment and another table which is a video table and in the comments table a column that is video_id which points to the video that has been commented.

We will have two comments table one comments_by_user and another one comment_by_video the question is how to keep these two table synchronized ?

When a user comments on a video we insert a comment in comments_by_video and comments_by_user, for a video and user respectively. However, what if the the second insert fails ?

We will have a comment by a user on a video that however cannot be found when we select all comments for that user ?

Upvotes: 1

Views: 622

Answers (2)

Aravind Chamakura
Aravind Chamakura

Reputation: 339

One option is to Batch Statement as mentioned in previous answer, which will have perf impact.

The other option, I could think of trying would be to change consistency level to ANY when a write fails. With consistency 'ANY' your data will be saved in the coordinator node for the configured amount of time and replicate to the node when the other responsible node comes up.

For any failed writes, handle it in your code and change the consistency to ANY for that insert and execute the insert again. Ofcourse you won't be able to read that data until any of the responsible node gets the data. 

function retryWrites(...)
try{
//insert statement
}catch<writeexception>{
//set consistency to ANY 
//insert failed statement
//set consistency back to wherever is required.
}

call retryWrites(statement1)
call retryWrites(statement2)

Upvotes: 0

piotrwest
piotrwest

Reputation: 2166

You can use the Batch Statement for this purpose. Be warned though, that batch statement is slower and puts around 30% of overhead on the regular operation on the coordinator node.

Upvotes: 1

Related Questions