SLICES
Table Option for MariaDB Xpand
This page is part of MariaDB's Documentation.
The parent of this page is: Table Options with MariaDB Xpand
Topics on this page:
Overview
Xpand breaks each representation (primary key + table or other index) into smaller, more manageable segments called "slices", each of which is assigned a portion of the representation's rows. There are multiple copies of each slice, called replicas.
Slices are distributed throughout the cluster to facilitate evenly distributed query processing.
The number of slices specified for the table itself applies to the table's data as well as to its primary key.
A different number of slices may be specified for each representation.
The number of slices for a given representation should never be less than the number of nodes in the cluster. (Tables distributed to
ALLNODES
are an exception.)When a slice becomes too large and exceeds rebalancer_
split_ threshold_ kb, the Rebalancer will split the slice into new slices and distribute the original slice's rows among them. The larger a slice becomes, the more expensive it is to move or copy it across the system. The maximum slice size for an individual table or index can be specified by including
split_threshold_kb
in the representation's DDL.
A slice must physically fit in its entirety on the storage device to which it is assigned. One slice may not span multiple devices.
To modify the number of slices for an existing table or index, follow this syntax:
ALTER TABLE tbl_name [SLICES = n] [ , INDEX index_name [SLICES = n] [split_threshold_kb = n]]
Global Variable Definitions
The following global variables impact Xpand slicing.
Name | Description | Default Value | Session Variable |
---|---|---|---|
| Controls how data is sliced. If set to |
| Yes |
| Default size at which the rebalancer splits slices. |
| |
| Defines how frequently the Rebalancer will assess if additional slices are needed. Specify |
|
Best Practices
The default slice size of 8 GB is optimal for most use cases. If a very large table results in more slices than available cores, performance might be impacted and increasing the max slice size may be recommended.
Tables and indexes should have a minimum number of slices equal to the number of nodes, with ALLNODES
tables being an exception. Use the following query to identify tables that contain fewer slices than the current number of nodes:
sql> SELECT fd.name `Database`, f.name `Table`, Count(*) Slices FROM system.slices JOIN system.representations fp USING (representation) JOIN system.relations f ON ( relation = `table` ) JOIN system.DATABASES fd USING (db) GROUP BY `Database`, `Table`, fp.name HAVING fd.name NOT IN ( 'system', 'clustrix_statd','clustrix_ui','_replication' ) AND slices < (SELECT Count(*) FROM system.membership WHERE status = 'quorum') AND (fp.name LIKE '%__PRIMARY%' OR fp.name LIKE '__base%') ORDER BY `Database`, `Table`, Slices;
Pre-slicing Tables
During normal operation, relations are resliced on demand, however it can be advantageous to pre-slice tables for which large data growth is anticipated. Creating or altering a representation to have a slice count commensurate with the expected size will allow the cluster to add data to the representation at maximum speed as slice splitting will be unnecessary. For additional information, see Data Import with MariaDB Xpand.
Use the following equation to determine the optimal number of slices for a table: (expected table size + 10%) / rebalancer_
Managing Slice Splitting
The Rebalancer automatically splits a table slice or index slice when it reaches the threshold set by the global rebalancer_