I link this video to anyone who is beginning with Cassandra. You have the most clear and concise explanations available online. Thank you very much for your work!
6:47 so a write goes to all partitions or just one? You didn't mention this. If only one partition receives the write, is it written to disk before committed back as successful to the caller or how does this work?
When the data is still in Memtable and not yet sent to SSTable and server crashes (or say power goes off), we loose data right? What happens in those cases? Any way to recover data?
I’ve also wondered about that. But it seems that the commit log is on disk, similar to WAL. So it would rebuilt from that. The more interesting question here is conflict resolution between the nodes in case of conflicting writes and how is the data replicated between the nodes. Classic distributed system issues it seems.
@@Sverdiyev If commit log were on disk, it would defeat the original statement that "cassandra writes are fast since they are written to in-memory commit logs"
I link this video to anyone who is beginning with Cassandra. You have the most clear and concise explanations available online. Thank you very much for your work!
I am now on course to crash a Cassandra database.
Very clear your explanation!, Now I can see that cassandra is a good option to consider as DB in my project, thanks a lot for this useful content!
Glad this helped you come to that conclusion.
Excellent video man !
Glad you liked it!
Commitlog is on disk and not in memory, if you want to make correction in the video.
Uggh, yeah that's right. Thank you for correcting.
@@irtizahafiz And sequential writes to disk are very fast, that's why even if CommitLog is not in memory, writes are still very fast
@@Khushboo1811 it actually does the bulk update to Disk..every 10seconds if i am not wrong.
Really loved the explanation !!
It was so easy to understand! Thank you!
great video, please do a video on how the data is stored on disk with different column families
Good idea. I will!
Great explanation ❤
Great explanation, easy to understand!
6:47 so a write goes to all partitions or just one? You didn't mention this. If only one partition receives the write, is it written to disk before committed back as successful to the caller or how does this work?
Amazing explanation!!
many thanks
Is a distributed database all you need for a system to be distributed?
I think you can use the term in this case, yes.
Bro can you please make video on zipkin traces Store in Cassandra database
Added to my backlog. Thanks for the idea!
When the data is still in Memtable and not yet sent to SSTable and server crashes (or say power goes off), we loose data right? What happens in those cases? Any way to recover data?
first written to the commit log to prevent data loss in the event of a failure.
And i'm working on ScyllaDB; So if i know something let you know
I’ve also wondered about that. But it seems that the commit log is on disk, similar to WAL. So it would rebuilt from that.
The more interesting question here is conflict resolution between the nodes in case of conflicting writes and how is the data replicated between the nodes.
Classic distributed system issues it seems.
@@Sverdiyev If commit log were on disk, it would defeat the original statement that "cassandra writes are fast since they are written to in-memory commit logs"
multiple players with the same name with the same club? ... 😵💫what?
That analogy fell apart very quickly LOL. But hopefully you get an idea of how the different keys work.