The database horizontally distributes rows either by: partition field, relation (parent/child foreign key relation), round-robin, or, replicate rows to all partitions.
Contents |
The partition field set during table creation. There can be only one partition field per table; it cannot be nullable. For example:
CREATE TABLE mytable ( id BIGINT NOT NULL PRIMARY KEY PARTITION, info CHAR )
The rows will be partitioned by [id] hash value. It is possible to check/view the partition group id to that the row will be inserted by looking into insert SQL query DQL plans. For example, in managers' query window paste SQL insert:
INSERT INTO mytable VALUES (0,'val1')
Then, press "show execution plan" button, that reveals:
INSERT 'test.mytable' ON '0' SET @this.[id]=0, @this.[info]='val1'
The output DQL's on '0' identify that the command will be executed at partition group (0), i.e. all nodes of partition group will insert the row.
Similar SELECT/UPDATE/DELETE will perform an action on particular partition group, if the partition field used in the WHERE clause. For example:
DELETE FROM mytable WHERE id=0
The DQL plan:
DELETE 'test.mytable(xlock_row)' ON '0' INDEX BY '100' WITH @this.[id]=0
When partition field cannot be used in search clause, the query will be sent to all partition groups. For instance SQL:
DELETE FROM mytable WHERE id>0
In DQL, missing ON keyword, means delete will be executed on all partition groups.
DELETE 'test.mytable(xlock_row)' INDEX BY '100' WITH @this.[id]>0
When tables join by partition fields either in INNER/OUTER JOIN on (...) or WHERE clauses, the join operation will be executed in parallel on each involved node. I.e. each node will perform the local join and then send the results back to the client. For example, using previously created table [mytable]:
SELECT t1.* FROM mytable t1 INNER JOIN mytable t2 ON (t1.id = t2.id)
Will produce DQL:
open_table 'test.mytable' TO @TT1 INDEX BY '100' project BY @this.[id],@this.[info] open_table 'test.mytable' TO @TT2 INDEX BY '100' join_inner 'TT1','TT2' TO @_esults WITH @TT1.[id]=@TT2.[id] project BY @TT1.[id],@TT1.[info],@TT2.[id] aggregate '_esults' TO @Results
The keyword split in DQL plan would mean that the output of one table will be aggregated from all nodes and then sent to each node to perform join. In this case split command is missing, therefore, the joins executed locally in parallel, and only successor rows are sent to the client. Hence, it still executes on all partitions.
Lest take another join:
SELECT t1.* FROM mytable t1 INNER JOIN mytable t2 ON (t1.id > t2.id)
The DQL plan:
open_table 'test.mytable' TO @_T1 INDEX BY '100' project BY @this.[id],@this.[info] aggregate '_T1' TO @#T1 splitter '#T1' TO @TT1 open_table 'test.mytable' TO @TT2 INDEX BY '100' join_inner 'TT1','TT2' TO @_esults WITH @TT1.[id]>@TT2.[id] project BY @TT1.[id],@TT1.[info],@TT2.[id] aggregate '_esults' TO @Results
Even if both t1.id and t2.id are partition fields, since condition is not an equal, local join optimization cannot be applied. We can see here split. The join is much less efficient now.
This is used when parent table is partitioned on one column and linked with child table(s) partitioned on parents' auto identity column.
Example, execute SQL:
CREATE DATABASE test_hierarchy_dist; GO; USE test_hierarchy_dist; GO; CREATE TABLE t3 ( name CHAR NOT NULL PRIMARY KEY partition, id autobigint NOT NULL UNIQUE ); GO; CREATE TABLE t3_1 ( id BIGINT NOT NULL partition, info CHAR, uid autobigint NOT NULL PRIMARY KEY, CONSTRAINT sk FOREIGN KEY (id) REFERENCES t3(id) ); GO; CREATE TABLE t3_1_1 ( id BIGINT NOT NULL partition, info2 CHAR, uid autobigint NOT NULL PRIMARY KEY, CONSTRAINT sk FOREIGN KEY (id) REFERENCES t3_1(uid))
In the example above, T3 table partitioned by the column <name>. The [T3] AutoBigInt column <id>, generates auto unique values, the value is unique, and, additionally, it encodes <name> columns' hash value. Therefore, child table T3_1 will be as well partitioned by T3(name), even if it is set to partition by ID field which is linked with T3(ID) ”AutoBigInt” field. Note: Foreign key contraint must be present, the optimizer must be told it is parent/child relation.
Example, execute script to populate rows:
USE test_hierarchy_dist; GO; DECLARE @i INT, @name CHAR, @r1 BIGINT, @r2 BIGINT BEGIN tran SET @i = 0 while @i < 10000 BEGIN SET @name = concat('m',@i) INSERT INTO t3(name) VALUES(@name) SET @r1 = scope_identity() INSERT INTO t3_1(id,info) VALUES(@r1,concat('v',@r1)) SET @r2 = scope_identity() INSERT INTO t3_1_1(id,info2) VALUES(@r2,concat('z',@r2)) INSERT INTO t3_1_1(id,info2) VALUES(@r2,concat('z',@r2)) SET @i = @i +1 END commit
Next, check ( show DQL plan ) if the following query will be executed only on a single node (the partition calculated by the WHERE clause name=value condition).
USE test_hierarchy_dist; GO; SELECT t3.* FROM t3 JOIN t3_1 ON (t3.id = t3_1.id) JOIN t3_1_1 ON (t3_1.uid = t3_1_1.id) WHERE t3.name = 'm1'
The DQL:
open_table 'test_hierarchy_dist.t3' ON '0' TO @TT1 INDEX BY '100' WITH @this.[name]='m1' project BY @this.[name],@this.[id] open_table 'test_hierarchy_dist.t3_1' TO @TT2 INDEX BY '101' join_inner 'TT1','TT2' ON '0' TO @TT3 WITH @TT1.[id]=@TT2.[id] project BY @TT1.[name],@TT1.[id],@TT2.[uid],@TT2.[id] AS u1 open_table 'test_hierarchy_dist.t3_1_1' TO @TT4 INDEX BY '101' join_inner 'TT3','TT4' ON '0' TO @Results WITH @TT3.[uid]=@TT4.[id] project BY @TT3.[name],@TT3.[id],@TT3.[uid]
We can see ON '0' on @TT1,@TT3,@Results, and, we don't see split, that means all commands will be executed on partition group (0). Note: @TT2 and @TT4 processes are the join inner tables (right parameters in join_inner process), therefore they don't play any role in distribution decision and missing ON.
Replicating tables are quite useful for tables that are not often modified, and usually define details of some static entity that can be linked by its id field. For example, product details by id, OLAP dimension tables for fact table, etc... Since, they are replicated to all nodes, each field is considered as partition field. In order to define the table as replicated, do not set PARTITION field when creating the table. For instance, consider following 2 tables:
CREATE TABLE products -- replicated table ( product_id autobigint NOT NULL PRIMARY KEY, name CHAR ) GO; CREATE TABLE orders -- partitioned by [user_id] ( order_id autobigint NOT NULL PRIMARY KEY, user_id BIGINT NOT NULL PARTITION, product_id BIGINT NOT NULL, ammount INT, CONSTRAINT [USER] INDEX(user_id), CONSTRAINT product FOREIGN KEY (product_id) REFERENCES products(product_id) )
Following SQL query will retrieve all orders for the user. Since [user_id] is partition field and [products] table is replicated, the execution will be done on a single node.
SELECT orders.*,products.product_id FROM orders JOIN products ON (orders.product_id = products.product_id) WHERE user_id = 0
DQL:
open_table 'test_hierarchy_dist.orders' ON '0' TO @TT1 INDEX BY '101' WITH @this.[user_id]=0 project BY @this.[order_id],@this.[user_id],@this.[product_id],@this.[ammount] open_table 'test_hierarchy_dist.products' TO @TT2 INDEX BY '100' join_inner 'TT1','TT2' ON '0' TO @Results WITH @TT1.[product_id]=@TT2.[product_id] project BY @TT1.[order_id] rid,@TT1.[user_id],@TT1.[product_id],@TT1.[ammount],@TT2.[product_id] rid
It is possible to control on what node to execute the stored procedure. Based on the input parameters' hash value, the procedure will be sent to the adequate node to execute. It comparable to simple sharding, where based on some parameter, the queries is executed on target shard. Note: if procedures' query(ies) distribution conflict with the executing node (computed by input parameter), the database error will be thrown.
For example, create a stored procedure, where parameters' [@val1] hash value define the target executing node/partition:
CREATE PROCEDURE test (@val1 INT PARTITION, @val2 INT OUTPUT) AS BEGIN SET @val2 = @val1 SELECT @val1 END
So, @v1 value, defines the node to execute the procedure:
DECLARE @v1 INT = 10, @v2 INT = 0 EXEC test @v1,@v2 output SELECT @v2
Round robin partitioning makes sense to apply when table has no logical partition attributes, e.g., tables for logging, facts, etc... </br>To enable round-robin partitioning, set GROUP PARTITION on AUTOBIGINT data type field.
For example, create round-robin table:
CREATE TABLE test_round_robin ( id autobigint NOT NULL PRIMARY KEY partition, myfield INT, info text )
Next, insert 1000 uniformly distributed rows:
DECLARE @i INT = 0 BEGIN tran while @i < 1000 BEGIN INSERT INTO test_round_robin(myfield,info) VALUES(@i,concat('text-',@i)) SET @i = @i+1 END commit