I would like to enforce me spending at most 3 hours on this series and developing StellarSQL each day. I am still studying in college now, so I cannot spend too much time on this. I cannot write too much words because it costs lots of time reading the source code of other DBMS and thinking about how to implement on StellarSQL.

As I mentioned yesterday, DBMS runs on servers. Therefore, before we develop modules of SQL parsing or database handling, we need to implement server functions.

The server part of a DBMS isn’t different too much from any other backend services. You can just think we are going to develop a server and add some DBMS modules on it.

Shoulders of Giants

Let’s take a glimpse at how MySQL does on the server part. It is always good to stand on the shoulders of giants. The “The Skeleton of the Server Code” in the internal guide of MySQL shows the underlying concepts about what a server of DBMS does. It’s recommended to read that guide before reading the following parts.

Basically, I would like to follow MySQL architecture when I implement StellarSQL, but in a simplified way. I would refers some good parts in other open sources projects when I develop the project.

The following snippet is the simplified server code of MySQL:

!FILENAME /sql/mysqld.cc

  int main(int argc, char **argv)
  {
    _cust_check_startup();
    (void) thr_setconcurrency(concurrency);
    init_ssl();
    server_init();                              // 'bind' + 'listen'
    init_server_components();
    start_signal_handler();
    acl_init((THD *)0, opt_noacl);
    init_slave();
    create_shutdown_thread();
    create_maintenance_thread();
    handle_connections_sockets(0);
    DBUG_PRINT("quit",("Exiting main thread"));
    exit(0);
  }

All functions are very straightforward. init_ssl runs OpenSSL. server_init and init_server_components are just doing as their names. start_signal_handler is for interrupt and (a)synchronous procedures. handle_connections_sockets is for the connections.

Now we have the idea of how to do. So let’s work on StellarSQL.

Tokio.rs in StellarSQL

As you can see the source code of MySQL has implemented lots of underlying functions by themselves, including lock, signal, IPC, socket and others. I am just going to do a proof of concept project of DBMS, so I would not implement such detail modules.

I would use Tokio.rs in StellarSQL. This framework has done some underlying modules already, so I can focus on implementation parts of SQL and database.

According to the official website of Tokio.rs:

Tokio is an event-driven, non-blocking I/O platform for writing asynchronous applications with Rust. At a high level, it provides a few major components:

  • A multithreaded, work-stealing based task scheduler.
  • A reactor backed by the operating system’s event queue (epoll, kqueue, IOCP, etc…).
  • Asynchronous TCP and UDP sockets.
    These components provide the runtime components necessary for building an asynchronous application.

Looks like Tokio.rs is so powerful, isn’t it?

Then, I will use Tokio.rs to implement the basic parts of StellarSQL tomorrow.

I have run out the time today (remember the rule of 3-hours limitation?), so see you tomorrow!