Search for a command to run...
Hands-on technology leader with 10+ years building scalable, mission-critical systems at Goldman Sachs, Brevan Howard and fast-growing fintechs. Expert in cloud-native architectures, distributed data pipelines and high-throughput systems; experienced in migrating legacy platforms and designing AI-enabled services. Proven track record delivering reliable platforms that process millions of transactions daily.
No comments yet. Be the first to comment.
It’s an Exoskeleton, and That Changes Everything Most people are thinking about AI the wrong way. They imagine it as a coworker:Something you assign tasks to… wait for… and hope it delivers. Sounds re
I didn’t wake up one day and decide, “AI will change everything.”My journey into AI was slower, messier, and honestly… a bit reluctant at first. If you’re a builder, engineer, or curious technologist,
Imagine a programming language designed not just for humans but also for AI.Not adapted for AI. Not retrofitted. Built from scratch so AI can read and write it easily. That’s exactly what NanoLang is. It’s a tiny, experimental language created by vet...
Most PostgreSQL optimization guides feel like laundry lists of settings and indexes. But real performance gains often come from clever ideas, not just the usual tricks. Let’s unpack a few of those ideas in ways that actually make sense for you. These...
Remember when we defeated pop-up ads? Yeah, they're back. And this time, nobody's fighting them. The Good Old Days (Of Terrible Ads) Back around 2000, the internet was a warzone. Visit any website and BAM!!! random windows would explode onto your scr...
This is the second part in a two-part series about the internals of Apache Cassandra for writing data. Click here to read the first part.
The process begins by a client sending a request to the coordinator containing an INSERT statement. Let’s assume we have a table named table1 according to below definition:
CREATE TABLE table1 (id int, name text, PRIMARY KET id);
And the cluster consists of five nodes, which we will call node1, ..., node5, and the replication factor is 3. The cluster will have a partitioner algorithm which given the primary key of the row, outputs a big random number. We call this random number, the identifier of the row. We assume an identifier number is a 128-bit number which means it will be between 0 and 2^128-1 (max number). Now consider this as a range of (0, max). Upon cluster configuration, this range is divided into five equal sub-ranges (because the cluster has five nodes):
R1=(0, max/5), R2=(max/5+1, 2*max/5), ... .
Each node will have its own range. R1 will be assigned to node1, R2 to node2 etc.
All nodes in the cluster know about other nodes and their corresponding range.
Coordinator receives this CQL statement:
INSERT INTO table1(id, name) VALUES (100, 'mahdi');
First, it applies the partitioner algorithm on ‘100‘ (the primary key). The result will be a number. It then determines the corresponding range (Ri, i=1,..,5) within which the number lies. Let’s assume the result number lies within R2 range. So node2 will receive the first copy of the row. But we have a replication factor of 3 which means data needs to be stored on three different nodes. In a simple replication strategy, additional nodes will be next nodes after the original receiver of the data which are R3 and R4 in our example. So coordinator will send 3 requests to R2, R3 and R4 to store the values for the new row in their local data (There is another more complex strategy called NetworkTopologyStrategy, see here for more information).
Note that R1 and R5 know nothing about the new row but the whole cluster contains the new data and you can later query this data from any of the nodes in the cluster.
In a node which belongs to a Cassandra Cluster, there are 3 components which are used to store data:
When writing data to the database, the data is written on Memtable and then on Commit log. After that a successful response is sent to the requester indicating the write operation is done successfully. Note that data is not written to SStable but it’s on persistent storage (Commit log) so it is safe. Periodically, the node requests memtables to be flushed to SStable which will write all updates to SStable (the final permanent storage for the data).
##