Read IO path (single shard)

Let us take the case of a single key read.

Step 1. Identify tablet leader

The user-issued read request first hits the YQL query layer on a port with the appropriate API, which is either YSQL or YCQL. This user request is translated by the YQL layer into an internal key. TheYQL layer then finds this tablet as well as the YB-TServers hosting it by making an RPC call to theYB-Master, and caches the response for future. The YQL layer then issues the read to the YB-TServerthat hosts the leader tablet-peer. The read is handled by the leader of the RAFT group of the tabletowning the internal key. The leader of the tablet RAFT group which handles the read request performsthe read from its DocDB and returns the result to the user.

As mentioned before in the write IO path section, the YugabyteDB smartclient can route the application requests directly to the correct YB-TServer avoiding any extranetwork hops or master lookups.

Step 2. Tablet leader performs the read operation (default is strongly consistent read)

Continuing our previous example, let us assume the user wants to read the value where the primarykey column K has a value k from table T1. From the previous example, the table T1 has a key column Kand a value column V. The read flow is depicted below.

Note that the read queries can be quite complex - even though the example here talks about a simplekey-value like table lookup. The YQL query layer has a fully optimized query engine to handlequeries which contain expressions, built-in function calls, arithmetic operations in cases wherevalid, etc.