Spider Storage Engine Core Concepts
A typical Spider deployment his a shared-nothing clustered architecture, the system work with any inexpensive hardware, and with a minimum of specific requirements for hardware or software. It consists of a set of computers, with one or more MariaDB processes known as nodes.
The nodes that store the data will be designed as Backend Nodes
, and can be any MariaDB, MySQL, Oracle server instances using any storage engine available inside the backend.
The Spider Proxy Nodes
are instances running at least MariaDB 10. Spider Proxy Nodes
are used to declare per table attachment to the backend nodes. In addition Spider Proxy Nodes
can be setup to enable the tables to be split and mirrored to multiple Backend Nodes
.
Spider Common Usage
Spider Storage Engine Federation
Spider is a pluggable Storage Engine, acting as a proxy between the optimizer and the remote backends. When the optimizer request multiple calls to the storage engine, Spider will enforce consistency using a 2 phase commit protocol to the backends and creating transactions on the backends to preserve atomic operations during a single SQL execution.
Preserving atomic operation during an execution is used at multiple level in the architecture, for regular optimizer plans refer as multiple split reads
and for concurrent partitions scans it will refer to semi transactions
.
Costly queries can be more efficient when it is possible to fully pushed down part of the execution plan on each backend and reduce the result afterward. Spider enable such execution with some direct execution shortcuts.
Spider Threading Model
Spider is using the per partitions and per table model to concurrently access the remote backend nodes. For memory workload that property can be used to define multiple partitions on a single remote backend node to better adapt the concurrency to available CPUs in the hardware.