Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance SqlGeopartition app to segregate reads/writes to the local "region" only #88

Open
ajcaldera1 opened this issue Jan 6, 2023 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@ajcaldera1
Copy link

Now that we have leader_preference in tablespace groups, and there are more geo-partitioned use-cases coming up where customers are trying to read/write only to a specific region partition, we should enhance the SqlGeopartitioned workload to do reads/writes only to the connected "region" instead of randomly picking a region based on the modulus of the number of overall partitions.

E.g.
Consider the case where you have highly distributed regions:

ap-northeast-1
eu-west-1
us-east-1

In a geo-partitioned workload, where "fast" writes are required, you could set up a table that is comprised of multiple partitions that belong to 1 region only.
E.g.

ap-northeast-1a, ap-northeast-1c, ap-northeast-1d
eu-west-1a, eu-west-1b, eu-west-1c
us-east-1a, us-east-1b, us-east-1c

As it happens right now in SqlGeopartitionedWorkload, these would be set up as different partitions, but ultimately the choice of which region is written or read by the workload comes down to a simply key % num_partitions choice. While useful, it doesn't illustrate the power that could be shown by allowing the connection to determine which region to read/write from.

@ajcaldera1 ajcaldera1 added the enhancement New feature or request label Jan 6, 2023
@ajcaldera1 ajcaldera1 self-assigned this Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant