Why is Kafka fast? What is the secret? We'll talk about it in this video. Let's dive right in. We'll first start by acknowledging that the term fast is ambiguous.
What does it even mean that Kafka is fast? Are we talking latency? Are we talking throughput? Is fast compared to what? Kafka is optimized for high throughput.
It is designed to move a large number of records in a short amount of time. Think of it as a very large pipe moving liquid. The bigger the diameter of the pipe, the larger the volume of liquid that can move through it.
So when someone says Kafka is fast, they usually refer to Kafka's ability to move a lot of data efficiently. What are some of the design decisions that help Kafka move a lot of data quickly? There are many design decisions that contributed to Kafka's performance. In this video, we'll focus on two. We think these two carry the most weight.
The first one is Kafka's reliance on sequential I.O. What is sequential I.O.? Let's dig deeper into that.
There's a common misconception that disk access is slow compared to memory access, but this largely depends on data access patterns. There are two types of disk access patterns, random and sequential. For hard drives, it takes time to physically move the arm to different locations on the magnetic disks.
This is what makes random access slow. For sequential access though, since your arm doesn't need to jump around, it is much faster to read and write blocks of data one after the other. Kafka takes advantage of this by using an append-only log as its primary data structure. An append-only log adds new data to the end of the file. This access pattern is sequential.
Now let's bring this idea home with some numbers. On modern hardware with an array of this hot disks, sequential write reach hundreds of megabytes per seconds, while random writes are measured in hundreds of kilobytes per second. Sequential access is several order of magnitude faster.
Using hot disks has its cost advantage too. Compared to SSD, hot disks come as one-third of the price but with about three times the capacity, giving Kafka a large pool of cheap This space without any performance penalty means that Kafka can cost effectively retain messages for a long period of time, a feature that was uncommon to messaging system before Kafka. The second design choice that gives Kafka its performance advantage is its focus on efficiency. Kafka moves a lot of data from network to disk and then from disk to network.
It is critically important to eliminate excess copy when moving pages and pages of data between the disk and the network. Now this is where zero copy principle comes into the picture. Modern Unix operating systems are highly optimized to transfer data from disk to network without copying data excessively.
Let's dive deeper to see how this is done. First we look at how Kafka sends a page of data on disk to the consumer when zero copy is not used at all. First the data is loaded from disk to the OS cache.
Second, the data is copied from the OS cache into the Kafka application. Third, the data is copied from Kafka to the socket buffer. And fourth, the data is copied from the socket buffer to the network interface card buffer.
And finally, the data is sent over the network to the consumer. Now this is clearly inefficient. There are four copies and two system calls. Now let's compare this to zero copy. The first step is the same.
The data page is loaded from the disk to the OS cache. With zero copy, the Kafka application uses a system call called sendfile to tell the operating system to directly copy the data from the OS cache to the network interface card buffer. In this optimized path, the only copy is from the OS cache into the network card buffer.
With a modern network card, this copying is done with DMA. DMA stands for direct memory access. When DMA is used, the CPU is not involved, making it even more efficient. To recap, sequential I.O.
and zero-copy principle are the cornerstone to Kafka's high performance. Kafka uses other techniques to squeeze every ounce of performance out of modern hardware. But these two are the most important in our view. If you'd like to learn more about system design, check out our books and weekly newsletter. Please subscribe if you learned something new.
Thank you so much and we'll see you next time.