| Sources | Hardware and software resources (hosts, databases) required for the operation of the cluster. |
| Cluster | It consists of governance center, monitoring center, log center, compute node, storage node, where monitoring center and log center are optional and compute node belongs to the same namespace of governance center. |
| Cluster Ecology Tool | SphereEx-Boot and SphereEx-Console are ecosystem components. |
| Cluster Component | The components that make up the cluster, i.e. (governance center, monitoring center, logging center, compute nodes, storage nodes). |
| Minimized Cluster | Only the governance center and compute nodes are included. |
| Governance Center | Use the ZooKeeper implementation for storing metadata information about compute nodes. |
| Monitoring Center | Use the Prometheus implementation for monitoring clusters. |
| Monitoring Plugin | Deployed on the client side to collect monitoring information to the monitoring center. |
| Log Center | Implemented using Elasticsearch+Logstash for storing logs of compute nodes. |
| Log Center Plugin | Filebeat is deployed on the compute node and logs are collected and transferred to Elasticsearch storage via logstash. |
| Computing Node | Compute Node (Alias: Proxy Node Proxy). A compute node, corresponding to a SphereEx-DBPlusEngine deployment unit, a set of resources identified by IP, port. A single compute node that takes on SQL routing, data merging, data aggregation, and other functions. A SphereEx-DBPlusEngine cluster, corresponding to multiple compute nodes. Only SphereEx-DBPlusEngine-Proxy is covered in this document. |
| Storage Node | Storage Node physically corresponds to a Schema under a database instance, same as the previous concept of “data source”. It is a collection of object resources under a set of IP, port, username, password, schema (Schema) conventions. Note: corresponds to under the schema, not under the instance; i.e., to multiple schemas under the physical database instance. In the case of SphereEx-DBPlusSuite, this role is to assume the data storage function. |
| Logic Database | Logical Database (alias: Schema) A logical database, a virtual database consisting of one or more storage nodes. A SphereEx-DBPlusEngine cluster, which can correspond to multiple logical databases. |
| Object | Logical objects managed under a logical library can be analogous to objects in a database. |
| Plugin | Data application functions on pluggable architecture, including but not limited to data fragmentation, read/write separation, etc., can act on logical libraries, objects, etc. |
| Shard Table | The logical name of a horizontally split database (table) with the same structure as the logical table is the logical identifier of the table in SQL. |
| Broadcast table | Refers to a table that exists in all sharded data sources, where the table structure and its data are identical in each database. |
| Table group | Refers to the primary and child tables with the same slicing rules. When using bound tables for multi-table association query, you must use the slice key for association, otherwise, Cartesian product association or cross-library association will occur, which will affect the query efficiency. For example, if the t_order table and t_order_item table are both sliced according to order_id and are related using order_id, the two tables are related to each other as bound tables. The multi-table association query between the bound tables will not have a Cartesian product association, and the efficiency of the association query will be greatly improved. |
| Single Table | This refers to a table that exists uniquely in all storage nodes, and is suitable for tables that do not have a large amount of data and do not need to be sharded. |
| DistSQL | SphereEx-DBPlusEngine’s proprietary manipulation language. It is used in exactly the same way as standard SQL to provide SQL-level manipulation capabilities for incremental functionality. |