Request processing

This page follows a statement from the client to the data.

The connection

The client connects a SQL broker and sends the statement as a message. The broker checks that the user exists and has the privilege, then answers. A statement is executed by the broker that received it; the client does not choose.

Statements that change the dictionary

create, alter, drop, grant, deploy... read and write the dictionary on the master brokers. Their answer is a text message. The long ones (deploy, update, dump, repair) run in the background of the broker and answer when they are over.

select

1. The broker finds in the dictionary where the data of the table is stored.
2. It opens a dedicated port for the result, protected by a random token, and tells the client. The client connects to this port.
3. The data brokers run your statement on their own partitions, in parallel, and the rows come back to you: sorted if there is an order by, in no particular order otherwise.
4. Rows are sent to the client as they arrive, and the client asks for each next row, so a slow client does not make the broker allocate the whole result. A row is at most 64 KB.
5. When the table has many partitions, the SQL brokers of the cluster share the work. You do not see it: you always talk to the broker you are connected to.

Wide tables

For a wide table, each row is assembled from its pieces before it reaches the client. This is why the select must name the whole hash key: the key is what links the pieces of a row.

insert, delete

An insert computes the partition from the hash key, then writes the row to each copy (and each chunk, for a wide table). A delete with a condition first finds the rows, then deletes them by their key on every copy.

When something stops

The client has no ping. If the broker does not answer, the client connects another one and sends the statement again, if it only reads. A statement that changes data is never sent again by itself: the client tells you that it may or may not have been executed.