Spider Storage Engine Core Concepts
A typical spider deployment his a shared-nothing 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 servers, and can be a MariaDB, MySQL, Oracle server instance using any storage engine available inside the backend.
The Spider proxy nodes stand for instances running at least MariaDB 10 and define per table attachment to the backend nodes. Spider proxy node 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. 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 use 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.