question

Shalini Ramachandra avatar image
Shalini Ramachandra asked Erick Ramirez commented

Is fetch-and-update considered anti-pattern in Cassandra?

Are the following 2 scenarios considered anti-patterns in Cassandra?

  1. Create a user with unique email. Since Cassandra does UPSERT and INSERT on an already existing record does not throw error, I will have to first fetch a user by email (aka READ) to validate that no other user exists. And only then INSERT.
  2. In my ReST Application the POST endpoint lets me CREATE a resource (aka entity). Once written, some columns should never be changed by the application. For ex: createdBy, createdDt, etc. And a PUT endpoint only allows me to update certain columns (depending on business logic). For this purpose, I will have to fetch the resource first (aka READ), so that I know if I'm working on a new record / existing record.

Are these considered read-before-write Anti-pattern? DS220 course talks about "Queries that require reads before writes excessively are expensive". What does the word "excessive" signify here?

lightweight transactionsanti-pattern
10 |1000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

2 Answers

Erick Ramirez avatar image
Erick Ramirez answered Erick Ramirez commented

No, they are not. They are called compare-and-set statements (CAS) because it involves making a comparison to see if a condition is satisfied before setting the value. These types of statements are also known as lightweight transactions (LWT).

In a scenario where you have a table like:

CREATE TABLE users_by_email (
    email text,
    username text,
    ...
    PRIMARY KEY (email)
)

A lightweight transaction would be:

INSERT INTO users_by_email (email, username, ... ) \
    VALUES ('joe@bloke.com', 'joebloke', ... )
    IF NOT EXISTS;

For a new user to be added, the email must not already exist in the table. To achieve this, Cassandra performs a read-before-write. As Saravanan stated in his answer, there are performance considerations when using LWTs since they require four round-trips between the client and the cluster. The blog post Lightweight transactions in Cassandra has a good explanation of how Cassandra implements this using the Paxos protocol.

The second part of your question is a little trickier. You need to apply the business rules for not updating certain columns within your application. But where possible, you should minimise the amount of read-before-write steps in your workflow but it could benefit from LWTs so the application is not "creating" a new record if it already exists.

The "excessive" part of the statement is when your application is constantly doing reads-before-writes which require multiple queries than a straight write. Cheers!

2 comments Share
10 |1000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Shalini Ramachandra avatar image Shalini Ramachandra commented ·

Thanks @Erick Ramirez. Nice and detailed as always!

0 Likes 0 ·
Erick Ramirez avatar image Erick Ramirez ♦♦ Shalini Ramachandra commented ·

Not a problem. Cheers!

0 Likes 0 ·
saravanan.chinnachamy_185977 avatar image
saravanan.chinnachamy_185977 answered Shalini Ramachandra commented

@Shalini Ramachandra Please find some details around both the scenarios.

Cheers!!!

1 comment Share
10 |1000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Shalini Ramachandra avatar image Shalini Ramachandra commented ·

Unfortunately, I can only accept one answer :) Else, I'd accept this one too. Thanks so much for sharing the details

0 Likes 0 ·