Database Guide

Context

Recently, a friend of mine told me about a particular company he had interviewed with and that they were looking for someone who had worked with Clickhouse. It seemed absurd to us that they would be looking for someone with such specific knowledge. We've both worked with several databases and storage systems over the years and once you understand a couple of them really well, it becomes trivial to understand a new one that comes along. It's silly to reject a strong candidate based on that.

There are a few reasons I think companies would reject good candidates without the specific knowledge:

  1. They do not understand the database/storage systems through the patterns they use, or they feel the candidate does not. - This article tries to rectify this failing.
  2. Highly esoteric database / storage system. - I attempt to tackle this later.
  3. Randomness of interviews and reasons that have nothing to do with knowledge of databases.

Patterns of Database/Storage Systems

In most backend systems we understand the system by the path the data takes and how it is mutated. For example, http traffic to servers, microservices, etc. So, we'll start with that and then move further. The list below shows the main areas I look at to understand a database.

  1. Interface
    2. This is the tcp server / library that the application uses to interact with the database.

    Postgresql

    TCP server with binary protocol and also unix domain socket.

  2. Write Path

    3. Postgresql

    Clickhouse

  3. Read Path
  4. Distributed Systems
  5. Disk Write Optimization