[MDEV-13392] Spider relaxed partitioning limitation Created: 2017-07-27  Updated: 2017-07-28  Resolved: 2017-07-28

Status: Closed
Project: MariaDB Server
Component/s: Partitioning, Storage Engine - Spider
Fix Version/s: N/A

Type: Task Priority: Minor
Reporter: Anders Karlsson Assignee: Unassigned
Resolution: Not a Bug Votes: 1
Labels: None


 Description   

Feature request:

When using Spider it would be useful to take advantage of data from several tables being colocated on the same set of Spider data nodes. This enforces that the column used for colocating data is also part of the primary key in all the tables, as this is a limitation of partitioning. Take the example of orders/customers. If we shard on customer_id, which is not unreasonable, then we have to make customer_id a part of the primary key in the orders table for this to work. It is understood that the limitation in partitioning to enforce the partitioning column to be part of the primary key is well founded and that this is there to ensure the uniqueness across partitions of the primary key. That said, in some cases it would be useful to lift this restriction, on a table by table basis, making the user responsible for maintaining cross partition uniqueness.



 Comments   
Comment by David Thompson (Inactive) [ 2017-07-28 ]

Lets say you have the given example of customer and order and you shard both tables on customer_id. DML should be being performed on the spider node and this inherently will result in co-location of a given customer and related orders on one shard. The primary key of the spider table on the spider node for order must include both order_id and customer_id, however it's not strictly required on the data node, you would of course want to ensure that customer_id is indexed.

So i don't think any enhancement is needed unless i am misunderstanding the case.

Generated at Thu Feb 08 08:05:14 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.