
SQL supported
On SQL syntax level, RadonDB Fully compatible with MySQL. All of the SQL features RadonDB supports can be viewed here:Radonsqlsurported
RadonDB is a cloud-native database based on MySQL. It’s architected to fully distributed cluster that delivering unlimited scalability (scale-out), capacity and performance. It supports distributed transaction capability for high data consistency, and leverage MySQL as storage engine with trusted data reliability. RadonDB is compatible with MySQL protocol, at mean time supports automatic table sharding, that simplifying the maintenance and opera-tion workflow.
Automatically sharding (partition) across nodes that minimizing the complexity of maintenance and operation.
Support distributed transaction across shards (partitions) that securing Atomicity, Consistency, Isolation, Durability (ACID) for whole transactrion process.
Presetting a set of connected threads that can be leveraged to accelerate the efficiency of connection between SQL cluster and storage nodes; supporting automatic reconnection and thread reuse.
Can be enabled for auditing and logging the SQL query operation in multiple dimensions: query event time, operations statement type, consuming time, etc; all these functions help to secure the operation safety and data compliance; the auditing log is able to be set in multiple modes for high flexibility: read (SQL) only, write only, or read/write simultaneously.
On SQL syntax level, RadonDB Fully compatible with MySQL. All of the SQL features RadonDB supports can be viewed here:Radonsqlsurported
After your SQL node receives a SQL request from a mysql client via proxy, RadonDB parses the statement, creates a query plan, and then executes the plan.
Received queries are parsed by sqlparser (which describes the supported syntax by mysql) and generated Abstract Syntax Trees (AST).
With the AST, RadonDB begins planning the query's execution by generating a tree of planNodes. This step also includes steps analyzing the client's SQL statements against the expected AST expressions, which include things like type checking.
You can see the a query plan generates using EXPLAIN(At this stage we only use EXPLAIN to analysis Table distribution).
Executing an Executor in a storage layer in Parallel with a Distributed Execution Plan.
The SQL node is stateless, but in order to guarantee transaction Snapshot Isolation, it is currently a write-multiple-read mode.
RadonDB supported distributed transaction capability. If one of the nodes that carrier distributed executors failed to execute, then the rest nodes will be rolled back, in order to guarantees the atomicity of operating across nodes and makes the database in a consistent state.
RadonDB achieved the level of SI (Snapshot Isolation) at the level of consistency. As long as a distributed transaction has not commit, or if some of the partitions have committed, the operation is invisible to other transactions.
The SQL node is stateless, but in order to guarantee transaction Snapshot Isolation, it is currently a write-multiple-read mode.